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开发笔记(序)章节目录

posted @ 2019-05-22 19:23  pinlantu  阅读(233)  评论(0编辑  收藏  举报