join()仅等待单个线程终结，绑定线程实例，不兼容线程池；CountDownLatch基于计数事件，支持超时、查询、多线程触发，适配线程池与复杂并发场景。
Java 中 join() 和 CountDownLatch 都能实现“等待其他线程完成后再继续执行”的效果，但底层机制、适用边界和扩展能力差异明显。选错工具容易导致代码僵硬、难以维护，甚至在线程池等现代并发场景中根本无法使用。
适用场景：单线程终结 vs 任意事件完成
join() 只能等待一个具体 Thread 实例的生命终结——即 run() 方法返回、线程彻底死亡。它绑定的是线程对象本身，不是任务逻辑。
CountDownLatch 等待的是“计数归零”这一抽象事件，与线程生命周期无关。它可以被任意线程在任意位置调用 countDown()，比如任务中途初始化完成、I/O 响应到达、配置加载成功等。
- 适合用
join()的情况：手动创建并管理少量独立线程，且必须等其完全结束（如简单脚本式并发） - 适合用
CountDownLatch的情况：微服务启动检查、批量异步请求汇总、多阶段初始化协调、线程池任务结果聚合
线程模型兼容性：裸线程 vs 线程池
join() 要求你持有目标线程的引用，而线程池（ExecutorService）复用线程、不暴露内部 Thread 对象，因此无法对提交的任务调用 join()。
立即学习“Java免费学习笔记（深入）”；
CountDownLatch 完全脱离线程实例，只需在任务逻辑中插入 latch.countDown() 即可。无论是 submit(Runnable) 还是 invokeAll()，都能自然集成。
- 线程池 + join → 编译报错或运行时空指针
- 线程池 + CountDownLatch → 直接可用，无需改造线程创建方式
控制粒度与灵活性：被动阻塞 vs 主动触发
join() 是被动等待：主线程只能卡在 join() 调用点，直到目标线程退出；无法超时、无法查询状态、无法中断等待（除非抛出 InterruptedException）。
CountDownLatch 提供主动控制能力：
-
await(long, TimeUnit)支持超时，避免无限等待 -
getCount()可实时查看剩余未完成任务数 - 多个线程可分阶段调用
countDown()，不必等整个任务跑完 - 主线程可在
await()前做其他准备，而非全程阻塞
性能与资源消耗：忙等风险 vs AQS 优化
join() 内部通过循环调用 wait(0) 实现，虽然 JVM 层做了优化，但在极端高负载或异常挂起时，仍存在隐式 CPU 轮询开销。
CountDownLatch 基于 AQS（AbstractQueuedSynchronizer），使用 CAS + 阻塞队列，等待线程真正休眠，不消耗 CPU；唤醒由 countDown() 触发，响应及时、无空转。
- 高频调用
join()的循环体可能拖慢整体吞吐 - CountDownLatch 在千万级并发压测中表现更稳定
