6.java并发编程之park&unpark与ReentrantLock

最新推荐文章于 2025-08-18 14:58:18 发布

然而,然而

最新推荐文章于 2025-08-18 14:58:18 发布

阅读量477

点赞数

CC 4.0 BY-SA版权

文章标签： java 开发语言算法

本文链接：https://blog.csdn.net/qq_30635523/article/details/131325734

☆1.Park & Unpark

基本使用

它们是 LockSupport 类中的方法

// 暂停当前线程 LockSupport.park(); // 恢复t1线程的运行 LockSupport.unpark(t1)

//先 park 再 unpark：先暂停再继续往下执行 Thread t1 = new Thread(() -> { log.debug("start..."); sleep(1); log.debug("park..."); LockSupport.park(); log.debug("resume..."); } ,"t1"); t1.start(); sleep(2); log.debug("unpark..."); LockSupport.unpark(t1); 输出： 18:42:52.585 c.TestParkUnpark [t1] - start... 18:42:53.589 c.TestParkUnpark [t1] - park... 18:42:54.583 c.TestParkUnpark [main] - unpark... 18:42:54.583 c.TestParkUnpark [t1] - resume...

//先 unpark 再 park:发现park还是继续往下执行 Thread t1 = new Thread(() -> { log.debug("start..."); sleep(2); log.debug("park..."); LockSupport.park(); log.debug("resume..."); } , "t1"); t1.start(); sleep(1); log.debug("unpark..."); LockSupport.unpark(t1); 18:43:50.765 c.TestParkUnpark [t1] - start... 18:43:51.764 c.TestParkUnpark [main] - unpark... 18:43:52.769 c.TestParkUnpark [t1] - park... 18:43:52.769 c.TestParkUnpark [t1] - resume...

特点

与 Object 的 wait & notify 相比 -wait，notify 和 notifyAll 必须配合 Object Monitor 一起使用，而 park，unpark 不必 -park & unpark 是以线程为单位来【阻塞】和【唤醒】线程，而 notify 只能随机唤醒一个等待线程，notifyAll是唤醒所有等待线程，就不那么【精确】 -park & unpark 可以先 unpark，而 wait & notify 不能先 notify

原理

每个线程都有自己的一个 Parker 对象，由三部分组成 counter ，cond 和 _mutex 。

打个比喻线程就像一个旅人，Parker 就像他随身携带的背包， cond条件变量就好比背包中的帐篷。counter 就好比背包中的备用干粮,0 为没有干粮或者干粮被耗尽，1 为干粮充足,默认是没有干粮的即0。

调用 park 的时候就是看有没有干粮。

调用 unpark，就好比令干粮充足。

1.如果备用干粮耗尽，那么钻进帐篷歇息 2.如果备用干粮充足，那么不需停留，继续前进 -调用unpark，就好比令干粮充足 1.如果这时线程还在帐篷即在park状态，就唤醒让他继续前进。 2.如果这时线程还在运行，那么下次他调用 park 时，仅是消耗掉备用干粮，不需停留继续前进 3.因为背包空间有限，多次调用 unpark 仅会补充一份备用干粮

先调用unpark再调用park,会先补充1份干粮,然后在调用park的时候不会停留而是继续前进。

先调用park再调用unpark,会先停留,等调用unpark的时候补充1份干粮继续前进。

其实park/unpark的设计原理核心是“许可”：park是等待一个许可，unpark是为某线程提供一个许可。如果某线程A调用park，那么除非另外一个线程调用unpark(A)给A一个许可，否则线程A将阻塞在park操作上。有一点比较难理解的，是unpark操作可以再park操作之前。也就是说，先提供许可。当某线程调用park时，已经有许可了，它就消费这个许可，然后可以继续运行。这其实是必须的。考虑最简单的生产者(Producer)消费者(Consumer)模型：Consumer需要消费一个资源，于是调用park操作等待；Producer则生产资源，然后调用unpark给予Consumer使用的许可。非常有可能的一种情况是，Producer先生产，这时候Consumer可能还没有构造好(比如线程还没启动，或者还没切换到该线程)。那么等Consumer准备好要消费时，显然这时候资源已经生产好了，可以直接用，那么park操作当然可以直接运行下去。如果没有这个语义，那将非常难以操作。但是这个“许可”是不能叠加的，“许可”是一次性的。比如线程B连续调用了三次unpark函数，当线程A调用park函数就使用掉这个“许可”，如果线程A再次调用park，则进入等待状态。

