Java开发笔记（一百零一）通过加解锁避免资源冲突

前面介绍了如何通过线程同步来避免多线程并发的资源冲突问题，然而添加synchronized的方式只在简单场合够用，在一些高级场合就暴露出它的局限性，包括但不限于下列几点：
1、synchronized必须用于修饰方法或者代码块，也就是一定会有花括号把需要同步的代码给包裹起来。这样的话，花括号内外的变量交互比较麻烦，特别是同步代码块，多出来的花括号硬生生把原来的代码隔离开，只好通过局部变量来传递数值。
2、synchronized的同步方式很傻，一旦同步方法/代码块被某个线程执行，其它线程到了这里就必须等待前个线程的处理，要是前个线程迟迟不退出同步方法/代码块，那么其它线程只能傻傻的一直等下去。
3、synchronized无法判断当前线程处于等待队列中的哪个位置，等待队列要是很长的话，也许走另外一条分支更合适，但synchronized是个死脑筋，它不知道等待队列的详细情况，也就无从选择更优的代码路径。
为此Java又设计了一套锁机制，通过锁的对象把加锁和解锁操作分离开，从而解决同步方式的弊端。锁机制提供了好几把锁，最常见的名叫可重入锁ReentrantLock，所谓可重入，字面意思指的是支持重新进入，凡是遇到被当前线程自身锁住的代码，则仍然允许进入这块代码；但要是遇到被其它线程锁住的代码，则不允许进入那块代码。换句话说，加锁不是为了锁自己，加锁是为了锁别人，故而可重入锁又称作自旋锁，之前介绍的synchronized也属于可重入机制。下面是ReentrantLock相关的锁方法说明：
lock：对可重入锁加锁。
unlock：对可重入锁解锁。
tryLock：尝试加锁。加锁成功返回true，加锁失败返回false。该方法与lock的区别在于：lock方法会一直等待加锁，而tryLock要求立刻加锁，要是加锁失败（表示之前已经被其它线程加了锁），就马上返回false，一会都等不了。
isLocked：判断该锁是否被锁住了。
getQueueLength：获取有多少个线程正在等待该锁的释放。
回到售票线程的例子，现在把同步方式改为加锁解锁的实现，修改后的售票代码示例如下：

	// 创建一个可重入锁
	private final static ReentrantLock reentrantLock = new ReentrantLock();

	// 测试通过可重入锁避免资源冲突
	private static void testReentrantLock() {
		Runnable seller = new Runnable() {
			private Integer ticketCount = 100; // 可出售的车票数量
			
			@Override
			public void run() {
				while (ticketCount > 0) { // 还有余票可供出售
					reentrantLock.lock(); // 对可重入锁加锁
					int count = --ticketCount; // 余票数量减一
					reentrantLock.unlock(); // 对可重入锁解锁
					// 以下打印售票日志，包括售票时间、售票线程、当前余票等信息
					String left = String.format("当前余票为%d张", count);
					PrintUtils.print(Thread.currentThread().getName(), left);
				}
			}
		};
		new Thread(seller, "售票线程A").start(); // 启动售票线程A
		new Thread(seller, "售票线程B").start(); // 启动售票线程B
		new Thread(seller, "售票线程C").start(); // 启动售票线程C
	}

以上采用锁机制的代码，运行起来没什么问题。可是实际业务往往不会这么简单，比如售票员在售票前还要帮旅客挑选合适的行程，这样又会消耗一定时间。通过编码演示的话，可在售票之前打开某个磁盘文件，模拟售票前的准备工作。于是添加模拟代码后的run方法变成了下面这副模样：

			public void run() {
				while (ticketCount > 0) { // 还有余票可供出售
					int count = 0;
					// 根据指定路径构建文件输出流对象
					try (FileOutputStream fos = new FileOutputStream(mFileName)) {
						reentrantLock.lock(); // 对可重入锁加锁
						count = --ticketCount; // 余票数量减一
						reentrantLock.unlock(); // 对可重入锁解锁
						fos.write(new String(""+count).getBytes()); // 把字节数组写入文件输出流
					} catch (Exception e) {
						e.printStackTrace();
					}
					// 以下打印售票日志，包括售票时间、售票线程、当前余票等信息
					String left = String.format("当前余票为%d张", count);
					PrintUtils.print(Thread.currentThread().getName(), left);
				}
			}

 

接着运行上述的模拟代码，在售票日志中经常发现以下的负数余票：

………………………这里省略前面的日志……………………
17:12:06.568 售票线程C 当前余票为3张
17:12:06.569 售票线程B 当前余票为2张
17:12:06.569 售票线程A 当前余票为1张
17:12:06.570 售票线程B 当前余票为0张
17:12:06.570 售票线程A 当前余票为-1张
17:12:06.570 售票线程C 当前余票为-2张

 

