Java中锁的应用之-ReadWriteLock

上面我们用儿子和父亲做了一个例子，儿子太猖狂了，花钱根本没有谱。

下面我们再做一个例子，讲解ReadWriteLock的使用，例子和刚才差不多，但是又多了一个角色母亲，而且父母只负责监督，不再存钱。

儿子每三秒都会去花钱一次，而父母每秒都在监督这个卡的使用情况。

 

所有 ReadWriteLock 实现都必须保证 writeLock 操作的内存同步效果也要保持与相关 readLock 的联系。也就是说，成功获取读锁的线程会看到写入锁之前版本所做的所有更新。

与互斥锁相比，读-写锁允许对共享数据进行更高级别的并发访问。虽然一次只有一个线程（writer 线程）可以修改共享数据，但在许多情况下，任何数量的线程可以同时读取共享数据（reader 线程），读-写锁利用了这一点。从理论上讲，与互斥锁相比，使用读-写锁所允许的并发性增强将带来更大的性能提高。在实践中，只有在多处理器上并且只在访问模式适用于共享数据时，才能完全实现并发性增强。

在 writer 释放写入锁时，reader 和 writer 都处于等待状态，在这时要确定是授予读取锁还是授予写入锁。Writer 优先比较普遍，因为预期写入所需的时间较短并且不那么频繁。Reader 优先不太普遍，因为如果 reader 正如预期的那样频繁和持久，那么它将导致对于写入操作来说较长的时延。公平或者“按次序”实现也是有可能的。

在 reader 处于活动状态而 writer 处于等待状态时，确定是否向请求读取锁的 reader 授予读取锁。Reader 优先会无限期地延迟 writer，而 writer 优先会减少可能的并发。

 

我们创建信用卡类：

package com.entity;
public class BankCard {	
	private String cardid = "XZ456789";	
	private int balance = 10000;
	public String getCardid() {
		return cardid;
	}
	public void setCardid(String cardid) {
		this.cardid = cardid;
	}
	public int getBalance() {
		return balance;
	}
	public void setBalance(int balance) {
		this.balance = balance;
	}
}

 

里面有卡号和父母已经存的钱。

儿子花钱首先要获得写的锁把卡锁了，然后再花钱。之后放开这个锁。

package com.thread;
import java.util.concurrent.locks.ReadWriteLock;
import com.entity.BankCard;
/**
 * @说明 儿子类，只消费
 */
public class Consumer implements Runnable {
	BankCard bc = null;
	ReadWriteLock lock = null;
	Consumer(BankCard bc, ReadWriteLock lock) {
		this.bc = bc;
		this.lock = lock;
	}
	public void run() {
		try {
			while(true){
				lock.writeLock().lock(); 
				System.out.print("儿子要消费，现在余额：" + bc.getBalance() + "\t");
				bc.setBalance(bc.getBalance() - 2000);
				System.out.println("儿子消费2000元，现在余额：" + bc.getBalance());
				lock.writeLock().unlock(); 
				Thread.sleep(3 * 1000);	
			}
		} catch (Exception e) {
			e.printStackTrace();
		}		
	}
}

父母类只监督这个卡的使用，获得的是读的锁。

package com.thread;
import java.util.concurrent.locks.ReadWriteLock;
import com.entity.BankCard;
/**
 * @说明 父母类，只监督
 */
public class Consumer2 implements Runnable {
	BankCard bc = null;
	int type = 0;
	ReadWriteLock lock = null;
	Consumer2(BankCard bc, ReadWriteLock lock,int type) {
		this.bc = bc;
		this.lock = lock;
		this.type = type;
	}
	public void run() {
		try {
			while(true){
				lock.readLock().lock(); 
				if(type==2)
					System.out.println("父亲要查询，现在余额：" + bc.getBalance());
				else
					System.out.println("老妈要查询，现在余额：" + bc.getBalance());
				//lock.readLock().unlock();
				Thread.sleep(1 * 1000);
			}
		} catch (Exception e) {
			e.printStackTrace();
		}		
	}
}

 运行程序，儿子开始花钱，父母两人一直在查看花钱情况。

package com.thread;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;
import com.entity.BankCard;
public class MainThread {
	public static void main(String[] args) {
		BankCard bc = new BankCard();
		ReadWriteLock lock = new ReentrantReadWriteLock();
		ExecutorService pool = Executors.newCachedThreadPool();
		Consumer cm1 = new Consumer(bc, lock);
		Consumer2 cm2 = new Consumer2(bc, lock , 1);
		Consumer2 cm3 = new Consumer2(bc, lock , 2);
		pool.execute(cm1);
		pool.execute(cm2);
		pool.execute(cm3);
	}
}

 我们来看一下运行结果：

儿子要消费，现在余额：10000	儿子消费2000元，现在余额：8000
老妈要查询，现在余额：8000
父亲要查询，现在余额：8000
父亲要查询，现在余额：8000
老妈要查询，现在余额：8000
老妈要查询，现在余额：8000
父亲要查询，现在余额：8000
儿子要消费，现在余额：8000	儿子消费2000元，现在余额：6000
父亲要查询，现在余额：6000
老妈要查询，现在余额：6000
老妈要查询，现在余额：6000
父亲要查询，现在余额：6000
父亲要查询，现在余额：6000
老妈要查询，现在余额：6000
老妈要查询，现在余额：6000
儿子要消费，现在余额：6000	儿子消费2000元，现在余额：4000
父亲要查询，现在余额：4000

 读写锁是互斥的，但是对于读来说没有互斥性。

也就是说读和写必须分开，但是资源可以同时被几个线程访问。不管是读还是写没有释放锁，其他线程就一直等待锁的释放。

我们来注释父母监督时锁的释放：

lock.readLock().unlock();

 

儿子要消费，现在余额：10000	儿子消费2000元，现在余额：8000
父亲要查询，现在余额：8000
老妈要查询，现在余额：8000
老妈要查询，现在余额：8000
父亲要查询，现在余额：8000
老妈要查询，现在余额：8000
父亲要查询，现在余额：8000
老妈要查询，现在余额：8000
父亲要查询，现在余额：8000

 可以看到儿子花了一次钱后，父母把卡给锁了，儿子不能在花钱，但是父母两个人都可以一直查询卡的余额。 

 

请您到ITEYE看我的原创：http://cuisuqiang.iteye.com

或支持我的个人博客，地址：http://www.javacui.com

 

评论

2 楼 姑苏痴情 2012-05-10  

如何跟Condition联合在一起用呢？

1 楼 cuisuqiang 2012-03-20  

Lock请见：http://cuisuqiang.iteye.com/blog/1458754