源码分析链接：https://www.jianshu.com/p/e3afe8ab8364

当前线程调用 Unsafe.park() 方法
检查 _counter ，本情况为 0，这时，获得 _mutex 互斥锁
线程进入 _cond 条件变量阻塞
设置 _counter = 0

调用 Unsafe.unpark(Thread_0) 方法，设置 _counter 为 1
唤醒 cond 条件变量中的 Thread0
Thread_0 恢复运行
设置 _counter 为 0

调用 Unsafe.unpark(Thread_0) 方法，设置 _counter 为 1
当前线程调用 Unsafe.park() 方法
检查 _counter ，本情况为 1，这时线程无需阻塞，继续运行
设置 _counter 为 0

多把锁

多把不相干的锁

一间大屋子有两个功能：睡觉、学习，互不相干。

现在小南要学习，小女要睡觉，但如果只用一间屋子即一个对象锁的话，那么并发度很低

解决方法是准备多个房间即多个对象锁。例如

class BigRoom { public void sleep() { synchronized (this) { log.debug("sleeping 2 小时"); Sleeper.sleep(2); } } public void study() { synchronized (this) { log.debug("study 1 小时"); Sleeper.sleep(1); } } } //执行 BigRoom bigRoom = new BigRoom(); new Thread(() -> { bigRoom. study (); } ,"小南").start(); new Thread(() -> { bigRoom.sleep(); } ,"小女").start();

改进以后,多个锁版本

class BigRoom { private final Object studyRoom = new Object(); private final Object bedRoom = new Object(); public void sleep() { synchronized (bedRoom) { log.debug("sleeping 2 小时"); Sleeper.sleep(2); } } public void study() { synchronized (studyRoom) { log.debug("study 1 小时"); Sleeper.sleep(1); } } } //执行 BigRoom bigRoom = new BigRoom(); new Thread(() -> { bigRoom. study(); } ,"小南").start(); new Thread(() -> { bigRoom.sleep(); } ,"小女").start();

将锁的粒度细分

好处，是可以增强并发度

坏处，如果一个线程需要同时获得多把锁，就容易发生死锁

☆活跃性问题

包括死锁、活锁、饥饿

死锁：迎面开来的汽车A和汽车B过马路，汽车A得到了半条路的资源(满足死锁发生条件1：资源访问是排他性的，我占了路你就不能上来，除非你爬我头上去)，汽车B占了汽车A的另外半条路的资源，A想过去必须请求另一半被B占用的道路(死锁发生条件2：必须整条车身的空间才能开过去，我已经占了一半，尼玛另一半的路被B占用了)，B若想过去也必须等待A让路，A是辆兰博基尼，B是开奇瑞QQ的屌丝，A素质比较低开窗对B狂骂：快给老子让开，B很生气，你妈的，老子就不让(死锁发生条件3：在未使用完资源前，不能被其他线程剥夺)，于是两者相互僵持一个都走不了(死锁发生条件4：环路等待条件)，而且导致整条道上的后续车辆也走不了。活锁：马路中间有条小桥，只能容纳一辆车经过，桥两头开来两辆车A和B，A比较礼貌，示意B先过，B也比较礼貌，示意A先过，结果两人一直谦让谁也过不去。在“首堵”北京的某一天，天气阴沉，空气中充斥着雾霾和地沟油的味道，某个苦逼的临时工交警正在处理塞车，有两条道A和B上都堵满了车辆，其中A道堵的时间最长，B相对相对堵的时间较短，这时，前面道路已疏通，交警按照最佳分配原则，示意B道上车辆先过，B道路上过了一辆又一辆，A道上排队时间最长的确没法通过，只能等B道上没有车辆通过的时候再等交警发指令让A道依次通过，这也就是ReentrantLock显示锁里提供的不公平锁机制(当然了，ReentrantLock也提供了公平锁的机制，由用户根据具体的使用场景而决定到底使用哪种锁策略)，非公平锁能够提高吞吐量但不可避免的会造成某些线程的饥饿。

活锁

