LockSupport.getBlocker()作用及使用详解

文章不知道大家是否熟悉？今天我将给大家介绍《LockSupport.getBlocker() 是 Java 并发包中的一个方法，用于获取当前线程阻塞的等待对象。在多线程环境中，当线程被阻塞时（例如通过 park() 方法），getBlocker() 可以返回导致线程阻塞的对象。1. LockSupport 的基本作用LockSupport 是 Java 并发工具包中提供的一种底层线程同步机制，它提供了比 synchronized 更灵活的线程阻塞和唤醒功能。与 Object.wait() 和 Object.notify() 不同，LockSupport 的 park() 和 unpark() 方法不依赖于对象的监视器锁，因此更加轻量和高效。2. LockSupport.getBlocker() 的作用getBlocker() 方法返回的是当前线程被阻塞时所等待的对象。这个对象通常是调用 park(Object blocker) 方法时传入的参数。如果没有显式地调用 park(Object blocker)，则默认的阻塞对象为 null。LockSupport.park(); // 或者 LockSupport.park(blocker);如果调用了 park(blocker)，那么 getBlocker() 将返回该 blocker 对象。如果调用了 park() 而没有传入参数，则 getBlocker() 返回 null。3.》，这篇文章主要会讲到等等知识点，如果你在看完本篇文章后，有更好的建议或者发现哪里有问题，希望大家都能积极评论指出，谢谢！希望我们能一起加油进步！

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 <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 引用或业务上下文字段。

• 调试时，在 park 前打日志：log.debug("parking on blocker: {}", blocker);，确保 blocker 是你可控的、带业务标识的对象（比如封装了请求 ID 的 WaitContext）
• 避免用临时对象作 blocker（如 new Object()），否则转储里全是 java.lang.Object，无法区分
• 用 jstack -l （带锁信息）配合 grep -A 5 "parking" 快速定位线程栈，再结合代码里 park 调用点附近的 blocker 构造逻辑反查
• JDK9+ 可用 jcmd 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 在复杂嵌套调用里始终指向你能一眼认出的业务实体——这得靠设计时就把它当成可观测性的一部分，而不是事后补救。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《LockSupport.getBlocker()作用及使用详解》文章吧，也可关注golang学习网公众号了解相关技术文章。