LockSupper是什么？他和Lock、Synchroized有什么关系？解决了什么？

Love The Way You Lie 2021-10-09 09:28 287阅读 0赞

### LockSupper是什么？他和Lock、Synchroized有什么关系？解决了什么？ ###

话不多说，先贴文档：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70][]

**关键的一句话：用于创线程和其他同步类的基本线程阻塞原语；**

**简单来说，就是阻塞线程的；但是我们阻塞线程不可以用await、wail吗？**

**看第三行：方法park和unpark提供了阻止、解除阻塞（唤醒）线程的有效手段，该方法不会遇到导致不推荐使用的方法Thread.suspend和Thread.resume目前不能使用的问题：一个线程调用park和另一个线程之间的尝试unpark保持活跃性，由于许可证。另外，如果调用者的线程被中断，park将返回，并且支持超时版本。Park方法也可以在任何其他时间返回，因为“无理由”，因此一般必须在返回之前重新检查条件的循环中被调用。在这个意义上，park作为一个“忙碌等待”的优化，不浪费时间选择，当必须和unpark配对才有效。**

说的有点云里雾里的，但是我听懂了一些，就是解决了一些不建议使用的情况，然后，支持多线程调用，并且支持超时；

### 了解LockSupport功能的前提，我们先得分析一下原来的synchronized；lock ###

**案例1：**

对于这个打印的顺序，我觉得应该大家都好理解吧，两个线程，同时顺序执行，因为我们加了同步锁synchronized，并且保证了同一个锁对象，那么按照代码块的顺序，基本上都是线程1先获取到cpu时间片，当线程1执行到休眠对象了后，该线程就会被挂起，也就是被阻塞，同时就会释放锁对象，恰好线程2所被阻塞的锁对象和线程1的一致，然后线程2进入同步锁，就开始执行唤起动作，唤起的对象恰好是线程1所挂起的对象，那么当线程1被唤起后，继续执行接下来的动作。

所以此处需要注意：原则上只要两个线程同时加上synchronized同步锁，并且锁对象是同一个对象，那么线程被阻塞的时候，就会释放锁，并不会发生死锁现象。

这里其实和sync的底层实现有关系，因为其底层实现是存在一个阻塞双向链表的。并且会控制一个对象当前的占用的线程实例。所以当前某个占有的线程被阻塞后，就会释放锁。

注意，当我们如果在执行线程阻塞的时候（wait方法）的时候，必须使用synchronized修饰代码块，这也是jvm层面的要求，因为在jvm执行锁休眠的时候，会执行释放锁的动作，那么要想释放，就得先获取到锁，也就是先要获取到synchronized锁，并且锁的对象，和我们执行唤起，阻塞的对象必须是同一个对象。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 1][]

如果不使用锁，直接执行线程的wait/notify方法，那么就会之间抛出异常IllegalMonitorStateException。例如下面图；并且都会产生死锁情况；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 2][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 3][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 4][]

**案例2：**

如果线程1后执行，线程2执行，会出现什么情况呢？也就是先被执行唤起，再被执行阻塞休眠；

结果就是，执行唤起线程成功了，但是接下来执行线程1的阻塞操作，就执行完成后，就一直被阻塞着，无法唤起了。

通俗的理解就是，当一个人将一个垃圾桶的垃圾清理了之后，然后另一个人又扔了一个垃圾进这个垃圾桶，那么这个垃圾桶就一直都有一个垃圾；对于第一个人而言，认为他已经清理了垃圾桶了；对于第二个人而言，他一直都在等第一个人清理垃圾桶。一直等着下去

产生的问题就是：不会存在逻辑错误，只会存在死锁现象了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 5][]

**案例3：**

我们都知道Lock，那么我们再试一下案例2中的锁对象换成 lock中的condition对象，看看这个对象中的await()/signal()方法效果怎么样

同样的产生了死锁，情况也是一样的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 6][]

