LockSupport：不用担心线程被永久阻塞

让线程“等待”的方法有很多，例如wait（）和notify（），不过这两个方法是对对象做操作，它们不在Thread类中。如果一个对象object o调用wait（）方法，那么它就会进入object的等待队列中，直到notify（）方法被调用后，从这个等待队列中随机选择唤醒一个线程，这种选择是随机的，是不公平的。

还有suspend（）和resume（）方法，不过既然是被标注为废弃方法，就很少用了，因为suspend（）方法挂起线程后，不会释放任何资源，此时如果有其他线程想去访问它占用的锁时，也会被牵连一起等待。如果resume（）方法意外地被执行在suspend（）之前，那么被挂起的线程就起不来了，一直处于挂起状态。还有一点很重要的是，书上说“对于被suspend（）挂起的线程，它的线程状态依然是Runnable，这会严重影响系统对线程当前状态的判断。“这么多问题，怪不得被标注为废弃方法。

有一种安全的方法，就是用阻塞工具类LockSupport，在线程执行时的任意地方都可以调用它，使用LockSupport.park（）方法让线程阻塞，然后在想唤醒线程的地方调用LockSupport.unpakr（）方法。为什么说它是安全的呢？假设LockSupport.unpark（）方法意外地在LockSupport.park（）方法前被调用了，被阻塞的线程仍然可以被唤醒，是的，来看看代码：

我们定义线程执行后睡眠，然后在执行LockSupport.park（）来阻塞线程，做的事情很简单。然后main函数中，实例化两个线程T1,T2。T1先执行后接着立刻调用LockSupport.unpark（）方法，模拟unpark（）方法意外地发生在了park（）方法前，T2也一样。执行结果你会发现，两个线程始终能够完成所有任务，不会因为方法的调用顺序出现意外而导致线程被永久阻塞。

这样看来很不错，但是想知道它是怎么做到的，代码一条一条按顺序执行？难道是有序性的问题，程序执行时出现了指令重排？以前刚开始看多线程时，就了解到指令重排的问题，指令是否发生重排，如何重排，都是不可预知的。不过，指令重排有一个基本前提，就是保证串行语义的一致性，也就是保证不会使逻辑语义发生问题，否则代码就无法保证一直正常工作了，所以，在串行执行的代码程序中，不用担心指令重排的问题。在多线程环境下，就不能保障指令重排出现问题了。

排除了指令重排问题，至于为什么LockSupport.unpark（）方法意外地被调用在了LockSupport.park（）方法后，线程还能从阻塞状态被唤醒？首先我去翻了文档：

原来，LockSupport类使用了类似于信号量的东西，文档里称为许可，LockSupport类为每一个线程使用它的线程都与一个许可关联起来，调用park（）方法时，如果这个许可是可用的，那么就把许可设置为不可用，线程进入阻塞。当调用unpark（）方法后，如果许可不可用，则将其设置为可用，此时线程被唤醒。文档中有一句说到，每个使用LockSupport类的线程都与一个许可关联（注意许可只有一个，这与信号量不同），还有特别重要的一句“调用park（）方法的线程和另一个试图将其unpark（）的线程之间的竞争将保持活性”，这才是park（）和unpark（）方法调用顺序不当也不会出错的原因。

      可是文档只是告诉我它们之间的活性竞争特点所以不会引起unpark（）被调用在park（）前而造成的线程永久阻塞问题，并没有告诉我们它们是如何做到的。这里我们再把重点放在那个“许可”上，我在网上翻了一些LockSupport的源码解读，下面两个我觉得挺不错：

https://www.cnblogs.com/leesf456/p/5347293.html

https://blog.csdn.net/chengzhang1989/article/details/79669045

两个一起看，大概就是，LockSupport类引入了sun.misc.Unsafe类中的park（）和unpark（）方法，park（）方法中的Parker类有一个链表成员_counter就是文档中所说的“许可”，调用park（）方法，如果许可_counter的值大于0（表示许可可用），就把它设置为0，并且调用Linux线程下的pthread_cond_timedwait一直等待。而unpark（）方法，如果许可_counter等于0，也就是不可用，就设置为1，然后直接返回，否则就一直等待许可的改变，这样来实现park（）和unpark（）方法之间的活性竞争。