public class TestLiveLock { static volatile int count = 10; static final Object lock = new Object(); public static void main(String[] args) { new Thread(() -> { // 期望减到 0 退出循环 while (count > 0) { sleep(0.2); count--; log.debug("count: {}", count); } } , "t1").start(); new Thread(() -> { // 期望超过 20 退出循环 while (count < 20) { sleep(0.2); count++; log.debug("count: {}", count); } } , "t2").start(); } }

死锁

有这样的情况：一个线程需要同时获取多把锁，这时就容易发生死锁

Object A = new Object(); Object B = new Object(); Thread t1 = new Thread(() -> { synchronized (A) { log.debug("lock A"); sleep(1); synchronized (B) { log.debug("lock B"); log.debug("操作..."); } } } , "t1"); Thread t2 = new Thread(() -> { synchronized (B) { log.debug("lock B"); sleep(0.5); synchronized (A) { log.debug("lock A"); log.debug("操作..."); } } } , "t2"); t1.start(); t2.start();

结果： 12:22:06.962 [t2] c.TestDeadLock - lock B 12:22:06.962 [t1] c.TestDeadLock - lock A

定位死锁

``` 定位死锁 1.检测死锁可以使用 jconsole工具，或者使用 jps 定位进程 id， 2.用 jstack 定位死锁. 一、使用jps查看进程 cmd > jps Picked up JAVATOOLOPTIONS: -Dfile.encoding=UTF-8 12320 Jps 22816 KotlinCompileDaemon 33200 TestDeadLock // JVM 进程 11508 Main 28468 Launcher 二、使用jstack 查看进程下的线程 cmd > jstack 33200 Picked up JAVATOOLOPTIONS: -Dfile.encoding=UTF-8 2018-12-29 05:51:40 Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.91-b14 mixed mode): "DestroyJavaVM" #13 prio=5 osprio=0 tid=0x0000000003525000 nid=0x2f60 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Thread-1" #12 prio=5 osprio=0 tid=0x000000001eb69000 nid=0xd40 waiting for monitor entry [0x000000001f54f000] java.lang.Thread.State: BLOCKED (on object monitor) at thread.TestDeadLock.lambda$main$1(TestDeadLock.java:28) - waiting to lock <0x000000076b5bf1c0> (a java.lang.Object) - locked <0x000000076b5bf1d0> (a java.lang.Object) at thread.TestDeadLock$$Lambda$2/883049899.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) "Thread-0" #11 prio=5 os_prio=0 tid=0x000000001eb68800 nid=0x1b28 waiting for monitor entry [0x000000001f44f000] java.lang.Thread.State: BLOCKED (on object monitor) at thread.TestDeadLock.lambda$main$0(TestDeadLock.java:15) - waiting to lock <0x000000076b5bf1d0> (a java.lang.Object) - locked <0x000000076b5bf1c0> (a java.lang.Object) at thread.TestDeadLock$$Lambda$1/495053715.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) // 略去部分输出

Found one Java-level deadlock:

"Thread-1": waiting to lock monitor 0x000000000361d378 (object 0x000000076b5bf1c0, a java.lang.Object), which is held by "Thread-0" "Thread-0": waiting to lock monitor 0x000000000361e768 (object 0x000000076b5bf1d0, a java.lang.Object), which is held by "Thread-1"

Java stack information for the threads listed above:

"Thread-1": at thread.TestDeadLock.lambda$main$1(TestDeadLock.java:28) - waiting to lock <0x000000076b5bf1c0> (a java.lang.Object) - locked <0x000000076b5bf1d0> (a java.lang.Object) at thread.TestDeadLock$$Lambda$2/883049899.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) "Thread-0": at thread.TestDeadLock.lambda$main$0(TestDeadLock.java:15) - waiting to lock <0x000000076b5bf1d0> (a java.lang.Object) - locked <0x000000076b5bf1c0> (a java.lang.Object) at thread.TestDeadLock$$Lambda$1/495053715.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) Found 1 deadlock. ```

哲学家就餐问题:死锁

有五位哲学家，围坐在圆桌旁。

他们只做两件事，思考和吃饭，思考一会吃口饭，吃完饭后接着思考。

吃饭时要用两根筷子吃，桌上共有 5 根筷子，每位哲学家左右手边各有一根筷子。

如果筷子被身边的人拿着，自己就得等待

``` class Chopstick { String name; public Chopstick(String name) { this.name = name; } @Override public String toString() { return "筷子{" + name + '}'; } } class Philosopher extends Thread { Chopstick left; Chopstick right; public Philosopher(String name, Chopstick left, Chopstick right) { super(name); this.left = left; this.right = right; } private void eat() { log.debug("eating..."); Sleeper.sleep(1); } @Override public void run() { while (true) { // 获得左手筷子 synchronized (left) { // 获得右手筷子 synchronized (right) { // 吃饭 eat(); } // 放下右手筷子 } // 放下左手筷子 } } } 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(); 12:33:15.575 [苏格拉底] c.Philosopher - eating... 12:33:15.575 [亚里士多德] c.Philosopher - eating... 12:33:16.580 [阿基米德] c.Philosopher - eating... 12:33:17.580 [阿基米德] c.Philosopher - eating... // 卡在这里, 不向下运行

名称: 阿基米德状态: cn.itcast.Chopstick@1540e19d (筷子1) 上的BLOCKED, 拥有者: 苏格拉底总阻止数: 2, 总等待数: 1 堆栈跟踪: cn.itcast.Philosopher.run(TestDinner.java:48)

- 已锁定 cn.itcast.Chopstick@6d6f6e28 (筷子5)

名称: 苏格拉底状态: cn.itcast.Chopstick@677327b6 (筷子2) 上的BLOCKED, 拥有者: 柏拉图总阻止数: 2, 总等待数: 1 堆栈跟踪: cn.itcast.Philosopher.run(TestDinner.java:48)

- 已锁定 cn.itcast.Chopstick@1540e19d (筷子1)

名称: 柏拉图状态: cn.itcast.Chopstick@14ae5a5 (筷子3) 上的BLOCKED, 拥有者: 亚里士多德总阻止数: 2, 总等待数: 0 堆栈跟踪: cn.itcast.Philosopher.run(TestDinner.java:48)

- 已锁定 cn.itcast.Chopstick@677327b6 (筷子2)

名称: 亚里士多德状态: cn.itcast.Chopstick@7f31245a (筷子4) 上的BLOCKED, 拥有者: 赫拉克利特总阻止数: 1, 总等待数: 1 堆栈跟踪: cn.itcast.Philosopher.run(TestDinner.java:48)

- 已锁定 cn.itcast.Chopstick@14ae5a5 (筷子3)

名称: 赫拉克利特状态: cn.itcast.Chopstick@6d6f6e28 (筷子5) 上的BLOCKED, 拥有者: 阿基米德总阻止数: 2, 总等待数: 0 堆栈跟踪: cn.itcast.Philosopher.run(TestDinner.java:48) - 已锁定 cn.itcast.Chopstick@7f31245a (筷子4) 分析发现: 阿基米德等待1,1被苏格拉底持有苏格拉底等待2,2被柏拉图持有柏拉图等待3，3被亚里士多德持有亚里士多德等待4,4被赫拉克利特持有赫拉克利特等待5,5被阿基米德持有即: 苏格拉底持有1,等待2 柏拉图持有2,等待3 亚里士多德持有3,等待4 赫拉克利特持有4,等待5 阿基米德持有5,等待1 每个人持有一根筷子，即一把锁，5个人互相等待。这也是死锁的表现。 ```

死锁解决:顺序加锁

先来看看使用顺序加锁的方式解决之前的死锁问题

Object A = new Object(); Object B = new Object(); Thread t1 = new Thread(() -> { synchronized (A) { log.debug("lock A"); sleep(1); synchronized (B) { log.debug("lock B"); log.debug("操作..."); } } } , "t1"); Thread t2 = new Thread(() -> { synchronized (A) { log.debug("lock A"); sleep(0.5); synchronized (B) { log.debug("lock B"); log.debug("操作..."); } } } , "t2"); t1.start(); t2.start();

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("阿基米德", c1, c5).start();

分析: 苏格拉底持有1,等待2 柏拉图持有2,等待3 亚里士多德持有3,等待4 赫拉克利特持有4,等待5 阿基米德持有1,等待5 由于5没有人持有，赫拉克利特先吃上饭释放了 4、5线程得以执行,但是又有新的问题，即饥饿。

饥饿

synchronized是非公平锁，没有浪费线程唤醒阶段的时间，执行新调用的方法，增加吞吐量，缺点是可能会造成饥饿。

很多教程中把饥饿定义为，一个线程由于优先级太低，始终得不到 CPU 调度执行，也不能够结束，饥饿的情况不易演示，讲读写锁时会涉及饥饿问题。

上面虽然解决了死锁的问题，但是存在某一个线程很长的一段时间里都得不到执行的问题。

可以使用ReentrantLock的公平锁解决。

使用非公平锁时可能会出现饥饿效应，这会导致某些线程一直不能获取到锁来进行后续任务的执行，这是生产环境不想看到的问题，如何解决？

饥饿效应产生的根本原因是线程在获取锁时在排队，而非公平锁使用了插队的方式来减少唤醒线程的CPU开销，插队导致后面的线程一直等待。这是饱效应的根本原因。

根治的方法是让等待时间过长的线程有重新获取锁的机会，可以给每一个等待的线程一个超时时间，超过某一时间后可以重新获取一次锁，线程在获取锁的过程中加一个带有超时时间、自旋间隔的自旋逻辑。

☆公平锁与非公平锁

前提: 线程等待时会被挂起，轮到他时会被唤醒。

公平锁:新进程发出请求，如果此时一个线程正持有锁，或有其他线程正在等待队列中等待这个锁，那么新的线程将被放入到队列中被挂起。相当于一堆嗜睡的低血糖病人排队看医生，进去的病人门一关，外面的人便排队候着打瞌睡，轮到他时再醒醒进去。

非公平锁: 新进程发出请求，如果此时一个线程正持有锁，新的线程将被放入到队列中被挂起，但如果发出请求的同时该锁变成可用状态，那么这个线程会跳过队列中所有的等待线程而获得锁。相当于排队看医生，进去的病人门一关，外面的人便排队候着打瞌睡，这时新人来了，碰巧门一开，外面的人还没完全醒来，他就乘机冲了进去。

☆ReentrantLock

相对于 synchronized,它具备如下特点

-可中断

-可以设置超时时间

-可以设置为公平锁

-支持多个条件变量

-与 synchronized 一样，都支持可重入

基本语法

// 获取锁 reentrantLock.lock(); try { // 临界区 } finally { // 释放锁 reentrantLock.unlock(); }

可重入

可重入是指同一个线程如果首次获得了这把锁，那么因为它是这把锁的拥有者，因此有权利再次获取这把锁

如果是不可重入锁，那么第二次获得锁时，自己也会被锁挡住

static ReentrantLock lock = new ReentrantLock(); public static void main(String[] args) { method1(); } public static void method1() { lock.lock(); try { log.debug("execute method1"); method2(); } finally { lock.unlock(); } } public static void method2() { lock.lock(); try { log.debug("execute method2"); method3(); } finally { lock.unlock(); } } public static void method3() { lock.lock(); try { log.debug("execute method3"); } finally { lock.unlock(); } } 输出: 17:59:11.862 [main] c.TestReentrant - execute method1 17:59:11.865 [main] c.TestReentrant - execute method2 17:59:11.865 [main] c.TestReentrant - execute method3

可打断

ReentrantLock lock = new ReentrantLock(); Thread t1 = new Thread(() -> { log.debug("启动..."); try { lock.lockInterruptibly(); //尝试加锁，但是该锁可以被打断 } catch (InterruptedException e) { e.printStackTrace(); log.debug("等锁的过程中被打断"); return; } try { log.debug("获得了锁"); } finally { lock.unlock(); } }, "t1"); //先获取到锁 lock.lock(); log.debug("获得了锁"); //再启动线层 t1.start(); try { //睡眠1秒 sleep(1); //中断t1获取锁的操作 t1.interrupt(); log.debug("执行打断"); } finally { lock.unlock(); }

18:02:40.520 [main] c.TestInterrupt - 获得了锁 18:02:40.524 [t1] c.TestInterrupt - 启动... 18:02:41.530 [main] c.TestInterrupt - 执行打断 java.lang.InterruptedException at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibly(AbstractQueuedSynchronizer.java:898)at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1222) at java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:335) at cn.itcast.n4.reentrant.TestInterrupt.lambda$main$0(TestInterrupt.java:17) at java.lang.Thread.run(Thread.java:748) 18:02:41.532 [t1] c.TestInterrupt - 等锁的过程中被打断

注意:如果是不可中断模式，那么即使使用了 interrupt 也不会让等待中断

ReentrantLock lock = new ReentrantLock(); Thread t1 = new Thread(() -> { log.debug("启动..."); //lock.lock();代替lock.lockInterruptibly(); lock.lock(); try { log.debug("t1获得了锁"); } finally { lock.unlock(); } }, "t1"); lock.lock(); log.debug("获得了锁"); t1.start(); try { sleep(1); t1.interrupt(); log.debug("执行打断"); sleep(1); } finally { log.debug("释放了锁"); lock.unlock(); } 输出: 18:06:56.261 [main] c.TestInterrupt - 获得了锁 18:06:56.265 [t1] c.TestInterrupt - 启动... 18:06:57.266 [main] c.TestInterrupt - 执行打断 // 这时 t1 并没有被真正打断, 而是仍继续等待锁 18:06:58.267 [main] c.TestInterrupt - 释放了锁 18:06:58.267 [t1] c.TestInterrupt - t1获得了锁

锁超时

ReentrantLock lock = new ReentrantLock(); Thread t1 = new Thread(() -> { log.debug("启动..."); if (!lock.tryLock()) { log.debug("获取立刻失败，返回"); return; } try { log.debug("获得了锁"); } finally { lock.unlock(); } } , "t1"); lock.lock(); log.debug("获得了锁"); t1.start(); try { sleep(2); } finally { lock.unlock(); } 由于主线程先获取到锁，t1线程不到锁会立刻返回。 //输出: 18:15:02.918 [main] c.TestTimeout - 获得了锁 18:15:02.921 [t1] c.TestTimeout - 启动... 18:15:02.921 [t1] c.TestTimeout - 获取锁失败，立刻返回

超时失败

ReentrantLock lock = new ReentrantLock(); Thread t1 = new Thread(() -> { log.debug("启动..."); try { if (!lock.tryLock(1, TimeUnit.SECONDS)) { log.debug("获取等待 1s 后失败，返回"); return; } } catch (InterruptedException e) { e.printStackTrace(); } try { log.debug("获得了锁"); } finally { lock.unlock(); } } , "t1"); lock.lock(); log.debug("获得了锁"); t1.start(); try { sleep(2); } finally { lock.unlock(); }

18:19:40.537 [main] c.TestTimeout - 获得了锁 18:19:40.544 [t1] c.TestTimeout - 启动... 18:19:41.547 [t1] c.TestTimeout - 获取等待 1s 后失败，返回

公平锁

ReentrantLock 默认是不公平的锁，synchronize默认也是不公平的锁。

所谓的公平指得是按照进入阻塞队列的顺序先来先得获取锁。

Synchronize是在锁释放以后，阻塞队列的锁一拥而上去抢占锁。

```

//ReentrantLock lock = new ReentrantLock(); 此处默认是false //相当于 //ReentrantLock lock = new ReentrantLock(false); ReentrantLock lock = new ReentrantLock(false); lock.lock(); for (int i = 0; i < 500; i++) { new Thread(() -> { //这里不是锁重入 //而是主线程创建了 500个线程 //这500个线程一直被阻塞在这里 //等待主线程释放锁这500个线程才能执行 lock.lock(); try { System.out.println(Thread.currentThread().getName() + " running..."); } finally { lock.unlock(); } } , "t" + i).start(); } // 1s 之后去争抢锁 Thread.sleep(1000); new Thread(() -> { System.out.println(Thread.currentThread().getName() + " start..."); //同上 lock.lock(); try { System.out.println(Thread.currentThread().getName() + " running..."); } finally { lock.unlock(); } } , "强行插入").start(); lock.unlock(); ```

强行插入线程有机会在中间输出。即没有按照顺序，最后来的最后才能获取锁，而是最后来到的插队获取到了锁。注意：该实验不一定总能复现。

t39 running... t40 running... t41 running... t42 running... t43 running... 强行插入 start... 强行插入 running... t44 running... t45 running... t46 running... t47 running... t49 running...

改为公平锁后

ReentrantLock lock = new ReentrantLock(true); //强行插入，总是在最后输出，最后来的最后才能获取锁。 t465 running... t464 running... t477 running... t442 running... t468 running... t493 running... t482 running... t485 running... t481 running... //强行插入 running..

公平锁一般没有必要，会降低并发度，后面分析原理时会讲解

条件变量

synchronized 中也有条件变量，就是我们讲原理时那个 waitSet 休息室，当条件不满足时进入 waitSet 等待。

ReentrantLock 的条件变量比 synchronized 强大之处在于，它是支持多个条件变量的，这就好比synchronized 是那些不满足条件的线程都在一间休息室等消息。

而 ReentrantLock 支持多间休息室，有专门等烟的休息室、专门等早餐的休息室、唤醒时也是按休息室来唤醒。

使用要点：

``` -await 前需要获得锁，这一点和synchronize一样

-await 执行后，会释放锁，进入 conditionObject 等待

-await 的线程被唤醒(或打断、或超时)后会重新竞争 lock 锁，竞争 lock 锁成功后，从 await 后继续执行 ```

static ReentrantLock lock = new ReentrantLock(); static Condition waitCigaretteQueue = lock.newCondition(); static Condition waitbreakfastQueue = lock.newCondition(); static volatile Boolean hasCigrette = false; static volatile Boolean hasBreakfast = false; public static void main(String[] args) { new Thread(() -> { try { lock.lock(); while (!hasCigrette) { try { waitCigaretteQueue.await(); } catch (InterruptedException e) { e.printStackTrace(); } } log.debug("等到了它的烟"); } finally { lock.unlock(); } } ).start(); new Thread(() -> { try { lock.lock(); while (!hasBreakfast) { try { waitbreakfastQueue.await(); } catch (InterruptedException e) { e.printStackTrace(); } } log.debug("等到了它的早餐"); } finally { lock.unlock(); } } ).start(); sleep(1); sendBreakfast(); sleep(1); sendCigarette(); } private static void sendCigarette() { lock.lock(); try { log.debug("送烟来了"); hasCigrette = true; waitCigaretteQueue.signal(); } finally { lock.unlock(); } } private static void sendBreakfast() { lock.lock(); try { log.debug("送早餐来了"); hasBreakfast = true; waitbreakfastQueue.signal(); } finally { lock.unlock(); } }

18:52:27.680 [main] c.TestCondition - 送早餐来了 18:52:27.682 [Thread-1] c.TestCondition - 等到了它的早餐 18:52:28.683 [main] c.TestCondition - 送烟来了 18:52:28.683 [Thread-0] c.TestCondition - 等到了它的烟

对比synchronized:

//1.工作线程相当于早餐 synchronized(lock) { while(早餐条件不成立) { lock.wait(); } // 干活 } //2.工作线程相当于烟 synchronized(lock) { while(烟条件不成立) { lock.wait(); } // 干活 } //3.条件变量线程: synchronized(lock) { 修改条件 lock.notifyAll(); }

tryLock解决哲学家就餐问题

class Chopstick extends ReentrantLock { String name; public Chopstick(String name) { this.name = name; } @Override public String toString() { return "筷子{" + name + '}'; } }

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 { left.unlock(); } } } } private void eat() { log.debug("eating..."); Sleeper.sleep(1); } }

``` 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();

饥饿的根源在于 synchronized 获取左手筷子,一直获取不到右手筷子。trylock获取到左手筷子,获取不到右手筷子就会释放左手筷子。

如果将Chopstick c1 = new Chopstick(true);//改为公平锁解决问题

使用非公平锁时可能会出现饥饿效应，这会导致某些线程一直不能获取到锁来进行后续任务的执行，这是生产环境不想看到的问题，如何解决？

饥饿效应产生的根本原因是线程在获取锁时在排队，而非公平锁使用了插队的方式来减少唤醒线程的CPU开销，插队导致后面的线程一直等待。这是饱效应的根本原因，根治的方法是让等待时间过长的线程有重新获取锁的机会，可以给每一个等待的线程一个超时时间，超过某一时间后可以重新获取一次锁，线程在获取锁的过程中加一个带有超时时间、自旋间隔的自旋逻辑。 ———————————————— 版权声明：本文为CSDN博主「码农杰森」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/bklydxz/article/details/117903146 ```