ObjectWaiter是HotSpot JVM内部C++类，封装调用wait()的线程，以双向链表（_WaitSet）形式组织在ObjectMonitor中，含_thread、_prev、_next及_notified等字段，分配于本地内存，由JVM自动管理唤醒与移除。
Java 中并没有直接暴露 ObjectWaiter 双向链表的底层结构供开发者操作，它属于 HotSpot JVM 内部实现细节，不属 Java 语言规范，也不在 JDK API 中。所谓“重量级锁”（即互斥锁，inflated monitor）在锁膨胀后，其等待队列确实由 ObjectWaiter 节点组成的双向链表（_WaitSet）来管理线程阻塞与唤醒，但这完全由 JVM 在 C++ 层实现（位于 src/hotspot/share/runtime/objectMonitor.hpp 和 .cpp），Java 层不可见、不可访问、不可修改。
H3：ObjectWaiter 是什么？
ObjectWaiter 是 HotSpot 内部的一个 C++ 类，每个调用 Object.wait() 进入阻塞状态的 Java 线程，都会被封装为一个 ObjectWaiter 实例。该结构体包含：
- 指向对应 Java
Thread对象的指针（_thread） - 前驱和后继指针（
_prev/_next），构成双向链表 - 等待状态字段（如
_notified，标记是否已被notify()唤醒） - 其他调度相关字段（如
_event用于 OS 层事件等待）
它不继承自任何 Java 类，不占用 Java 堆内存，而是分配在本地内存（C-heap）中，生命周期由 JVM 监控器（ObjectMonitor）管理。
立即学习“Java免费学习笔记（深入）”；
H3：WaitSet 双向链表如何组织？
当多个线程在同一个对象上调用 wait()，它们会被挂起并加入该对象关联的 ObjectMonitor 的 _WaitSet 链表：
- 插入发生在链表尾部（FIFO 语义，但
notify()不严格保序） -
_WaitSet是一个指向某个ObjectWaiter的指针，作为链表头（实际是循环或带哨兵的双向链？HotSpot 多采用 head/tail 分离 + CAS 插入） - 链表遍历通过
_next向前跳转，回溯靠_prev，支持 O(1) 解除单个节点（如被中断或超时）
例如线程 T1 → T2 → T3 等待，则 _WaitSet 指向 T1，T1._next = T2，T2._next = T3，T3._next = null；T2._prev = T1，T3._prev = T2。
H3：线程如何从链表中跳转/唤醒？
唤醒动作（notify() / notifyAll()）由 JVM 在 ObjectMonitor::notify() 中执行：
-
notify()：摘下_WaitSet首节点（非严格首，可能跳过已失效节点），将其移入_EntryList（竞争锁的就绪队列）或直接唤醒（若无竞争） -
notifyAll()：遍历整个_WaitSet链表，将所有节点逐个移出并唤醒 - 唤醒前会设置
_notified = 1，并调用ParkEvent::unpark()触发操作系统级线程解阻塞
注意：链表跳转不涉及 Java 字节码或指令，全部在 JVM runtime 的 C++ 临界区中完成，使用原子操作（如 Atomic::cmpxchg）维护链表一致性，避免并发修改问题。
H3：为什么 Java 程序员通常不需要关心这个？
- 所有
wait/notify行为被synchronized和 JVM 自动封装，无需手动管理链表 -
ObjectWaiter无法反射获取，不能序列化，不属于 Java 对象模型 - 即使通过 JVMTI 或 Unsafe 探测，也极易导致 JVM 不稳定或未定义行为
- 性能分析时可借助
jstack查看WAITING (on object monitor)状态，但看不到链表结构本身
真正影响性能的是锁竞争模式、GC 压力、上下文切换开销，而非链表跳转效率——现代 JVM 对 _WaitSet 操作已高度优化，链表遍历极少成为瓶颈。
