objectmonitor的waitset通过双向链表管理wait线程，notify/notifyall唤醒时摘除节点并设为thread_blocked，随后线程需竞争锁或入entrylist，不保证立即获得锁。
Java中ObjectMonitor的WaitSet在重量级锁唤醒时，核心控制逻辑是通过_WaitSet链表与线程状态迁移协同完成的，关键在于唤醒顺序、竞争时机和线程重新入队策略。
WaitSet的结构与线程入队机制
WaitSet是一个双向链表（ObjectWaiter节点），由ObjectMonitor维护。线程调用wait()后，会：
- 释放当前持有的ObjectMonitor（进入无锁状态）
- 将自身封装为
ObjectWaiter节点，插入WaitSet尾部 - 将线程状态设为
THREAD_WAITING，并挂起（通常通过park()）
该过程是原子的，且WaitSet本身不保证FIFO语义（JVM实现可能按插入顺序，但不强制）。
notify/notifyAll唤醒时的WaitSet遍历与移除
当持有锁的线程调用notify()或notifyAll()时，ObjectMonitor会：
- 从WaitSet头部开始遍历（HotSpot采用LIFO或FIFO取决于版本，主流JDK8+倾向FIFO）
- 对每个被选中的
ObjectWaiter：将其从WaitSet链表中摘除，设置线程状态为THREAD_BLOCKED - 调用
unpark()唤醒对应线程
注意：notify()只唤醒一个；notifyAll()遍历整个WaitSet，但不保证所有线程立即获得锁——它们仍需竞争ObjectMonitor的入口队列（EntryList）或直接尝试获取锁。
唤醒后线程如何重新竞争锁
被unpark()的线程恢复执行后，并不会直接进入临界区，而是：
- 检查ObjectMonitor是否空闲：若空闲，尝试CAS抢占锁，成功则继续执行
- 若锁被占用，则加入EntryList（同步队列），等待被Owner线程在
exit()时通过ExitEpilog()唤醒 - 若此时有多个线程被唤醒，它们之间存在竞争，结果取决于操作系统线程调度与CAS成功率
也就是说，WaitSet中的唤醒 ≠ 立即获得锁，只是获得了“参与锁竞争”的资格。
重量级锁下WaitSet与EntryList的协作关系
在重量级锁场景中，ObjectMonitor内部维护三类线程集合：
- Owner：当前持有锁的线程（仅1个）
- EntryList：等待获取锁的阻塞线程队列（已park，等待被唤醒）
-
WaitSet：因
wait()而主动释放锁并等待条件的线程队列
二者转换路径清晰：WaitSet → (notify) → EntryList → (Owner释放锁) → 获取锁
这个流程确保了wait-notify语义的可靠性，也解释了为何notify后线程仍可能阻塞：它必须再次赢过EntryList中其他线程的竞争。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
