应使用CountDownLatch配合System.nanoTime()精准统计并发总耗时：主线程提交前记录起点，await()返回后记录终点，或各线程独立计时后取最大值；避免在submit/start处计时或使用currentTimeMillis()。
要准确统计多个线程并发执行的总耗时（即从第一个线程启动到所有线程全部完成的时间），不能简单用 System.currentTimeMillis() 包裹 executor.submit() 或 thread.start()，因为那测的是“提交耗时”或“启动耗时”，而非实际任务执行时间。正确做法是：在所有线程**真正开始执行任务前**统一计时起点，在**最后一个线程结束任务后**记录终点——CountDownLatch 正好能帮你精准同步这个“全部完成”的时刻。
用 CountDownLatch 确保“所有任务结束”才停止计时
CountDownLatch 本身不提供耗时能力，但它能阻塞主线程直到所有子线程调用 countDown()，从而保证你在所有任务真正完成后才读取结束时间。关键在于：计时起点放在任务开始执行处（而非线程启动处），终点放在 await() 返回之后。
- 初始化
CountDownLatch latch = new CountDownLatch(n)，n 是任务数 - 每个线程在自己任务逻辑的**第一行**记录开始时间（可存入线程局部变量或共享容器），或更推荐——主线程在分发任务前统一记录起始时间（前提是任务启动延迟可忽略；若任务有初始化开销，建议在 Runnable/Callable 内部首行记时）
- 每个线程在任务逻辑**最后一行**调用
latch.countDown() - 主线程在提交完所有任务后，立即调用
latch.await()，之后再获取当前时间作为结束时间
推荐写法：主线程统一开始 + await 后结束（简洁可靠）
适用于任务体轻量、线程池复用充分、启动延迟小的场景。代码结构清晰，避免多线程读写共享时间变量的复杂性：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
long start = System.nanoTime();
CountDownLatch latch = new CountDownLatch(5);
<p>for (int i = 0; i < 5; i++) {
executor.submit(() -> {
try {
// 模拟业务逻辑
Thread.sleep(100);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
} finally {
latch.countDown(); // 必须在 finally 中确保执行
}
});
}</p><p>try {
latch.await(); // 主线程等待所有任务完成
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}</p><p>long end = System.nanoTime();
long totalMs = TimeUnit.NANOSECONDS.toMillis(end - start);
System.out.println("总耗时：" + totalMs + " ms"); // ≈ 100ms（非 500ms）
进阶：各线程独立计时 + 取最大值（更精确反映并行效果）
如果任务执行时间差异大，或你想验证是否真正在并行（比如某任务卡住拖慢整体），可让每个线程自己记录耗时，主线程收集后取最大值。这比单一起止点更能体现真实瓶颈：
立即学习“Java免费学习笔记（深入）”；
- 用
ConcurrentLinkedQueue<Long>或AtomicLongArray收集各线程耗时 - 每个线程内：开始前
long t0 = System.nanoTime()，结束后queue.add(System.nanoTime() - t0) - 主线程
latch.await()后，遍历集合取max值转为毫秒 - 这样得到的是“最慢那个线程的执行时间”，即实际并行总耗时，且不受主线程调度延迟影响
常见误区提醒
✘ 错误：在 submit() 前记 start，submit() 后立刻记 end → 测的是提交耗时，不是执行耗时
✘ 错误：用 Thread.sleep(100) 模拟任务但没加 finally countDown() → 异常时漏减，await() 永远不返回
✘ 错误：把 System.currentTimeMillis() 当高精度计时器 → 并发场景建议用 System.nanoTime()，毫秒级精度不够稳定
