在 barrierAction 中无法直接获取其他等待线程的堆栈，但可通过 ThreadMXBean 获取所有线程快照并筛选 WAITING/TIMED_WAITING 状态下堆栈含 CyclicBarrier.await 的线程。
在 CyclicBarrier 的 barrierAction 中获取“完整的当前堆栈快照”，本质上是想捕获所有正在等待屏障的线程（即调用 await() 后被阻塞、尚未执行 barrierAction 的线程）的堆栈信息。但需要明确一点：barrierAction 本身是在最后一个到达线程的上下文中同步执行的，此时其他线程仍处于 await() 的阻塞状态（如在 Condition.await() 或自旋中），它们的堆栈是“静止”的，无法直接从 barrierAction 内部主动读取。
Java 标准库不提供“获取所有阻塞在某个同步点上的线程堆栈”的 API。不过，有几种**实用且可控的方式**可以逼近你的目标：
方式一：利用 ThreadMXBean 获取所有线程堆栈（最常用）
这是最直接、无需侵入业务逻辑的方法。在 barrierAction 中调用 JVM 级线程监控接口，抓取当前时刻所有线程的堆栈快照：
- 使用
ManagementFactory.getThreadMXBean()获取ThreadMXBean - 调用
dumpAllThreads(false, false)（不打印锁信息、不加锁）获得ThreadInfo[] - 遍历结果，筛选出状态为
WAITING或TIMED_WAITING且堆栈中包含CyclicBarrier.await的线程 - 对每个匹配线程调用
getStackTrace()即可得到其完整堆栈
示例代码片段：
立即学习“Java免费学习笔记（深入）”；
Runnable barrierAction = () -> {
ThreadMXBean bean = ManagementFactory.getThreadMXBean();
ThreadInfo[] infos = bean.dumpAllThreads(false, false);
for (ThreadInfo info : infos) {
Thread.State state = info.getThreadState();
if ((state == Thread.State.WAITING || state == Thread.State.TIMED_WAITING)
&& info.getStackTrace().length > 0) {
StackTraceElement top = info.getStackTrace()[0];
// 粗略判断是否卡在 CyclicBarrier.await
if (top.getClassName().contains("CyclicBarrier")
&& top.getMethodName().equals("await")) {
System.out.println("Thread " + info.getThreadId()
+ " (" + info.getThreadName() + ") stack:");
Arrays.stream(info.getStackTrace())
.forEach(System.out::println);
}
}
}
};
方式二：在 await 前主动登记线程堆栈（精准可控）
如果你需要精确知道“哪些线程参与了本次屏障”并保留它们进入阻塞前的原始堆栈（比如用于调试或链路追踪），可在调用 await() 之前手动记录：
- 定义一个
ThreadLocal<stacktraceelement></stacktraceelement>存储每个线程进入await()前的堆栈 - 在线程调用
await()前，执行threadLocal.set(new Exception().getStackTrace()) - 在
barrierAction中，通过共享容器（如ConcurrentHashMap）收集并清空这些堆栈 - 注意线程安全与内存泄漏：建议配合
remove()清理ThreadLocal
方式三：结合 JFR 或 JVMTI（生产级深度诊断）
如果需求是长期可观测性或性能分析，不推荐在 barrierAction 中硬编码堆栈采集：
- 启用 JDK Flight Recorder（JFR），配置
jdk.ThreadSleep、jdk.JavaMonitorEnter等事件，可回溯线程阻塞行为 - 使用
jcmd <pid> VM.native_memory summary或jstack <pid>外部命令做快照（适合人工排查） - JVMTI Agent 可拦截线程状态变更，但开发成本高，一般用于 APM 工具（如 Arthas 的
thread -b）
不复杂但容易忽略：CyclicBarrier 的 barrierAction 是单线程执行的，它本身不会“唤醒”其他线程——那些线程仍在阻塞中，直到 barrierAction 返回后才被统一唤醒。所以你看到的“当前堆栈”，其实是它们被挂起那一刻的快照，而非运行时动态堆栈。
