countdownlatch用作发令枪的核心逻辑是：主线程调用await()等待，所有子线程在“准备就绪、只待开跑”时调用countdown()，而非启动后或执行完才减；就绪指httpclient连接池就绪、threadlocal填充完毕、预热完成等前置条件全部满足。
CountDownLatch 用作发令枪的核心逻辑是什么
关键就一条：CountDownLatch 的 await() 必须在主线程调用，而所有子线程必须在真正开始“干活”前调用 countDown()；但注意——不是执行完才减，是「准备就绪、只待开跑」那一刻就减。否则主线程永远等不到计数归零。
常见错误现象：await() 返回了，但子线程还没真正开始处理请求，压测时间戳错乱、并发量不达标。
- 子线程启动后立刻
countDown()→ 错！这时线程可能连连接池、本地缓存都没初始化好 - 子线程把业务逻辑全跑完才
countDown()→ 错！这已经不是“发令”，是“收工汇报” - 主线程
await(5, TimeUnit.SECONDS)超时后继续往下走 → 错！得明确失败并中断压测，否则结果不可信
子线程怎么才算“就绪”才该 countDown
就绪 ≠ 启动，≠ 实例化，≠ 进入 run() 方法。它指的是：当前线程已具备立即发起请求的一切前置条件。
典型就绪点包括：HttpClient 连接池 ready、ThreadLocal 上下文已填充、预热请求（warmup）完成、等待信号的 BlockingQueue 已注入初始任务。
- Spring Boot 环境下，可用
ApplicationRunner或@PostConstruct预热 HTTP 客户端，再让子线程确认 - 裸写线程时，在
run()开头加一个while (!ready.get()) { Thread.yield(); }，由主线程统一置ready.set(true)后再countDown() - 更稳妥的做法：子线程启动后，先执行一次空请求或 ping 接口，成功后再
countDown()
await 超时和异常该怎么处理
await() 抛出 InterruptedException 不是边缘情况，而是压测中线程被强制中断的明确信号；超时则说明有子线程卡死或未按约定就绪，这两种都必须终止整个压测流程。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
不能吞掉异常、不能忽略超时、不能 fallback 到“尽力而为”模式——压测数据失真比不跑还危险。
- 捕获
InterruptedException后，立即调用Thread.currentThread().interrupt()恢复中断状态 - 超时分支里，遍历所有存活子线程并调用
interrupt()，避免残留线程污染后续测试 - 记录具体哪个线程没就绪（比如用
ConcurrentHashMap<thread boolean></thread>标记），方便定位是初始化慢还是死锁
为什么不用 CyclicBarrier 或 Phaser 替代
CyclicBarrier 看似更贴切（“大家一起到齐才出发”），但它在 parties 到齐后会自动放行，且无法区分「到达」和「开始执行」；一旦某个线程在 barrier.await() 后崩溃，其他线程会被永久阻塞，无超时控制。
Phaser 功能强但复杂，phase 切换逻辑容易在压测场景中引入非预期的等待或重入，调试成本远高于 CountDownLatch 的单向流语义。
-
CountDownLatch是一次性、不可重置、语义清晰的“门栓”，正适合发令枪这种单次触发场景 - 若需多次压测复用同一 latch，必须新建实例——重用已触发的 latch 会导致
await()立即返回，发令失效 - 别为了“看起来高级”换组件，压测稳定性和可重现性，比代码炫技重要得多
最容易被忽略的一点：子线程调用 countDown() 的位置，必须严格落在「所有初始化完成、所有依赖就绪、所有资源分配完毕」之后，且不能有任何可能抛异常的代码夹在中间。否则，那个线程就悄无声息地“失踪”了，主线程干等，你还以为是网络延迟。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
