最典型“任务当根节点挤爆系统”的起点是线程池队列持续膨胀且为无界队列；常见危险写法包括new linkedblockingqueue()、executors.newfixedthreadpool(n)等，其特征为活跃线程数长期卡在corepoolsize、队列size持续上涨、大量线程waiting在park/take、runnable对象占比异常高。
直接看线程池队列是否在持续膨胀，再确认它是不是无界队列——这是最典型的“任务当根节点挤爆系统”的起点。
一眼识别无界队列风险
常见危险写法：new LinkedBlockingQueue()（没传容量）、Executors.newFixedThreadPool(n)、Executors.newSingleThreadExecutor()。它们底层都用了无界队列，表面稳定，实则埋雷。
关键特征：
- 线程池活跃线程数长期卡在 corePoolSize，几乎不扩容到 maximumPoolSize
- 队列 size 持续上涨，监控中能看到 getQueue().size() 从几十涨到几千甚至上万
- 大量线程处于 WAITING on condition 状态，堆栈停留在
LockSupport.park或LinkedBlockingQueue.take - 堆内存中 Runnable/Callable 对象 占比异常高，且多数未执行
定位堆积任务是否成了“根节点”
所谓“充当根节点”，是指这些待执行任务本身被强引用滞留在队列中，阻止 GC 回收其持有的上下文对象（如 HTTP 请求体、数据库连接、大 byte[]），最终拖垮整个堆。
排查动作：
- 用 jmap -histo:live
查看实例最多的类，重点关注业务相关的 Runnable 匿名类、Lambda 类、或你封装的 Task 类 - 用 mat（Memory Analyzer）打开 heap dump，按 “Group by Class” 排序，点开高占比任务类 → “Merge Shortest Paths to GC Roots” → 若显示 “through java.util.concurrent.LinkedBlockingQueue$Node” ，就坐实了：队列节点是 GC Root
- 检查任务对象内部是否持有大对象（如 Base64 图片字符串、完整 JSON 字符串、InputStream），这类引用会随任务一起钉在堆里
验证任务是否真“卡住”而非“慢执行”
不能只看队列长度，得确认这些任务是否还有机会被执行。
- 查 getActiveCount() 和 getCompletedTaskCount() 的差值是否远小于队列 size —— 若活跃线程极少、完成数增长极慢，说明任务根本没轮上
- 用 Arthas watch 监控任务提交入口：
watch com.xxx.TaskSubmitter submit '{params,returnObj}' -n 5，确认任务确实在进队列，而非被拒绝 - 在任务 run() 方法开头加日志：
log.debug("task {} start at {}", taskId, System.currentTimeMillis());—— 若大量 taskId 出现在日志里却不见 “finish”，就是队列阻塞；若压根不出现，说明连入队都失败（可能是拒绝策略静默丢弃）
紧急止血与配置修正
发现确认后，立刻行动：
- 上线前临时降级：把无界队列换成 ArrayBlockingQueue(200)，配合 CallerRunsPolicy，让过载压力回流到上游线程，倒逼限流生效
- 永久修复配置示例：
10, // core
200, // max
60L, TimeUnit.SECONDS,
new ArrayBlockingQueue(500), // 明确有界
new ThreadPoolExecutor.CallerRunsPolicy() // 不丢任务，也不让内存失控
);
同时必须配套做两件事：监控队列使用率（size / capacity）、记录被拒绝的任务 ID 并告警。
