线程池动态调参

一、监控四大核心指标（缺一不可）

·队列积压量（queue.size()）：最核心信号，持续 > 5000 即告警。
·活跃线程数（activeCount）：若长期等于核心数，说明负载打满。
·任务拒绝数（rejectedCount）：> 0 必须立刻扩容，这是业务受损的直接证据。
·任务平均等待时间：从入队到执行的延迟，比积压量更能反映用户体验。

二、扩缩容决策阈值（黄金法则）

第一步看CPU，超过80%直接熔断禁止扩容。

第二步看队列和拒绝数，如果队列满了或有拒绝，我会扩容。

第三步分情况：如果只是老任务积压，我优先扩核心线程去清淤；如果担心有新任务被拒绝，我先扩最大线程做兜底，再慢慢扩核心。扩的时候都是小步调参，观察10秒再继续。

第四步缩容，只有队列持续为空且响应正常时，我才慢慢缩核心，让线程自己超时死掉，绝不暴力回收。”

三、生产级建议

· 自动化闭环：用 Apollo/Nacos 配置中心 + Prometheus 监控，编写脚本基于阈值自动调用 setCorePoolSize。
· 人工兜底：自动化只做 +10~20% 的微调，大幅度调整必须人工审批。