**案例4：**

我们知道对于Object对象的wait/notify方法，必须需要搭配synchronized使用，那么我们也试一下condition是不是也是需要搭配lock使用？

是的，错误都一样，我们需要对某个对象进行阻塞/唤起，都需要先获取锁，我们才能操作该对象的阻塞和唤起。这都是基于jvm底层规定要求。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 7][]

**对于上述4个案例，我们可以通过执行的结果得出一些结论：**

1.  **锁对象的阻塞、唤起，的前提条件，必须配合锁一起使用，并且锁的对象和代码块中的对象必须是同一个。**
2.  **线程的阻塞、唤起必须顺序执行，如果不顺序执行，那么将可能会发生死锁的情况。**

**那么这也是传统的锁的弊端。那么我们新的锁对象就来了。LockSupport**

那么就看源码把？

![20210210210001498.png][]

禁止构造，这就是一个工具类把。

继续：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 8][]

大概可以看到这个工具类的所有方法，那么分别是什么意思呢？我们解读一下；

1.  **public static void park()**

禁止当前线程进行线程调度，除非许可证可用。

如果许可证可用，则它被消耗，并且该呼叫立即返回; 否则当前线程对于线程调度目的将被禁用，并且处于休眠状态，直至发生三件事情之一：

一些其他线程调用当前线程作为目标的unpark ;

要么一些其他线程当前线程interrupts ;

要么电话虚假（也就是说，没有理由）返回。

这种方法不报告是哪个线程导致该方法返回。 来电者应重新检查导致线程首先停放的条件。 呼叫者还可以确定线程在返回时的中断状态。

从上面的官方描述中，我们可以扑捉到1个关键字：许可证

也就是说LockSupport类使用了一种叫许可（Permit）的概念，通过这个概念来实现线程的阻塞和唤起的功能。对于每个线程来说，都会有一个许可，这个许可有两种状态，为0,1；缺省情况下为0；

都知道，我们在PV操作中会有一种概念叫做信号量，通过信号量来实现多线程环境下的线程唤起，线程阻塞。那么这个许可证和这个信号量概念很类似了，只不过有些区别就是，信号量值是不受限制，但是许可证只会有0,1。

当我们线程1调用 park()方法的时候，当前线程就会被阻塞挂起，然后就会一直等待其他线程将该线程的许可证设置为1，然后该线程就会被唤起，然后又会将其许可证设置为0后，再执行后面的逻辑。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 9][]

1.  **public static void unpark(Thread**** thread)**

禁用当前线程进行线程调度，直到指定的截止日期，除非许可证可用。

如果许可证可用，则它被消耗，并且该呼叫立即返回; 否则当前线程对于线程调度目的将被禁用，并且处于休眠状态，直到发生四件事情之一：

一些其他线程调用当前线程作为目标的unpark ; 要么

其他一些线程当前线程为interrupts ; 要么

指定期限通过; 要么

电话虚假（也就是说，没有理由）返回。

这种方法不报告是哪个线程导致该方法返回。 来电者应重新检查导致线程首先停放的条件。 呼叫者还可以确定线程的中断状态，或返回当前的时间。

如果线程被park给阻塞了，那么调用它就会解除阻塞。但是如果给定的线程没有被阻塞，那么就不做任何操作。因为当线程的许可证为1了，你再唤起，也会是1。

这个有什么优势呢？也就是说，他可以无脑调用唤醒线程，并不需要只能唤醒被阻塞的线程。

看一下源码，很简单清晰，就一个主要代码，调用的是UNSAFE类中的unpark(thread);unsafe就不说了，一个本地方法的类，都是偏底层实现的。基本可以认为是原子操作。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 10][]

LockSupport其他方法就不解释了，基本上是重载；

**案例5：**

那么我们将上面案例2、案例3的方式使用一下看看，会不会抛出异常呢？

