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><0x...> (a java.lang.Object) 中的 <0x...> 对应的对象——但注意，getBlocker() 返回的是那个 Object 实例引用，不是地址。
- 它不反映实际加锁状态（比如没持
synchronized锁、没进ReentrantLock.lock()，照样能有 blocker） - 它不参与任何同步逻辑，纯属诊断标记，JVM 不靠它做调度
- 自定义 AQS 实现时，常在
park()前设一个有意义的 blocker（如当前节点的waiter字段），方便排查
为什么 jstack 里看不到 getBlocker() 对应的对象
常见现象：代码里明明调用了 LockSupport.park(someObj)，但 jstack 输出里还是显示 parking to wait for <0x0000000712345678>，而你查 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输出的<0x...>是内部表示，不可直接映射
如何在线程转储中准确定位 blocker 对应的业务含义
关键不是去反推地址，而是让 blocker 本身可识别。AQS 类实现（如 ReentrantLock、Semaphore）通常把当前等待节点（Node）设为 blocker，而 Node 里往往持有 Thread 引用或业务上下文字段。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 调试时，在 park 前打日志：
log.debug("parking on blocker: {}", blocker);，确保 blocker 是你可控的、带业务标识的对象（比如封装了请求 ID 的WaitContext） - 避免用临时对象作 blocker（如
new Object()），否则转储里全是java.lang.Object，无法区分 - 用
jstack -l <pid>（带锁信息）配合grep -A 5 "parking"快速定位线程栈，再结合代码里 park 调用点附近的 blocker 构造逻辑反查 - JDK9+ 可用
jcmd <pid> VM.native_memory summary辅助看是否因 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 在复杂嵌套调用里始终指向你能一眼认出的业务实体——这得靠设计时就把它当成可观测性的一部分，而不是事后补救。
