标签：Java 并发疑难杂症 - Ai拆代码的曹操 - Java性能调优·线上问题排查

置顶Java 并发疑难杂症 · 系列目录

Java 并发疑难杂症 · 系列目录叙事框架：现象 → 逆向推理 → 验证 → 根因总计 26 篇，已发布 9 篇，17 篇待完善一、线程池类 ✅ 线程 Dump 不会读？从 BLOCKED/WAITING/RUNNABLE 到问题还原 ✅ 线程池队列积压百万任务，不重启如何诊断？ ✅ 线程池

ReentrantReadWriteLock 锁降级：面试背答案的人，写不出这种死锁场景：缓存组件使用 ReentrantReadWriteLock 做读写分离，写锁降级读锁时所有线程卡死路径：现象 → 复现 → 排查路径 → AQS 源码 + CLH 队列 → 代码审查标记上篇讲了 Reen

无竞争，换锁后 RT 飙了 15 倍——ReentrantLock 的 JIT 内联陷阱场景：8 线程业务服务，接口 RT ~50ms，锁竞争几乎为零。因上游超时需加 tryLock(1s) 降级，把 synchronized 换成 ReentrantLock——上线后 RT 飙到 800ms+。

卡死 3 分钟，jstack 查出 4 条线程在跳探戈场景：转账服务两个账号互相转账，同时请求导致全部线程 BLOCKED，服务 hang 死路径：现象全景 → 现场还原 → 第一板斧(jstack) → 第二板斧(代码审查) → 第三板斧(lock chain) → 排查地图上篇讲了 Exe

线程池没满，JVM 先 OOM 了——Executors 的并发陷阱场景：订单处理服务使用 Executors.newFixedThreadPool(10) 处理消息队列，上线一年某天突然 OOM。线程池没满、拒绝策略没触发——但堆里躺了 870 万条待处理任务。路径：现象（OOM 现场）→ 还

ScheduledThreadPoolExecutor 定时任务未按时执行排查场景：每 5 秒执行一次的定时任务，实际间隔变成了 8 秒、15 秒、30 秒——越来越慢路径：检查执行时间 → 区分 fixedRate vs fixedDelay → 验证异常处理 → 监控线程池状态上篇讲了核心

核心线程数设错了：过大引发资源竞争、过小导致队列积压场景：8C16G 容器，线程池 200 个核心线程，CPU 50% 但 P99 延迟从 50ms 涨到 800ms 路径：判断任务类型 → 公式计算 → 压测验证 → 持续监控上篇讲了拒绝策略选型失误导致任务静默丢失，这篇我们来看线程池配置里另

线程池满了：拒绝策略选型失误导致任务丢失场景：凌晨批处理对账发现 2 万条数据丢失，系统无任何错误日志路径：模拟提交 → 观察各策略行为 → 检查 handler 类型 → 修复为自定义策略上篇讲了线程池队列积压导致接口全面超时的排查过程，最后提到「拒绝策略不要轻易用 AbortPolicy」

线程池队列积压百万任务，不重启如何诊断？本文是 Java 并发疑难杂症系列的第 2 篇叙事框架：现象 → 排查过程 → 根因 → 修复 → 预防问题现象告警触发某日下午 14:28，用户中心服务的告警群突然被告警机器人刷屏。接口 p99 飙到了 3128ms（阈值 800ms），错误率升

线程 Dump 不会读？从 BLOCKED/WAITING/RUNNABLE 到问题还原系列：Java 并发疑难杂症 | 第 1 篇本文所有命令和输出均来自真实复现环境，可照步骤重现 1. 问题现象 1.1 告警某日早高峰 9:32，支付对账服务告警群弹出：接口响应时间从正常的 50ms 暴