CyclicBarrier必然逃逸，因其需跨线程共享状态（count、parties、barrierCommand等）及锁（ReentrantLock+Condition），对象被多线程引用或作为参数传递即判定为global escape，JIT无法标量替换或栈上分配。
CyclicBarrier 本身是一个线程同步工具，它的核心是协调多个线程在某个“屏障点”等待彼此到达后才一起继续执行。它内部依赖共享状态（如 count、parties、barrierCommand）和锁（ReentrantLock + Condition），这些对象天然需要跨线程可见、可修改——也就是说，它们必须分配在堆上，且必然逃逸。
CyclicBarrier 实例本身通常会逃逸
当你 new 一个 CyclicBarrier，比如：
CyclicBarrier barrier = new CyclicBarrier(3, () -> System.out.println("All arrived"));这个 barrier 对象几乎总会被多个线程共同引用（例如传给不同线程的 Runnable），或作为共享字段存在。只要它被赋值给静态变量、实例字段、或作为参数传入其他方法（尤其是未内联的方法），JIT 的逃逸分析就会判定它“逃逸出当前方法作用域”。一旦逃逸，就无法做标量替换或栈上分配。
内部对象基本都不可优化
CyclicBarrier 内部持有：
立即学习“Java免费学习笔记（深入）”；
-
ReentrantLock lock—— 必须在堆中，供多线程竞争 -
Condition trip—— 与 lock 绑定，同样需全局可见 -
Runnable barrierCommand（如果非 null）—— 通常是 Lambda 或匿名类实例，闭包捕获外部变量时更易逃逸 -
int count和int parties—— 虽是基本类型，但因所属对象已逃逸，无法单独拆解标量替换
这些组件的设计目标就是跨线程协作，JIT 不会对它们做逃逸优化——这不是缺陷，而是语义决定的。
逃逸分析对 CyclicBarrier 没有实际优化空间
不同于 ArrayList.iterator() 在局部 foreach 中可能不逃逸、从而被 JIT 消除掉 Iterator 对象，CyclicBarrier 的使用模式决定了它：
- 生命周期通常跨越多个线程启动与执行阶段
- 必须支持
await()被并发调用，状态变更需内存可见（依赖 volatile / 锁） - 没有“仅限本方法内使用”的典型场景
所以即使开启 -XX:+DoEscapeAnalysis，JIT 几乎总判定 CyclicBarrier 对象及其关键字段为“global escape”，跳过标量替换、同步消除等优化。
真正影响性能的是用法，不是逃逸分析
与其关注 JIT 能不能优化 CyclicBarrier，不如注意：
- 避免在高频循环中反复创建新 CyclicBarrier（每次 new 都是堆分配+锁初始化开销）
- 复用同一实例（前提是业务逻辑允许重置，如配合
reset()） - 若只需单次等待，考虑更轻量的
CountDownLatch（其内部结构类似，但无 barrierCommand，略少一点字段） - 高并发下注意
await()的争用，必要时评估Phaser的分段屏障能力
JIT 对它的“不优化”，恰恰说明它的设计符合并发契约——该逃逸的，就该逃逸。
