并发编程之六：ReentrantLock线程活跃性问题(死锁、活锁、饥饿),线程执行顺序

最新推荐文章于 2024-08-19 21:26:48 发布

java_xxxx

最新推荐文章于 2024-08-19 21:26:48 发布

阅读量1k

点赞数 1

分类专栏： # 多线程高并发_java 文章标签：线程活跃性问题 ReentrantLock 死锁、活锁、饥饿线程执行顺序

本文链接：https://blog.csdn.net/java_xxxx/article/details/118331252

版权

多线程高并发_java 专栏收录该内容

7 篇文章 1 订阅

订阅专栏

线程的活跃性

活跃性：线程的代码是有限的，但是由于某些原因线程的代码一直执行不完。如死锁。
活跃性包括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&notify版

/**
 * @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&notify

场景：线程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、同步模式之顺序控制:控制线程的执行顺序，让他们顺序执行或者交替执行

java_xxxx

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

专栏目录

并发编程之六：ReentrantLock线程活跃性问题(死锁、活锁、饥饿),线程执行顺序

并发编程之六：线程活跃性问题(死锁、活锁、饥饿

线程的活跃性

多把锁(细粒度的锁)

死锁(概念及排查工具)

哲学家就餐问题(导致死锁的著名问题)

活锁

饥饿

ReentrantLock(解决死锁、活锁)

synchronized与ReentrantLock的区别

可重入：(ReentrantLock与synchronized的相同点)

可打断(被动解决死锁)

可超时(主动解决死锁)

解决哲学家就餐问题(tryLock无参方法)

公平锁(解决饥饿问题)

ReentrantLock中的条件变量(避免虚假唤醒)

条件变量(Condition)的使用例子

同步模式之顺序控制

固定运行顺序1:wait&notify版

固定运行顺序2:await&signal&condition版

固定运行顺序3：park&unpark

交替输出1：wait&notify

交替输出2：ReentrantLock&Condition&await&signal

本篇小结

本章小结