明明每次循环之前都有判断余票数量要大于零，为啥还会出现车票被卖到负数的情况？真是咄咄怪事。原来在循环开始之后到对余票减一之间，多了一个打开文件的步骤，正是因为文件的打开操作耗费了一点点时间，导致其它线程在这一瞬间卖掉车票，而当前线程以为还有余票可卖，其结果必然导致卖出了早就卖光的车票。譬如当前线程在循环开始前检查余票数量为1，认为有票可卖，于是开始给旅客选择车票，谁知别的线程刚好在这空挡卖掉最后一张票，那么实时的余票数量减少到0，可是当前线程浑然不知，继续后面的选票与售票操作，最终又卖掉了一张票，此时余票数量刷新为-1。显然在每次循环开头检查余票不够保险，还得在选票之后售票之前再检查一次，务必确保还有余票才能进行售票操作。
鉴于检查余票和售出车票的性质有所不同，检查余票不会更改余票变量，所以它属于读操作；而售出车票会更改余票变量，所以它属于写操作。理论上可以同时进行读操作，但不能同时进行写操作。更具体地说，A线程在读的时候，B线程允许读但不允许写；A线程在写的时候，B线程既不允许读也不允许写。据此可将锁再细分为读锁和写锁两类，读锁与读锁不是互斥关系，而读锁与写锁是互斥关系，且写锁与写锁也是互斥关系。总而言之，检查余票这项操作适用于读锁，售出车票这项操作适用于写锁。
Java提供的读写锁工具名叫ReentrantReadWriteLock，意即可重入的读写锁，调用读写锁对象的readLock方法可获得读锁对象，调用读写锁对象的writeLock方法可获得写锁对象，之后再根据实际情况分别对读锁或者写锁进行加锁和解锁操作。利用读写锁优化之前的售票逻辑，主要开展以下两点修改：
1、在售票（余票数量减一）这一步骤的前面加上写锁，该步骤后面解除写锁。
2、售票之前补充检查余票的判断语句，并在检查步骤的前面加上读锁，该步骤后面解除读锁。
通过读写锁优化修改后的完整售票代码如下所示：

	// 创建一个可重入的读写锁
	private final static ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
	// 获取读写锁中的写锁
	private final static WriteLock writeLock = readWriteLock.writeLock();
	// 获取读写锁中的读锁
	private final static ReadLock readLock = readWriteLock.readLock();

	// 测试通过读写锁避免资源冲突
	private static void testReadWriteLock() {
		Runnable seller = new Runnable() {
			private Integer ticketCount = 100; // 可出售的车票数量
			
			@Override
			public void run() {
				while (ticketCount > 0) { // 还有余票可供出售
					int count = 0;
					// 根据指定路径构建文件输出流对象
					try (FileOutputStream fos = new FileOutputStream(mFileName)) {
						readLock.lock(); // 对读锁加锁。加了读锁之后，其它线程可以继续加读锁，但不能加写锁
						if (ticketCount <= 0) { // 余票数量为0，表示已经卖光了，只好关门歇业
							fos.close(); // 关闭文件
							break; // 跳出售票的循环
						}
						readLock.unlock(); // 对读锁解锁
						writeLock.lock(); // 对写锁加锁。一旦加了写锁，则其它线程在此既不能读也不能写
						count = --ticketCount; // 余票数量减一
						writeLock.unlock(); // 对写锁解锁
						fos.write(new String(""+count).getBytes()); // 把字节数组写入文件输出流
					} catch (Exception e) {
						e.printStackTrace();
					}
					// 以下打印售票日志，包括售票时间、售票线程、当前余票等信息
					String left = String.format("当前余票为%d张", count);
					PrintUtils.print(Thread.currentThread().getName(), left);
				}
			}
		};
		new Thread(seller, "售票线程A").start(); // 启动售票线程A
		new Thread(seller, "售票线程B").start(); // 启动售票线程B
		new Thread(seller, "售票线程C").start(); // 启动售票线程C
	}

运行上面的读写锁售票代码，从打印的售票日志中再也找不到余票为负数的情况了，可见读写锁很好地解决了盲目售票的问题。

………………………这里省略前面的日志……………………
16:29:44.899 售票线程C 当前余票为3张
16:29:44.899 售票线程B 当前余票为2张
16:29:44.899 售票线程A 当前余票为1张
16:29:44.900 售票线程C 当前余票为0张

　　

更多Java技术文章参见《Java开发笔记（序）章节目录》