线程数设为CPU核心数×2导致卡顿，是因忽略I/O等待、锁竞争和上下文切换开销；混合任务应从核心数+1开始压测，避免阻塞操作拖垮ForkJoinPool。
为什么线程数设为 CPU 核心数 × 2 就卡顿？
这不是经验公式的失效，而是忽略了 I/O 等待、锁竞争和上下文切换的实际开销。当 ThreadPoolExecutor 的核心线程数盲目设为 Runtime.getRuntime().availableProcessors() * 2，而任务实际含数据库查询或远程调用时，大量线程会阻塞在 WAITING 或 BLOCKED 状态，反而加剧调度负担。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用
jstack抓取线程快照，统计java.lang.Thread.State: WAITING占比；若超 60%，说明线程过载，应降配并引入异步 I/O（如CompletableFuture+HttpClient非阻塞模式） - 对纯计算型任务，线程数可设为
availableProcessors()；对混合型任务，从availableProcessors() + 1开始压测，观察 GC 日志中GC pause与吞吐量拐点 - 避免复用同一
ForkJoinPool执行阻塞操作，否则会拖垮整个公共池——改用自定义ThreadPoolExecutor并设置allowCoreThreadTimeOut(true)
ConcurrentHashMap.computeIfAbsent 为什么在高并发下变慢？
Java 8 的 computeIfAbsent 在 key 对应的桶为空时会加锁，但若传入的 mappingFunction 耗时较长（比如查 DB 或解析 JSON），会导致该桶长期被独占，其他线程在该桶上形成排队等待，吞吐量骤降。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 绝不在
computeIfAbsent的 lambda 中做任何 I/O 或重计算；只做轻量对象构造（如new HashMap()） - 若需懒加载复杂对象，先用
putIfAbsent尝试插入占位符（如FutureTask），再由单一线程异步初始化，其他线程 await 获取结果 - JDK 17+ 可考虑
ConcurrentHashMap.newKeySet()配合外部缓存策略，规避 compute 类方法的锁粒度问题
CountDownLatch.await() 超时后为何线程没释放？
常见错误是只调用 countDown() 一次，却在多线程中反复 await —— CountDownLatch 是一次性门闩，一旦计数归零，后续所有 await() 立即返回，但若业务逻辑未检查返回值就继续执行，可能造成空指针或状态不一致，间接拖慢整体流程。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 永远用
if (latch.await(3, TimeUnit.SECONDS)) { /* 正常路径 */ } else { /* 超时处理：清理资源、抛异常或降级 */ } - 不要用
CountDownLatch控制循环节奏；改用Semaphore限流或Phaser多阶段同步 - 在单元测试中模拟超时场景，验证
finally块是否能正确释放Lock、关闭Socket等资源——漏掉这个，压测时连接池耗尽比吞吐下降更致命
用 JMH 测吞吐量时，为什么结果总飘忽不定？
JMH 默认的预热轮次（@Fork + @Warmup）不足以让 JIT 编译器稳定优化分支预测和内联深度，尤其当被测方法含 if-else 链或 switch 表时，不同轮次可能走不同编译路径，导致 ops/ms 波动超过 ±25%。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 至少配置
@Fork(jvmArgs = {"-XX:+UnlockDiagnosticVMOptions", "-XX:+PrintAssembly"})查看热点方法是否被 C2 编译，再决定是否增加@Warmup(iterations = 10) - 禁用分层编译（
-XX:-TieredStopAtLevel）强制使用 C2，消除解释执行干扰 - 用
@State(Scope.Benchmark)管理共享对象，但切忌在@Setup中初始化ConcurrentHashMap并直接注入——应延迟到第一次@Benchmark调用时按需构建，否则预热数据污染真实测量
真正卡住吞吐量的，往往不是算法复杂度，而是某次 System.out.println() 被留在生产日志里，或是某个 static final Map 初始化时偷偷触发了类加载锁。调优要盯住线程栈和 GC 日志里的“异常平稳”——那通常意味着瓶颈藏在你看不见的地方。