结果很明显哈，虽然，线程2先将线程1进行了unpark()操作，也就是唤起操作，但是线程1后3秒钟后执行阻塞操作，当线程1执行park()操作后，立马就被唤起了。

其中的变化，我们可以知道，通过线程的许可证进行控制：第一步，线程2将线程1的许可证由默认值0改为1，然后线程1进行阻塞操作，发现自己的线程的许可证为1，那么将直接唤醒，然后将自己线程的许可证改为0，然后继续执行后续动作。

注意：此处我们没有添加锁..

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 11][]

**有趣的拓展一下1：**

我们都知道信号量的特性，那么上面也说了一下许可证的特性，那么我们试一下，假设，先唤起1次，然后再阻塞2次，看看结果咋样？

结果很明显，发生了阻塞，原因就是，第一次被唤起的时候，又将其许可证初始化为0了，那么第二次执行阻塞的时候，就真的被阻塞了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 3][]

**有趣的拓展一下2：**

那么我们接着拓展1，如果先唤起2次，然后再阻塞2次呢？

结果充分的证明了，许可证只能是1或者0；当我们第一次唤起的时候，将许可证置为1，然后第二次唤起的时候，也只能置为1；然后第一次阻塞的时候，将1变为0，第二次阻塞的时候0,就不能被唤起了。所以第二次阻塞就一直阻塞了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 12][]

**有趣的拓展一下3：**

多次唤起，多次阻塞，我们偏偏要不阻塞，咋实现？如下试试?

诶！没有被阻塞了，怎么回事？欢迎各位大佬来分析一下，休眠2到底怎么被唤起的？其中的许可证变化顺序又是怎么样的呢？

欢迎各位留言分享一下各自的分析。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 13][]

**总结：**

**LockSupport解决了阻塞、唤醒先后顺序问题，解决方案是通过许可证概念。但是有一个规则，就是许可证只能是1,0；并且两个状态转换，存在一定规则，规则如上图案例；**

**为什么唤醒两次，阻塞两次后就会被阻塞，无法被唤起。因为连续调用两次unPark()方法，本质来说就是将许可证重复置为1，那么两次调用park()方法，就是将1置为0，唤醒的前提条件是，当前的许可证必须为1，第一个阻塞唤起操作将1变为0，那么当前的线程的许可证已经是0了，无法被唤起；**

**LockSupport实现方式是通过本地方法，是c的实现了，基本上可以理解为原子操作。**

**LockSupport是一个工具类，因为被私有化构造方法，内部方法都是静态方法了。**

**LockSupport不需要使用锁，只是对于线程的唤起，阻塞操作。**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70]: /images/20211009/a206582002f4426e9720f18882500510.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 1]: /images/20211009/d0f8c334c76445c491ef2fa103f4d5e1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 2]: /images/20211009/5267be63439e47b9b22647a27cd2963c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 3]: /images/20211009/b6a1bd225965461ba0656623923ff119.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 4]: /images/20211009/e17fd566ff93413ca64909929bdbb0fe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 5]: /images/20211009/cff5dae00af04b2d8ce5394ef7b34ed1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 6]: /images/20211009/ce1fbea6c9e54e47aec0840fc4444759.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 7]: /images/20211009/46cc15ba44334c178acd1f1cbf43f87b.png
[20210210210001498.png]: /images/20211009/10218e6eef384b838dfbfe591b95449c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 8]: /images/20211009/e7040822b4cf4108acabaf12facdab24.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 9]: /images/20211009/da983ec179d64bca94645b1d53dc97b4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 10]: /images/20211009/e24914ad61e84d2eb2ab2ffb2c7cf1d2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 11]: /images/20211009/c9f19042ea8142dfb0b4192ce7b555ec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 12]: /images/20211009/225938736756402787f36d19fbf4b8d7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 13]: /images/20211009/770869c2d4ee4cecbc97d7d08afdaf2c.png