并发编程之六：线程活跃性问题(死锁、活锁、饥饿
线程的活跃性
活跃性：线程的代码是有限的，但是由于某些原因线程的代码一直执行不完。如死锁。
活跃性包括3种现象：死锁、活锁、饥饿。
解决方案：
活锁：线程运行时间交错开(两个线程都睡眠随机的时间，达到一个线程运行完毕，另一个线程再运行的目的)
死锁，饥饿：ReentrantLock
多把锁(细粒度的锁)
我们前几篇博客都是使用一把锁，这样会有一些并发度上的问题。
多把不相干的锁
栗子：-间大屋子有两个功能:睡觉、学习，互不相干。
现在小南要学习，小女要睡觉，但如果只用一间屋子(- 个对象锁)的话，那么并发度很低就变成了串行的，但是小南学习与小女睡觉是完全不影响的，串行显然不是太好。
解决方法是准备多个房间(多个对象锁)。一个学习的房间，一个睡觉的房间，不同的锁保护不同的操作，这样能够增强并发度。
代码如下：因为他们是给不同的对象上的锁，所以他们之间的操作是互不干扰的，几乎是同时运行的。
注意：要做多把锁，的保证多个锁之间是没有业务关联的。
注意：要做多把锁，的保证多个锁之间是没有业务关联的。
将锁的粒度细分：
- 好处，是可以增强并发度
- 坏处，如果一个线程需要同时获得多把锁，就容易发生死锁
死锁(概念及排查工具)
死锁：两个线程都在等待对方执行完毕，才能再往下执行。
有这样的情况: 一个线程需要同时获取多把锁，这时就容易发生死锁。
t1线程获得A对象锁，接下来想获取B对象的锁。
t2线程获得B对象锁,接下来想获取A对象的锁。
如下代码：t1线程一上来就获得了A对象锁，t2一上来就获得了B对象的锁，然后在t1线程里无法获取B对象锁，因为B对象锁已经被线程t2所占用，而t2想要运行结束，的获取A锁，但是A被t1所占用于是双方都无法再继续执行。它们各自持有一把锁，但是想要获取对方的锁的时候就发生了死锁。
定位死锁
1、jstack（基于命令行）
2、jconsole（基于图形界面）
检测死锁可以使用jconsole工具, 或者使用jps定位进程id, 再用jstack定位死锁
点击idea的terminal窗口，
第一步：输入jps，第一列为线程id，第二列为线程所在的java类名称。
第二步：输入jstack 线程id
待补充…
哲学家就餐问题(导致死锁的著名问题)
哲学家就餐问题可以这样表述，假设有五位哲学家围坐在一张圆形餐桌旁，做以下两件事情之一：吃饭，或者思考。吃东西的时候，他们就停止思考，思考的时候也停止吃东西。餐桌中间有一大碗意大利面，每两个哲学家之间有一只餐叉。因为用一只餐叉很难吃到意大利面，所以假设哲学家必须用两只餐叉吃东西。他们只能使用自己左右手边的那两只餐叉。哲学家就餐问题有时也用米饭和筷子而不是意大利面和餐叉来描述，因为很明显，吃米饭必须用两根筷子。
ps:哲学家们要是知道他们和别人共用筷子，会被恶心死吗？
如下代码：会发生死锁问题
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.ReentrantLock;
/**
* @Author: llb
* @Date: 2021/7/13 16:53
*/
public class ReentrantLockTest4 {
private static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) throws InterruptedException {
ChopsTick c1 = new ChopsTick("1");
ChopsTick c2 = new ChopsTick("2");
ChopsTick c3 = new ChopsTick("3");
ChopsTick c4 = new ChopsTick("4");
ChopsTick c5 = new ChopsTick("5");
new Philosopher("苏格拉底", c1, c2).start();
new Philosopher("柏拉图", c2, c3).start();
new Philosopher("亚里士多德", c3, c4).start();
new Philosopher("赫拉克利特", c4, c5).start();
new Philosopher("阿基米德", c5, c1).start();
}
}
class Philosopher extends Thread {
ChopsTick left;
ChopsTick right;
public Philosopher(String name, ChopsTick left, ChopsTick right) {
super(name);
this.left = left;
this.right = right;
}
@Override
public void run() {
while (true) {
// 尝试获得左手筷子
synchronized (left) {
// 尝试获得右手筷子
synchronized (right) {
eat();
}
}
}
}
private void eat() {
log.log("eating...");
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
class ChopsTick {
public ChopsTick(String name) {
this.name = name;
}
String name;
@Override
public String toString() {
return "筷子{" + name + "}";
}
}
活锁
活锁出现在两个线程互相改变对方的结束条件，最后谁也无法结束，例如
活锁与死锁的区别：
死锁，两个线程互相持有对方想要的锁，导致两个线程都无法继续向下运行，两个线程都阻塞住了。
活锁：两个线程没有阻塞，它们都不断的使用cpu不断的运行，互相改变了对方的结束条件导致对方结束不了。
解决活锁的方法，让两个线程执行的时间交错，或者将睡眠时间改为随机数，达到把他们的执行时间交错开，第一个线程执行完了，第二个线程开始执行。
饥饿
接下来我们来看线程活跃性中的饥饿问题。
很多教程中把饥饿定义为，一个线程由于优先级太低，始终得不到CPU调度执行，也不能够结束，饥饿的情况不易演示，讲读写锁时会涉及饥饿问题
下面我讲一下我遇到的一个线程饥饿的例子，先来看看使用顺序加锁的方式解决之前的死锁问题。
解决方案： 顺序加锁的解决方案
ReentrantLock(解决死锁、活锁)
知己知彼，百战不殆，我们看下从它的单词意思学期。
entrant中文意思是重入，en表示：可。Lock：锁。
ReentrantLock：属于juc并发包下的一个重要类。
synchronized与ReentrantLock的区别
区别：与synchronized相比的不同点
相对于synchronized它具备如下特点
- 可中断
- 可以设置超时时间
- 可以设置为公平锁
- 支持多个条件变量
解释：
可中断：synchronized里：比如a线程拥有锁，b线程在等在锁，但是在a不释放所资源的前提下，没有方法让b线程不等待。synchronized不可以被中断，并不指synchronized方法不可中断，而是指，synchronized的等待不可以被中断。但是ReentrantLock可以。
可以设置超时时间：synchronized，如果一个线程获取一个锁，其他的没有获取锁的线程就一直等待下去了，直到获取到锁位置。但是ReentrantLock可以设置超时时间，到了一定时间我争取不到锁，我就去执行其他的逻辑，不能在一颗树上吊死啊。
可以设置为公平锁：所谓公平锁就是先进先出，防止线程饥饿的情况，比如大家排队，公平锁是按排队一个个来，而不是随机来，如果线程过多，随机来，有些线程可能一直得不到运行。
支持多个条件变量：这里的条件变量就是，相当于synchronized里有一个waitset(当条件不满足时线程等待的一个地方)，当条件不满足时，线程就在waitset里等待。而ReentrantLock是指，你不满足条件1的时候可以在一个地方等，不满足条件2的时候可以在另一个地方等,不满足条件3的时候…而synchronized相当于不管你不满足啥条件你都只能在一个地方等。当notifyAll叫醒线程的时候，它就叫醒一屋子的线程。不像ReentrantLock可以细分，可以指定叫醒哪些线程。
可重入：(ReentrantLock与synchronized的相同点)
可重入
可重入是指同一个线程如果首次获得了这把锁，那么因为它是这把锁的拥有者，因此有权利再次获取这把锁如果是不可重入锁，那么第二次获得锁时，自己也会被锁挡住。
基本语法
先获取一个reentrantLock对象。从这里就可以看出它它和synchronized不一样，synchronized是在关键字的级别去保护临界区，而reentrantLock是在对象的级别去保护临界区。
1、先获取一个reentrantLock对象
2、调用它的lock方法进行一个锁的获取。
3、将临界区写入到一个try-finally块里，然后在finally里不管有没有异常都释放掉锁。
注意：
1、一定要保证lock与unlock是成对出现的。其次要在finally里去释放锁。
至于加锁的lock方法放在try外面还是里面效果都是一样的，按自己喜欢来。
2、reentrantLock.lock()；就取代了之前的普通对象+monitor，如果线程没有得到锁，就会进入reentrantLock的头里去等待。
3、以前我们把synchronized的对象当成锁，但是真正的锁是monitor所关联的对象，但是现在呢,我们创建出来的这个ReentrantLock对象它就是一把锁。
private static ReentrantLock lock = new ReentrantLock();
如下代码
可重入是指同一个线程如果首次获得了这把锁，那么因为它是这把锁的拥有者，因此有权利再次获取这把锁如果是不可重入锁，那么第二次获得锁时，自己也会被锁挡住。所以正确结果就是，main线程可以在main方法里lock进入m1,当进入m1时执行lock.lock();方法时如果能成功执行，进入try，就说明可重入，m1调用m2也是同理。
import java.util.concurrent.locks.ReentrantLock;
/**
* @Author: llb
* @Date: 2021/7/13 14:54
*/
public class ReentrantLockTest1 {
private static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) {
lock.lock();
try {
System.out.println("method main");
m1();
} finally {
lock.unlock();
}
}
public static void m1() {
lock.lock();
try {
System.out.println("method m1");
m2();
} finally {
lock.unlock();
}
}
public static void m2() {
lock.lock();
try {
System.out.println("method m2");
} finally {
lock.unlock();
}
}
}
打印结果
可打断(被动解决死锁)
线程在等待锁的过程中，其它线程可以用interrupt去终止该线程的等待。
这个我们就不能用刚才的lock.lock了，因为它是不可被打断的锁。
这里我们使用lock.lockInterruptibly();
下面代码，我们正常调用，因为没有其它线程和它竞争锁资源，所以它不会被打断，正常执行同步带代码块里的内容，打印日志。
场景1：正常执行
import java.util.concurrent.locks.ReentrantLock;
/**
* @Author: llb
* @Date: 2021/7/13 14:54
*/
public class ReentrantLockTest2 {
private static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) {
Thread t1 = new Thread(() ->{
try {
// 如果没有竞争，那么此方法就会获取lock对象锁
// 如果有竞争就进入阻塞队列，可以被其它线程用 interrupt 方法打断，不在等待锁
System.out.println("尝试获得锁");
lock.lockInterruptibly();
} catch (InterruptedException e) {
// 如果被打断，则进入到catch里
// 正在等待中的线程，在其他线程调用interrupt方法时会被打断，
// 并且抛出打断异常，且将打断标志设置为false
e.printStackTrace();
System.out.println("没有获得锁");
return;
}
try{
System.out.println("获取到锁");
}finally {
lock.unlock();
}
}, "t1");
t1.start();
}
}
打印结果
场景2：被阻塞
import java.util.concurrent.locks.ReentrantLock;
/**
* @Author: llb
* @Date: 2021/7/13 14:54
*/
public class ReentrantLockTest2 {
private static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) {
Thread t1 = new Thread(() ->{
try {
// 如果没有竞争，那么此方法就会获取lock对象锁
// 如果有竞争就进入阻塞队列，可以被其它线程用 interrupt 方法打断，不在等待锁
System.out.println("尝试获得锁");
lock.lockInterruptibly();
} catch (InterruptedException e) {
// 如果被打断，则进入到catch里
// 正在等待中的线程，在其他线程调用interrupt方法时会被打断，
// 并且抛出打断异常，且将打断标志设置为false
e.printStackTrace();
System.out.println("没有获得锁");
return;
}
try{
System.out.println("获取到锁");
}finally {
lock.unlock();
}
}, "t1");
// 这里写lock.lock();是哪个线程获取的锁呢？
// 代码是在main方法里所以是主线程获取了该锁,
// 然后t1之后才启动，于是t1就被阻塞住了
lock.lock();
t1.start();
}
}
打印结果：
场景3：打断操作,意义：防止线程无限的等待下去，这也是避免死锁的一种方法。如果不可被打断，线程一直等待，就有可能产生死锁。
import java.util.concurrent.locks.ReentrantLock;
/**
* @Author: llb
* @Date: 2021/7/13 14:54
*/
public class ReentrantLockTest2 {
private static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() ->{
try {
// 如果没有竞争，那么此方法就会获取lock对象锁
// 如果有竞争就进入阻塞队列，可以被其它线程用 interrupt 方法打断，不在等待锁
System.out.println("尝试获得锁");
lock.lockInterruptibly();
} catch (InterruptedException e) {
// 如果被打断，则进入到catch里
// 正在等待中的线程，在其他线程调用interrupt方法时会被打断，
// 并且抛出打断异常，且将打断标志设置为false
e.printStackTrace();
System.out.println("没有获得锁");
return;
}
try{
System.out.println("获取到锁");
}finally {
lock.unlock();
}
}, "t1");
// 这里写lock.lock();是哪个线程获取的锁呢？
// 代码是在main方法里所以是主线程获取了该锁,
// 然后t1之后才启动，于是t1就被阻塞住了
lock.lock();
t1.start();
// 让主线程睡1s，然后打断t1
// 打断线程的方法，在其它线程里，运行该线程的interrupt方法
Thread.sleep(1000);
t1.interrupt();
}
}
打印结果：代码里我们可以看到，主线程并没有释放锁的代码，也就是说t1是不可能获取锁的，然后我们在主线程里把t1打断，让t1退出等待锁。防止线程无限的等待下去，这也是避免死锁的一种方法。如果不可被打断，就有可能产生死锁。
如果这里用的是lock而不是lockInterruptibly，线程会一直等待下去，不会被打断
如下代码：等待中的线程没有抛出异常，说明没有被打断，意味着，lock(）的锁是不可被打断的。
import java.util.concurrent.locks.ReentrantLock;
/**
* @Author: llb
* @Date: 2021/7/13 14:54
*/
public class ReentrantLockTest21 {
private static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
// 如果没有竞争，那么此方法就会获取lock对象锁
// 如果有竞争就进入阻塞队列，可以被其它线程用 interrupt 方法打断，不在等待锁
System.out.println("尝试获得锁");
lock.lock();
try {
System.out.println("获取到锁");
} finally {
lock.unlock();
}
}, "t1");
// 这里写lock.lock();是哪个线程获取的锁呢？
// 代码是在main方法里所以是主线程获取了该锁,
// 然后t1之后才启动，于是t1就被阻塞住了
lock.lock();
t1.start();
// 让主线程睡1s，然后打断t1
// 打断线程的方法，在其它线程里，运行该线程的interrupt方法
Thread.sleep(1000);
t1.interrupt();
}
}
打印结果：一直等待下去
可超时(主动解决死锁)
ReentrantLock的可打断是为了避免线程死等，但是可打断毕竟是一种被动的避免死等，由其它线程调用该线程的interrupt不让该线程死等，而锁超时，是主动的去避免死等。
可超时:如果其它线程一直持有锁不释放，我也不会一直死等，等待一段时间，如果这段时间过了，对方仍旧没有释放锁，那么我就放弃等待，表示这次获取锁失败了。可以避免线程无限制的等待下去。
lock.tryLock()方法：
- 无参：不超时等待。获取不到锁立即退出等待。
- 参数1：时间，参数2：时间单位。时间返回内获取不到锁退出等待。会提抛出InterruptedException异常。
- 支持被打断
以上两个方法都是避免死锁的解决方法
如下代码：
场景1：没有其它线程竞争锁
import java.util.concurrent.locks.ReentrantLock;
/**
* @Author: llb
* @Date: 2021/7/13 16:06
*/
public class ReentrantLockTest3 {
private static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
System.out.println("尝试获取锁...");
// tryLock方法，获取到锁返回true，反之false
if (!lock.tryLock()) {
System.out.println("获取不到锁");
return;
}
try {
System.out.println("获取到锁");
} finally {
lock.unlock();
}
}, "t1");
t1.start();
}
}
打印结果：
场景2：获取不到锁
import java.util.concurrent.locks.ReentrantLock;
/**
* @Author: llb
* @Date: 2021/7/13 16:06
*/
public class ReentrantLockTest3 {
private static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
System.out.println("尝试获取锁...");
// tryLock方法，获取到锁返回true，反之false
if (!lock.tryLock()) {
System.out.println("获取不到锁");
return;
}
try {
System.out.println("获取到锁");
} finally {
lock.unlock();
}
}, "t1");
lock.lock();
System.out.println("主线程获取到锁");
t1.start();
}
}
打印结果：
场景3：有时限的锁-获取不到锁
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.ReentrantLock;
/**
* @Author: llb
* @Date: 2021/7/13 16:06
*/
public class ReentrantLockTest3 {
private static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
log.log("尝试获取锁...");
try {
// tryLock方法，获取到锁返回true，反之false.tryLock也是支持被打断的
// 等待1s，如果获取到锁，返回true,等待1s,获取不到锁返回false
if (!lock.tryLock(1, TimeUnit.SECONDS)) {
log.log("获取不到锁");
return;
}
} catch (InterruptedException e) {
e.printStackTrace();
log.log("获取不到锁");
return;
}
try {
log.log("获取到锁");
} finally {
lock.unlock();
}
}, "t1");
lock.lock();
log.log("主线程获取到锁");
t1.start();
}
}
以上代码，在线程获取到锁的时候会返回true，打印“获得到锁”,如果获取不到锁等待1s，1s后获取到锁，同上，如果还是获取不到则返回false，打印“获取不到锁”。但是主线程根本就没有释放锁，所以t1永远都得不到锁。
打印结果：我们可以看到22秒时等待锁，1s后等待不到，于是放弃等待，在23s时，打印“获取不到锁”
场景3：有时限的等待-获取到锁
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.ReentrantLock;
/**
* @Author: llb
* @Date: 2021/7/13 16:06
*/
public class ReentrantLockTest3 {
private static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
log.log("尝试获取锁...");
try {
// tryLock方法，获取到锁返回true，反之false.tryLock也是支持被打断的
// 等待1s，如果获取到锁，返回true,等待1s,获取不到锁返回false
if (!lock.tryLock(2, TimeUnit.SECONDS)) {
log.log("获取不到锁");
return;
}
} catch (InterruptedException e) {
e.printStackTrace();
log.log("获取不到锁");
return;
}
try {
log.log("获取到锁");
} finally {
lock.unlock();
}
}, "t1");
lock.lock();
log.log("主线程获取到锁");
t1.start();
// 主线程睡1s,然后释放锁
Thread.sleep(1000);
log.log("主线程释放了锁");
lock.unlock();
}
}
打印结果：以上代码让主线程1s后释放锁，然后t1等待2s去获取锁资源，当然获取的到了
解决哲学家就餐问题(tryLock无参方法)
我们在死锁章节介绍了哲学家就餐问题的死锁现象，现在我们来解决了它。
synchronized虽然也能解决该问题，但是synchronized的等待不可以被中断，所以解决起来比较麻烦，比如让哲学家们有顺序的获取 筷子，或者在获取做左筷子之后，如果获取不到右筷子，可以等待一端时间(但是真实情况中，这个等待的时间是不好把握的)，但是显然ReentrantLock的可中断等待解决起来更方便。
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.ReentrantLock;
/**
* @Author: llb
* @Date: 2021/7/13 16:53
*/
public class ReentrantLockTest4 {
private static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) throws InterruptedException {
ChopsTick c1 = new ChopsTick("1");
ChopsTick c2 = new ChopsTick("2");
ChopsTick c3 = new ChopsTick("3");
ChopsTick c4 = new ChopsTick("4");
ChopsTick c5 = new ChopsTick("5");
new Philosopher("苏格拉底", c1, c2).start();
new Philosopher("柏拉图", c2, c3).start();
new Philosopher("亚里士多德", c3, c4).start();
new Philosopher("赫拉克利特", c4, c5).start();
new Philosopher("阿基米德", c5, c1).start();
}
}
class Philosopher extends Thread {
ChopsTick left;
ChopsTick right;
public Philosopher(String name, ChopsTick left, ChopsTick right) {
super(name);
this.left = left;
this.right = right;
}
@Override
public void run() {
while (true) {
// 尝试获取左手筷子
if (left.tryLock()) {
try {
// 尝试获取右手筷子
if (right.tryLock()) {
try {
// 两只筷子都有了，就可以吃饭了
eat();
} finally {
right.unlock();
}
}
} finally {
// 如果哲学家得不到右手的筷子，那么他会放下左手的筷子
// 然后就不会像synchronized一样去死等了。
// 也就避免的死锁的产生
// 释放手里的筷子
left.unlock();
}
}
// 尝试获得左手筷子
synchronized (left) {
// 尝试获得右手筷子
synchronized (right) {
eat();
}
}
}
}
private void eat() {
log.log(Thread.currentThread().getName() + ":eating...");
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
/**
* 以上代码中我们知道，哲学家们要先获取左筷子，再获取右筷子，然后才能吃饭，所以锁是加在筷子上的
* 我们要把筷子当成锁，但是又不想使用synchronized，那就只能，让它继承ReentrantLock
*/
class ChopsTick extends ReentrantLock {
public ChopsTick(String name) {
this.name = name;
}
String name;
@Override
public String toString() {
return "筷子{" + name + "}";
}
}
运行结果：你看他们每个人都吃到了饭，也不管筷子上有没有别人的口水，也不管恶心不恶心…
公平锁(解决饥饿问题)
公平锁的本意是用来解决饥饿问题的
synchronized的monitor锁属于不公平锁：所谓不公平锁就是，当拥有锁的线程释放锁资源时，其它等待的线程就会一拥而上，谁先抢到了，谁就是锁的主人。
所谓公平锁就是先进先出，防止线程饥饿的情况，当拥有锁的线程释放锁资源时，等待中的线程先等待的先得到锁，即先来先得到锁。比如大家排队，公平锁是按排队一个个来，而不是随机来，如果线程过多，随机来，有些线程可能一直得不到运行。
ReentrantLock默认是不公平锁。
首先我们看下ReentrantLock得源码，它得构造函数里有一个boolean类型得参数
有参构造函数里得fair(公平)默认为false。
如果fair为真它就创建一个FairSync的对象，为假，它就创建一个NonfairSync的对象。
注：公平锁一般没有必要，会降低并发度，等到后面分析原理时我们会啃源码，看公平锁是按先入先得来获取锁的。
ReentrantLock中的条件变量(避免虚假唤醒)
synchronized中也有和条件变量完全等价的概念,就是我们讲原理时那个waitSet休息室，当条件不满足时进入waitSet等待
ReentrantL ock的条件变量比synchronized强大之处在于，它是支持多个条件变量的,这就好比
- synchronized 是那些不满足条件的线程都在1间休息室等消息(所以唤醒时也只能随机唤醒或全部唤醒，哪些不满足唤醒的线程就成了虚假唤醒，他们还得再去循环再去等待)
- 而ReentrantL ock支持多间休息室，有专门]等烟的休息室、专门等早餐的休息室、唤醒时也是按休息室来唤醒。
使用流程
- await 前需要获得锁(和synchronized一样，想要进入这个休息室，你必须的先获得锁)
- await执行后，会释放锁,进入conditionObject等待
- await的线程被唤醒调用signal/signalAll(或打断、或超时)取重新竞争lock锁
- 竞争lock锁成功后，从await后继续执行
- ReentrantLock的await其实和synchronized的wait方法是类似的
代码示例：
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;
/**
* @Author: llb
* @Date: 2021/7/15 17:48
*/
public class ReentrantLockTest5 {
static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) throws InterruptedException {
// 休息室：不同业务逻辑的线程可以放在不同的休息室里
// 我们在唤醒它们的时候，就可以更准确的唤醒线程
// 而不是之前的类似于Synchronized的notifyAll唤醒所有的线程
// 或者notify随机的唤醒某一个线程
// 创建一个新的条件变量(相当于休息室)
Condition condition1 = lock.newCondition();
Condition condition2 = lock.newCondition();
Condition condition3 = lock.newCondition();
// 加锁
lock.lock();
// 等待：线程进入休息室等待
condition1.await();
// 唤醒：
// 其它线程想要唤醒，休息室1里的线程，就找到condition1
// 唤醒该休息室里随机的一个线程
condition1.signal();
// 唤醒该休息室里所有的线程
condition1.signalAll();
}
}
使用条件变量的例子:
收外卖和等烟的例子，我们用ReentrantLock来解决第四章中的等外卖和等烟的例子。
背景：一些线程他们要使用一个共享的房间来达到一个线程安全的目的。所以他们都要使用加锁的方式去进入到room房间去做些线程安全的代码。
前提条件：
人物 小南：正所谓，一根烟，一杯酒，一个bug调一宿，小南就是典型的有烟才能干活。所以小南的在有烟的前提下才能去干活。
下面我们就用一段代码来模拟这个过程。
条件变量(Condition)的使用例子
import com.carrotsearch.hppc.CharScatterSet;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;
/**
* @Author: llb
* @Date: 2021/7/15 18:04
*/
public class ReentrantLockTest6 {
static final Object room = new Object();
static boolean hasCigarette = false;// 有没有烟
static boolean hasTakeout = false; // 外卖
static ReentrantLock ROOM = new ReentrantLock();
// 等待烟的休息室
static Condition waitHasCigarette = ROOM.newCondition();
// 等待外卖的休息室
static Condition waitTakeout = ROOM.newCondition();
public static void main(String[] args) throws InterruptedException {
new Thread(new Runnable() {
@Override
public void run() {
ROOM.lock();
try {
log.log(Thread.currentThread().getName() + ":有烟没？ " + hasCigarette);
while (!hasCigarette) {
log.log(Thread.currentThread().getName() + ":没烟先歇会: " + hasCigarette);
// 这里不用之前的wait等待了，我们直接进入休息室等待
// 避免虚假唤醒，来个外卖，把两人都叫醒了，但是另一个人一看不是自己的，他有的去等待
waitHasCigarette.await();
}
log.log(Thread.currentThread().getName() + ":可以干活了: " + hasCigarette);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
ROOM.unlock();
}
}
}, "小南").start();
// 该线程与小南线程几乎一样，但是它等的是外卖而不是烟
new Thread(new Runnable() {
@Override
public void run() {
ROOM.lock();
try {
log.log(Thread.currentThread().getName() + ":外面送到没？ " + hasTakeout);
while (!hasTakeout) {
log.log(Thread.currentThread().getName() + ":没等待外卖先歇会: " + hasTakeout);
// 进入等待外卖的休息室：
// 避免虚假唤醒，来个外卖，把两人都叫醒了，但是另一个人一看不是自己的，他有的去等待
// 类似与synchronized里的wait但是这里，ReentrantLock分的更细，让该线程指定的到一个地方去等待
waitTakeout.await();
}
log.log(Thread.currentThread().getName() + ":可以干饭了: " + hasTakeout);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
ROOM.unlock();
}
}
}, "小女").start();
for (int i = 0; i < 5; i++) {
new Thread(new Runnable() {
@Override
public void run() {
synchronized (room) {
log.log(Thread.currentThread().getName() + ":可以干活了 " + hasCigarette);
}
}
}, "其他人").start();
}
Thread.sleep(1000);
// 该送外卖的线程到底将谁叫醒了呢?
new Thread(new Runnable() {
@Override
public void run() {
ROOM.lock();
try {
hasTakeout = true;
// 我们这里没有用signalAll方法是因为只有小女一个人在等待外卖
waitTakeout.signal();
log.log(Thread.currentThread().getName() + ":外卖到了 " + hasTakeout);
} finally {
ROOM.unlock();
}
}
}, "送外卖的").start();
// 该送烟的线程到底将谁叫醒了呢?
new Thread(new Runnable() {
@Override
public void run() {
ROOM.lock();
try {
hasCigarette = true;
// 我们这里没有用signalAll方法是因为只有小男一个人在等待烟
waitHasCigarette.signal();
log.log(Thread.currentThread().getName() + ":外卖到了 " + hasTakeout);
} finally {
ROOM.unlock();
}
}
}, "送外卖的").start();
}
}
运行结果：
其实synchronized与ReentrantLock很相似，前者的wait对应后者的await,前者的notify/notifyAll对应后者的signal/signalAll。只不过ReentrantLock将条件更细的划分了,synchronized里所有的线程都调用wait，但是ReentrantLock更细分了，它通过Condition(条件变量)让不同的线程在不同的Condition里等待，等到唤醒的时候，也是可以指定Condition去唤醒里面一个或者所有线程，避免唤醒条件不满足的线程，造成虚假唤醒。
我们再来看一下synchronized的解决方法对比一下
public class WaitTest4 {
static final Object room = new Object();
static boolean hasCigarette = false;// 有没有烟
static boolean hasTakeout = false; // 外卖
public static void main(String[] args) throws InterruptedException {
new Thread(new Runnable() {
@Override
public void run() {
synchronized (room) {
logger.log(Thread.currentThread().getName() + ":有烟没？ " + hasCigarette);
while (!hasCigarette) {
logger.log(Thread.currentThread().getName() + ":没烟先歇会: " + hasCigarette);
try {
room.wait();
} catch (InterruptedException e) {
// 该异常什么时候会抛出呢?就是其他线程调用interrupt方法
// 它也会让正在wait的线程被打断，打断之后，我们这边接到异常
// 就知道该线程被打断了,也可以对打断标记进行判断，于是可以继续进行处理。
// 当然了，更合理的方法是其他线程调用notify方法来唤醒
// 正在wait的线程
e.printStackTrace();
}
}
logger.log(Thread.currentThread().getName() + ":有烟没？ " + hasCigarette);
if (hasCigarette) {
logger.log(Thread.currentThread().getName() + ":可以干活了: " + hasCigarette);
} else {
logger.log(Thread.currentThread().getName() + ":没干成活: " + hasCigarette);
}
}
}
}, "小南").start();
// 该线程与小南线程几乎一样，但是它等的是外卖而不是烟
new Thread(new Runnable() {
@Override
public void run() {
synchronized (room) {
logger.log(Thread.currentThread().getName() + ":外面送到没？ " + hasTakeout);
while (!hasTakeout) {
logger.log(Thread.currentThread().getName() + ":没等待外卖先歇会: " + hasTakeout);
try {
room.wait();
} catch (InterruptedException e) {
// 该异常什么时候会抛出呢?就是其他线程调用interrupt方法
// 它也会让正在wait的线程被打断，打断之后，我们这边接到异常
// 就知道该线程被打断了,也可以对打断标记进行判断，于是可以继续进行处理。
// 当然了，更合理的方法是其他线程调用notify方法来唤醒
// 正在wait的线程
e.printStackTrace();
}
}
logger.log(Thread.currentThread().getName() + ":外面送到没？ " + hasTakeout);
if (hasTakeout) {
logger.log(Thread.currentThread().getName() + ":可以干饭了: " + hasTakeout);
} else {
logger.log(Thread.currentThread().getName() + ":没干成饭: " + hasTakeout);
}
}
}
}, "小女").start();
for (int i = 0; i < 5; i++) {
new Thread(new Runnable() {
@Override
public void run() {
synchronized (room) {
logger.log(Thread.currentThread().getName() +":可以干活了 " + hasCigarette);
}
}
},"其他人").start();
}
Thread.sleep(1000);
// 该送外卖的线程到底将谁叫醒了呢?
new Thread(new Runnable() {
@Override
public void run() {
synchronized (room) {
hasTakeout = true;
logger.log(Thread.currentThread().getName() +":外卖到了 " + hasTakeout);
// 这里要要注意，
// notify/notifyAll只能唤醒wait状态下的线程
// 对blocked状态下的线程毫无作用。
// 所以不管是wait还是notify/notifyAll，
// 他们都有一个前提就是线程都必须获得了对象锁。成为了owner之后才能调用这3个方法
// 所以这里要在synchronized代码块里调用notify，否则将抛出非法状态异常
//room.notify();
room.notifyAll();
}
}
},"送外卖的").start();
}
}
同步模式之顺序控制
至上面的一小节，我们已经学会了synchronized的wait，notify/notifyAll以及ReentrantLock的lock,unlock，await,single,singleAll,已经学会了线程之间的一些基本的同步控制了。经常会有一些面试题目，以及现实开发中遇到的一些问题。就是，在多个线程之间对它们的执行顺序进行一些协调，我们我们要学会下面这种模式，就是控制线程的运行次序。
场景：现在有两个线程一个线程打印1，另一个线程打印2，现在要求必须先打印2在打印1
下面我们就以不同的方式去实现它。
固定运行顺序1:wait¬ify版
/**
* @author diao 2021/7/15 22:42
*/
public class Test2 {
static final Object lock = new Object();
// 表示t2是否运行过
static boolean t2runned = false;
public static void main(String[] args) {
Thread t1 = new Thread(() -> {
// 为什么写在while里，这是我们前面学到的
// synchronized的wait的正确的使用姿势
synchronized (lock) {
// 当条件满足的时候，就跳出while打印结果
while (!t2runned) {
try {
lock.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
log.log("1");
}
}, "t1");
Thread t2 = new Thread(() -> {
synchronized (lock) {
log.log("2");
// 更改标记位
t2runned = true;
// 唤醒t1
lock.notifyAll();
}
}, "t2");
t1.start();
t2.start();
}
}
代码分析：
- 情况1
：是t1先运行，那么t2runned初始值为false，不满足条件，所以进入到while里执行wait释放锁资源，然后t1、t2竞争锁资源。如果是t1竞争到了，重复上述步骤，当t2竞争到所资源之后，打印结果，修改标记位为true，然后释放所资源，唤醒t1，t1不满足while条件，不会再wait，直接打印结果。
- 情况2
：t2先运行打印结果，修改标记位为true，然后释放所资源，唤醒t1（此时是个空唤醒，因为t1没有得到过锁，也就不会执行wait:注wait方法会释放线程拥有的所资源，所以调用wait的线程，一定是得到过锁资源的线程），t1不满足while条件，不会再wait，直接打印结果。
打印结果：总是先2再1
固定运行顺序2:await&signal&condition版
代码分析和上面简直一模一样，这里不在比比
import java.awt.*;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;
/**
* @author diao 2021/7/15 22:42
*/
public class Test3 {
static final ReentrantLock lock = new ReentrantLock();
static Condition condition1 = lock.newCondition();
// 表示t2是否运行过
static boolean t2runned = false;
public static void main(String[] args) {
Thread t1 = new Thread(() -> {
lock.lock();
try {
if(!t2runned) {
condition1.await();
}
log.log("1");
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}, "t1");
Thread t2 = new Thread(() -> {
lock.lock();
try {
log.log("2");
t2runned = true;
// 这里就一个线程
condition1.signalAll();
}finally {
lock.unlock();
}
}, "t2");
t1.start();
t2.start();
}
}
打印结果：总是先2再1
固定运行顺序3：park&unpark
import java.util.concurrent.locks.LockSupport;
/**
* @author diao 2021/7/15 23:10
*/
public class Test4 {
public static void main(String[] args) {
Thread t1 = new Thread(() -> {
// 暂停当前线程,park之后线程对应的是wait状态
LockSupport.park();
log.log("1");
}, "t1");
Thread t2 = new Thread(() -> {
log.log("2");
// 恢复某个线程的运行
LockSupport.unpark(t1);
}, "t2");
t1.start();
t2.start();
}
}
- 情况1
先运行线程1，线程1得到资源了，但是park，会是它暂停当前线程直到其它线程调用了unpark方法后它才会去执行。然后线程2就执行了，先打印2，然后在唤醒线程1,于是线程1会接着park之后的代码运行，于是打印1.
- 情况2
首先要明白unpark可以在park执行之前或者执行之后调用。不懂的请看并发编程之五中有关LockSupport的park&unpark部分。
原理之park & unpark
每个线程都有自己的-一个Parker对象(java层面是看不到得)，由三部分组成_ counter， cond 和 _mutex 打个比喻
线程就像一一个旅人，Parker 就像他随身携带的背包，条件变量就好比背包中的帐篷。counter 就好比背包中的备用干粮(0
为耗尽，1为充足)
调用park就是要看需不需要停下来歇息
1、如果备用干粮耗尽，那么钻进帐篷歇息
2、如果备用干粮充足，那么不需停留，继续前进
调用unpark,就好比令干粮充足
1、如果这时线程还在帐篷，就唤醒让他继续前进
2、如果这时线程还在运行，那么下次他调用park时，仅是消耗掉备用干粮，不需停留继续前进
2.1、因为背包空间有限，多次调用unpark仅会补充一份备用干粮
情况2：先执行线程2：此时线程2 在运行，打印2，然后调用unpark，然后线程1执行，当其调用park时，因为线程2已经调用过unpark了，所以线程1不会暂停，而是直接往下运行。简单的理解为，当有线程先调用unpark再调用park时，线程不会暂停而是继续执行。多次调用unpark，也只能保证紧跟着的下一次park不会暂停。
交替输出1：wait¬ify
场景：线程1输出a 5次，线程2输出b 5次，线程3输出c 5次。现在要求输出abcabcabcabcabc怎么实现？
代码如下：
/**
* @Author: llb
* @Date: 2021/7/16 23:12
*/
public class Test3 {
public static void main(String[] args) {
// 多个线程用同一把锁才能起到同步的作用
// 这里表示，初始打印flag为1的，一共打印5次
WaitNotify waitNotify = new WaitNotify(1, 5);
new Thread(()->{
waitNotify.print("a", 1 , 2);
}, "t1").start();
new Thread(()->{
waitNotify.print("b", 2 , 3);
}, "t2").start();
new Thread(()->{
waitNotify.print("c", 3 , 1);
}, "t3").start();
}
}
/**
* 输出内容 等待标记 下一个标记
* a 1 2
* b 2 3
* c 3 1
*/
class WaitNotify{
// 打印
public void print(String str, int waitFlag, int nextFlag) {
for (int i = 0; i < loopNumber; i++) {
// 因为要同步，所以要加锁
synchronized (this) {
// 为什么加while见wait/notify的正确使用姿势
// 判断传进来的waitFlag是不是应该运行的flag
while (waitFlag != flag) {
try {
// 如果得到锁资源的不是当前该运行的线程
// 那么就进行wait释放锁资源，让其他线程去竞争
this.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
// 打印内容
System.out.print(str);
// 将标志位设置为下一个要运行的标志
flag = nextFlag;
// 唤醒所有等待的线程
this.notifyAll();
}
}
}
// 等待标记
private int flag;
// 循环次数
private int loopNumber;
public WaitNotify(int flag, int loopNumber) {
this.flag = flag;
this.loopNumber = loopNumber;
}
}
打印结果：按照顺序abc共5次。
使用整数标记来控制该线程是等待还是继续向下运行，并且用了下一个标记，来控制下一个等待标记下一个该执行的线程。
交替输出2：ReentrantLock&Condition&await&signal
一下代码没啥好说的，有个小问题，为啥在主线程里不能直接调用a.signal呢？调用会报错。
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;
/**
* @author diao 2021/7/18 22:19
*/
public class Test5 {
public static void main(String[] args) throws InterruptedException {
AwaitSignal awaitSignal = new AwaitSignal(5);
Condition a = awaitSignal.newCondition();
Condition b = awaitSignal.newCondition();
Condition c = awaitSignal.newCondition();
new Thread(() -> {
awaitSignal.print("a", a, b);
}).start();
new Thread(() -> {
awaitSignal.print("b", b, c);
}).start();
new Thread(() -> {
awaitSignal.print("c", c, a);
}).start();
// 上面的3个线程进入print方法后全部都await了
// ReentrantLock会释放锁资源
Thread.sleep(1000);
// 为了确保上面3个线程全部陷入等待，我们让主线程睡眠1s
// 然后我们唤醒a休息室中的线程
// 小问题：既然是唤醒休息室中的线程，为啥要加锁呢，直接signal不就行了吗？
// 原理，进入singl方法，查看源码：getExclusiveOwnerThread()方法返回的是当前持有锁的线程，
// Thread.currentThread()取得的是当前的线程，所以当持有锁的线程不是当前线程时，
// isHeldExclusively()方法就会返回false，继而抛出IllegalMonitorStateException异常。
// 结论 调用signal()方法的线程一定要持有锁，否则会抛出IllegalMonitorStateException异常。
// 这里调用signal的代码写在了main方法里，所以是主线程调用的signal，所以主线程需要先获取锁
awaitSignal.lock();
try {
a.signal();
} finally {
awaitSignal.unlock();
}
}
}
class AwaitSignal extends ReentrantLock {
private int loopNumber;
public AwaitSignal(int loopNumber) {
this.loopNumber = loopNumber;
}
public void print(String str, Condition current, Condition next) {
for (int i = 0; i < loopNumber; i++) {
lock();
try {
current.await();
System.out.print(str);
next.signal();
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
unlock();
}
}
}
}
交替输出3：park&unpark
park与unpark。它没有对象锁的概念也没有ReentrantLock锁的概念。它停止和恢复线程的运行都是以线程自身为单位的。
import java.util.concurrent.locks.LockSupport;
/**
* @author diao 2021/7/19 23:13
*/
public class Test6 {
static Thread t1;
static Thread t2;
static Thread t3;
public static void main(String[] args) {
ParkUnpark pu = new ParkUnpark(5);
t1 = new Thread(() -> {
pu.print("a", t2);
});
t2 = new Thread(() -> {
pu.print("b", t3);
});
t3 = new Thread(() -> {
pu.print("c", t1);
});
// 他们刚开始运行的时候都是阻塞的
t1.start();
t2.start();
t3.start();
// 唤醒t1
LockSupport.unpark(t1);
}
}
class ParkUnpark {
public void print(String str, Thread next) {
for (int i = 0; i < loopNumber; i++) {
// 让当前线程阻塞
LockSupport.park();
// 当它被唤醒的时候去打印内容
System.out.print(str);
// 唤醒下一个该执行的线程
LockSupport.unpark(next);
}
}
private int loopNumber;
public ParkUnpark(int loopNumber) {
this.loopNumber = loopNumber;
}
}
本篇小结
-
1、掌握死锁、活锁、饥饿问题产生的原因，及其解决方法
-
2、synchronized与ReentrantLock的区别与相同点
-
ReentrantLock与synchronized区别：
1、可被打断 lock.lockInterruptibly();//被动解决死锁 2、可以设置超时间 lock.tryLock();//主动解决死锁 3、可以设置公平锁 new ReentrantLock(true);//解决饥饿问题 4、支持多个条件变量 lock.newCondition();//避免虚假唤醒
本章小结
算是对第四、五、六章的一个小结
并发编程之四：并发之共享问题、线程安全、synchronized关键字
并发编程之五：synchronized底层原理、monitor、轻量级锁、偏向锁、wati/notify/notifyAll、join、状态转换
并发编程之六：RenentrantLock线程活跃性问题(死锁、活锁、饥饿),线程执行顺序
本章小结
本章我们需要重点掌握的是
-
分析多线程访问共享资源时，哪些代码片段属于临界区
-
使用synchronized互斥解决临界区的线程安全问题
1、掌握synchronized锁对象语法 2、掌握synchronzied 加载成员方法和静态方法语法 3、掌握wait/notify 同步方法 4、互斥与同步虽然都是synchronized但是解决的问题不一样 互斥：解决临界区的代码由于线程上下文切换导致的指令交错的问题。 同步：某一个条件不满足时，想让线程等待 -
使用lock(ReentrantLock)互斥解决临界区的线程安全问题
掌握lock的使用细节:可打断、锁超时(try-lock)、公平锁(ReentrantLock默认非公平)、条件变量 -
学会分析变量的线程安全性、掌握常见线程安全类的使用(所谓线程安全性，他们的内部方法添加了synchronized方法内部代码就原子的，但是这么多个同步的方法放在一起缺不是原子的)
-
了解线程活跃性问题:死锁、活锁、饥饿
-
应用方面
互斥:使用synchronized或Lock达到共享资源互斥效果(保证临界区内的代码是原子效果，不会受 到线程上下文切换的干扰)。 同步:使用wait/notify或Lock的条件变量来达到线程间通信效果。 -
原理方面
1、monitor(锁,它是jvm层面实现的，c++实现，ReentrantLock便是java级别实现的)、synchroized原理、 wait/notifv原理 2、synchronized 进阶原理(重量级锁、轻量级锁、偏向锁、锁膨胀等) 3、park & unpark原理 -
模式方面
1、同步模式之保护性暂停：两个线程之间传递结果，比如线程1需要获得线程2的结果（一一对应） 2、异步模式之生产者消费者：结果产生者和消费者不是一一对应 3、同步模式之顺序控制:控制线程的执行顺序，让他们顺序执行或者交替执行
578
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
