CountDownLatch 不引发内核上下文切换，因其基于 JVM 层 AQS 实现，仅用 volatile 计数器和 park/unpark，new 操作轻量无系统调用，真实切换源于线程启动、I/O 或锁竞争。
CountDownLatch 本身不触发操作系统级上下文切换——它纯在 JVM 层基于 AQS 实现，所有 await/countDown 操作都不创建线程、不调用 OS 系统调用，更不会引起内核态线程调度或上下文切换。
为什么 CountDownLatch 不造成内核上下文切换
它只是对一个 volatile 计数器做原子减法（countDown）或自旋+阻塞队列挂起（await），阻塞时使用的是 Java 线程的 Object.wait() 或 AQS 的 park/unpark，这些最终由 JVM 转换为用户态线程挂起（如 Linux 上是 futex_wait），仅在真正需要让出 CPU 且无其他工作可做时，才可能间接触发内核线程调度。但这个开销与“初始化 CountDownLatch 对象”完全无关。
- new CountDownLatch(3) 只是分配一个轻量对象，耗时几十纳秒，无系统调用
- 频繁 new 不会导致上下文切换，只会增加 GC 压力和内存带宽占用
- 真正的上下文切换来自线程启动（Thread.start）、线程阻塞唤醒（如 I/O、synchronized 争抢、park）、或虚拟线程大量 yield 等行为
误判来源：常被混淆的两类“切换”
开发者看到“多个线程等 latch”就默认“一定有切换”，其实混淆了两个层面：
- 逻辑等待 vs. 真实调度：await() 后线程进入 WAITING 状态，但若此时 CPU 还有其他可运行线程，JVM 可能继续调度它们——这属于正常线程调度，不是因 CountDownLatch 引发的额外代价
- 虚拟线程场景下的假象：Java 21+ 使用虚拟线程 + structured concurrency 时，大量 virtual thread 在 await 上挂起，看起来“切换密集”，但实际是 JVM 在用户态协程调度器中快速切换栈，不经过 OS 内核，上下文切换开销比平台线程低 1–2 个数量级
真要测上下文切换内耗？盯准这几个地方
如果你观察到高延迟或性能抖动，并怀疑是“同步工具引发内核切换”，请转向以下真实影响点：
- 检查是否在 countDown() 后立刻 notifyAll() 或唤醒大量线程竞争同一把锁（如 synchronized 方法体里调用 latch.countDown）
- 确认 await() 调用是否包裹在慢速 I/O 或阻塞调用中（如数据库连接、Socket.read）——这才是上下文切换大户
- 用 perf record -e sched:sched_switch 或 pidstat -w 测实际进程/线程切换频次，再关联堆栈（perf script）看是否真卡在 Unsafe.park 或 futex_wait
- 对比启用 -XX:+UseVirtualThreads 后的切换次数：虚拟线程下 sched_switch 事件锐减，但用户态 park/unpark 次数上升——这正是设计预期
替代方案：比 CountDownLatch 更轻的协作方式
如果目标是减少任意层面的调度开销，可考虑：
- 用 StructuredTaskScope（Java 21+）替代手动管理 latch，天然适配虚拟线程，无显式计数器维护成本
- 高频短任务用 CompletableFuture.allOf() + 线程池 submit，避免反复 new latch
- 组件初始化类场景，改用 ServiceLoader + 初始化门控（static final AtomicBoolean），零对象分配、零阻塞
