locksupport.getblocker() 返回当前线程调用 park(object blocker) 时传入的 blocker 对象引用，若调用无参 park() 则返回 null；该值仅用于线程转储诊断，不参与同步逻辑。
LockSupport.getBlocker() 返回什么
LockSupport.getBlocker() 返回的是当前线程被阻塞时「显式关联」的 Object，不是锁对象本身，也不是任意等待目标。它只在调用 LockSupport.park(Object blocker) 时由你传入的那个 blocker 参数决定；如果用的是无参 park()，返回 null。
这个值唯一作用是：在线程转储（如 jstack 输出）里显示为 - parking to wait for <code> (a java.lang.Object) 中的 对应的对象——但注意，getBlocker() 返回的是那个 Object 实例引用，不是地址。
- 它不反映实际加锁状态（比如没持
synchronized锁、没进ReentrantLock.lock()，照样能有 blocker） - 它不参与任何同步逻辑，纯属诊断标记，JVM 不靠它做调度
- 自定义 AQS 实现时，常在
park()前设一个有意义的 blocker（如当前节点的waiter字段），方便排查
为什么 jstack 里看不到 getBlocker() 对应的对象
常见现象：代码里明明调用了 LockSupport.park(someObj)，但 jstack 输出里还是显示 parking to wait for ，而你查 someObj 的哈希码对不上——这是因为 jstack 显示的是对象头里的 identity hash code（由 JVM 在首次调用 System.identityHashCode() 时生成并缓存），不是 someObj.hashCode()，更不是内存地址。
-
getBlocker()返回的是对象引用，jstack显示的是该对象的 identity hash 码（十六进制），二者不等价 - 如果对象从未触发过 identity hash 计算（比如没调过
System.identityHashCode()或hashCode()且未被 synchronized 锁过），JVM 可能延迟生成，导致jstack显示的地址看起来“飘忽” - 不要试图用
someObj.toString()或System.identityHashCode()手动比对——jstack输出的是内部表示，不可直接映射
如何在线程转储中准确定位 blocker 对应的业务含义
关键不是去反推地址，而是让 blocker 本身可识别。AQS 类实现（如 ReentrantLock、Semaphore）通常把当前等待节点（Node）设为 blocker，而 Node 里往往持有 Thread 引用或业务上下文字段。
立即学习“Java免费学习笔记（深入）”；
- 调试时，在 park 前打日志：
log.debug("parking on blocker: {}", blocker);，确保 blocker 是你可控的、带业务标识的对象（比如封装了请求 ID 的WaitContext） - 避免用临时对象作 blocker（如
new Object()），否则转储里全是java.lang.Object，无法区分 - 用
jstack -l <pid></pid>（带锁信息）配合grep -A 5 "parking"快速定位线程栈，再结合代码里 park 调用点附近的 blocker 构造逻辑反查 - JDK9+ 可用
jcmd <pid> VM.native_memory summary</pid>辅助看是否因 native 内存不足导致 park 行为异常（这时 blocker 可能失效）
getBlocked() 和 getBlocker() 完全不是一回事
别被名字误导：Thread.getBlockedCount() 和 Thread.getStackTrace() 返回的是线程在 synchronized 块上**等待进入临界区**的次数和栈，跟 LockSupport.getBlocker() 毫无关系。前者属于 monitor 锁语义，后者属于底层线程调度标记。
-
Thread.getState() == BLOCKED→ 等 monitor 锁 → 看getBlockedCount() -
Thread.getState() == WAITING / TIMED_WAITING且栈顶是Unsafe.park()→ 才可能有有效 blocker → 查LockSupport.getBlocker() - 没有 API 能直接从线程对象拿到它的 blocker，必须自己保存（比如在 park 前存到
ThreadLocal）或者依赖框架（如ForkJoinPool自己管理）
事情说清了就结束。真正难的不是读出 blocker，而是让 blocker 在复杂嵌套调用里始终指向你能一眼认出的业务实体——这得靠设计时就把它当成可观测性的一部分，而不是事后补救。
