Java开发笔记（一百零一）通过加解锁避免资源冲…
2019-05-23 09:56:18来源：博客园 阅读 ()
前面介绍了如何通过线程同步来避免多线程并发的资源冲突问题，然而添加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开发笔记（序）章节目录》
原文链接:https://www.cnblogs.com/pinlantu/p/10907989.html
如有疑问请与原作者联系
标签：
版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有
上一篇：Java基础--正则表达式的规则
下一篇：java_注解
- 国外程序员整理的Java资源大全（全部是干货） 2020-06-12
- 2020年深圳中国平安各部门Java中级面试真题合集（附答案） 2020-06-11
- 2020年java就业前景 2020-06-11
- 04.Java基础语法 2020-06-11
- Java--反射(框架设计的灵魂)案例 2020-06-11
IDC资讯： 主机资讯 注册资讯 托管资讯 vps资讯 网站建设
网站运营： 建站经验 策划盈利 搜索优化 网站推广 免费资源
网络编程： Asp.Net编程 Asp编程 Php编程 Xml编程 Access Mssql Mysql 其它
服务器技术： Web服务器 Ftp服务器 Mail服务器 Dns服务器 安全防护
软件技巧： 其它软件 Word Excel Powerpoint Ghost Vista QQ空间 QQ FlashGet 迅雷
网页制作： FrontPages Dreamweaver Javascript css photoshop fireworks Flash
