线程数设为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 Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
实操建议：
立即学习“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 日志里的“异常平稳”——那通常意味着瓶颈藏在你看不见的地方。
