countdownlatch 不支持偏向锁，因其完全基于 aqs 实现，依赖 volatile state 和 cas 操作，不涉及对象头 mark word，与 synchronized 锁优化机制无关。
这个问题存在根本性误解——CountDownLatch 不会、也不能被施加偏向锁，更不存在“偏向锁优化擦除”一说。
CountDownLatch 的锁机制不走对象头偏向路径
CountDownLatch 内部完全基于 AQS（AbstractQueuedSynchronizer）的共享模式实现，其同步逻辑依赖于一个独立的 Sync 内部类（继承 AQS），而该类的同步状态由 state 字段（volatile int）控制。所有线程对它的等待（await()）和计数递减（countDown()）都通过 AQS 的 CAS 操作和队列管理完成。
这意味着：
- 它不依赖被锁对象（如某个普通 Java 对象）的对象头 Mark Word 做锁标记；
- 没有“某个线程首次获取锁并记录 thread ID”的前提，无法触发偏向锁初始化；
- 所有竞争行为发生在 AQS 的抽象队列和 volatile state 上，与 JVM 对普通对象的锁升级流程（无锁 → 偏向锁 → 轻量级锁 → 重量级锁）完全隔离。
偏向锁只作用于 synchronized 同步块/方法的目标对象
偏向锁是 JVM 针对 synchronized 关键字修饰的临界区所做的运行时优化，仅适用于以下场景：
- 锁对象是普通 Java 实例（非 Class、非数组、非常量池对象等）；
- 该对象在生命周期中大概率由同一线程反复进入同步块；
- JVM 启用偏向锁（JDK 15+ 默认已禁用，需显式开启
-XX:+UseBiasedLocking）。
而 CountDownLatch 的 await/countDown 是纯 Java 方法调用，内部无任何 synchronized(this) 或类似语义，因此 JVM 根本不会、也无法对其做偏向锁标记或撤销。
高频 AQS 竞争触发的是 AQS 自身的优化，不是 JVM 锁升级
当多个线程频繁调用 countDown() 导致 CAS 失败率升高时，AQS 的响应是：
- 自旋重试（在
tryAcquireShared/tryReleaseShared中有限次数 CAS）； - CAS 失败后，线程进入 AQS 同步队列排队，由 LockSupport.park/unpark 控制阻塞与唤醒；
- 底层仍使用操作系统互斥原语（如 futex）支撑 park，这属于重量级等待，但这是 AQS 协议层行为，与 synchronized 的“重量级锁”概念无关。
这种行为由 AQS 框架自身调度，和 JVM 对象头的锁状态（偏向/轻量/重量）毫无关系。
可能混淆的来源
容易产生误解的点通常来自：
- 把 “AQS 使用了 CAS + volatile” 和 “synchronized 底层也用了 CAS + 对象头” 粗略等同，误以为它们共享同一套锁优化体系；
- 看到 JDK 源码中
CountDownLatch.Sync继承 AQS，就默认它参与了 JVM 的锁膨胀流程； - 将 “锁消除（lock elimination）” 错当成 “偏向锁擦除”——锁消除是 JIT 编译器对 未逃逸的 synchronized 的移除，而 CountDownLatch 根本没用 synchronized。
