本文主要是介绍关于 java 锁池、等待池（一），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
围绕着：「等待池中被 "唤醒"notifyAll() 的线程一定会进入锁池吗？」
这个问题，深入学习，发现了一篇讲解很透彻的博客：
http://www.cnblogs.com/tiancai/p/9371655.html
学习，感谢！
原文：
谢邀。不知道题中的一段文字出自何处。“锁池”和“等待池”这种翻译我还是头一回见。不过，题主的思路已经对了，即不拘泥于文字，而是在考虑这两个东西在锁的调度（即决定哪个线程可以获得锁的过程）中起到什么作用。
Java平台中，每个对象都有一个唯一与之对应的内部锁（Monitor）。Java虚拟机会为每个对象维护两个“队列”（姑且称之为“队列”，尽管它不一定符合数据结构上队列的“先进先出”原则）：一个叫Entry Set（入口集），另外一个叫Wait Set（等待集）。对于任意的对象objectX，objectX的Entry Set用于存储等待获取objectX对应的内部锁的所有线程。objectX的Wait Set用于存储执行了objectX.wait()/wait(long)的线程。
设objectX是任意一个对象，monitorX是这个对象对应的内部锁，假设有线程A、B、C同时申请monitorX，那么由于任意一个时刻只有一个线程能够获得（占用/持有）这个锁，因此除了胜出（即获得了锁）的线程（这里假设是B）外，其他线程（这里就是A和C）都会被暂停（线程的生命周期状态会被调整为BLOCKED）。这些因申请锁而落选的线程就会被存入objectX对应的Entry Set（以下记为entrySetX）之中。当monitorX被其持有线程（这里就是B）释放时，entrySetX中的一个任意（注意是“任意”，而不一定是Entry Set中等待时间最长或者最短的）线程会被唤醒（即线程的生命周期状态变更为RUNNABLE）。这个被唤醒的线程会与其他活跃线程（即不处于Entry Set之中，且线程的生命周期状态为RUNNABLE的线程）再次抢占monitorX。这时，被唤醒的线程如果成功申请到monitorX，那么该线程就从entrySetX中移除。否则，被唤醒的线程仍然会停留在entrySetX，并再次被暂停，以等待下次申请锁的机会。
如果有个线程执行了objectX.wait()，那么该线程就会被暂停（线程的生命周期状态会被调整为WAITTING）并被存入objectX的Wait Set（以下记为waitSetX）之中。此时，该线程就被称为objectX的等待线程。当其他线程执行了objectX.notify()/notifyAll()时，waitSetX中的一个（或者多个，取决于被调用的是notify还是notifyAll方法）任意（注意是“任意”，而不一定是Entry Set中等待时间最长或者最短的）等待线程会被唤醒（线程的生命周期状态变更为RUNNABLE）。这些被唤醒的线程会与entrySetX中被唤醒的线程以及其他（可能的）活跃线程共同参与抢夺monitorX。如果其中一个被唤醒的等待线程成功申请到锁，那么该线程就会从waitSetX中移除。否则，这些被唤醒的线程仍然停留在waitSetX中，并再次被暂停，以等待下次申请锁的机会。
@刘方外
我理解调用对象的 notifyAll方法后，waitSet 上的线程都会加入到 entrySet 中的吧？在一个持有锁的线程释放锁后，应该只有 entrySet 队列的线程可能获取锁，那这个通知是 park 来实现的吗？是否有保证获取锁公平性的相关设置?
1、从Java虚拟机性能的角度来说，Java虚拟机没有必要在notifyAll调用之后“将Wait Set中的线程移入Entry Set”。首先，从一个“队列”移动到另外一个“队列”是有开销的，其次，虽然notifyAll调用后Wait Set中的多个线程会被唤醒，但是这些被唤醒的线程极端情况下可能没有任何一个能够获得锁（比如被其他活跃线程抢先下手了）或者即便可以获得锁也可能不能继续运行（比如这些等待线程所需的等待条件又再次不成立）。那么这个时候，这些等待线程仍然需要老老实实在wait set中待着。因此，如果notifyAll调用之后就将等待线程移出wait set会导致浪费（白白地进出“队列”）。这点可以参考显式锁的实现：
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(Node, int)
/*** Acquires in exclusive uninterruptible mode for thread already in* queue. Used by condition wait methods as well as acquire.** @param node the node* @param arg the acquire argument* @return {@code true} if interrupted while waiting*/final boolean acquireQueued(final Node node, int arg) {boolean failed = true;try {boolean interrupted = false;for (;;) {final Node p = node.predecessor();if (p == head && tryAcquire(arg)) {setHead(node);p.next = null; // help GCfailed = false;return interrupted;}if (shouldParkAfterFailedAcquire(p, node) &&parkAndCheckInterrupt())interrupted = true;}} finally {if (failed)cancelAcquire(node);}}从上面的代码可以看出，（使用显式锁时）被唤醒的线程获得锁（tryAcquire调用返回true）之后才被从wait set中移出（setHead调用）。
2、内部锁仅仅支持非公平锁调度。显式锁既支持公平锁又支持非公平锁。
LockSupport.park/upark是在jdk1.5开始引入的，显式锁的在实现线程的暂停和唤醒的时候会用到这个两个方法。而内部锁是在jdk1.5之前就已经存在的。
【参考资料】
1、黄文海.Java多线程编程实战指南（核心篇）.电子工业出版社,2017
2、Inside the Java Virtual Machine： Thread Synchronization and the Java Monitor
3、Thread.State (Java Platform SE 7 )
这篇关于关于 java 锁池、等待池（一）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
