线程池参数设置不当是系统稳定性的必答题，而非性能调优可选项；典型问题包括无界队列配过大最大线程数致OOM、corePoolSize失衡引发资源浪费或吞吐瓶颈、拒绝策略缺失导致任务丢失或雪崩、缺乏可观测性致使故障定位滞后。
线程池参数设置不当，不是性能调优的“可选项”，而是系统稳定性的“必答题”。生产环境里多数线程相关故障——OOM、响应延迟飙升、服务雪崩、线程耗尽——往往都源于几个关键参数的误配，而非代码逻辑本身。
无界队列 + 过大最大线程数 → 堆内存溢出（OOM）
这是最典型的组合陷阱。例如使用 LinkedBlockingQueue()（默认容量为 Integer.MAX_VALUE）搭配 maximumPoolSize = Integer.MAX_VALUE，任务持续涌入时，线程池既不会拒绝任务，也不会限制队列增长，最终导致大量任务对象堆积在堆中，触发 OutOfMemoryError: Java heap space。
- 电商订单系统曾因该配置，在秒杀高峰时订单积压超百万，JVM堆使用率在5分钟内冲至98%
- 修复方式：改用有界队列（如
ArrayBlockingQueue(200)），容量建议设为corePoolSize × 5～10 - 配套启用
CallerRunsPolicy，让提交线程临时执行任务，天然限流
核心线程数失衡 → 资源浪费或吞吐瓶颈
线程数不是越多越好，也不是越少越省。错配会直接反映在CPU和I/O利用率上：
-
CPU密集型任务（如图像转码、加解密）：设为
Runtime.getRuntime().availableProcessors() + 1。线程过多反而引发频繁上下文切换，vmstat中cs（context switch）值异常升高 -
IO密集型任务（如数据库查询、HTTP调用）：可设为
corePoolSize ≈ CPU核心数 × (1 + 平均等待时间 / 平均计算时间)，实践中常取2～4倍核心数 - 避免硬编码大数值（如
corePoolSize = 100），尤其在容器环境下，应基于实际分配的CPU资源动态计算
拒绝策略缺失或误用 → 任务静默丢失或雪崩传导
默认的 AbortPolicy 在队列满时抛异常，若上层未捕获，任务直接失败；而 DiscardPolicy 则完全静默丢弃，监控无感知。
立即学习“Java免费学习笔记（深入）”；
- 金融类业务需强一致性：推荐
CallerRunsPolicy，由调用方降级执行，保留任务不丢失 - 日志/埋点等弱一致性场景：可用
DiscardOldestPolicy，丢弃最旧任务，保障最新数据及时处理 - 务必配合告警：监控
getRejectedExecutionCount()，一旦非零立即触发告警
缺乏可观测性 → 故障定位滞后数小时
很多团队直到服务不可用才想起查线程池，而此时关键线索（如队列峰值、活跃线程拐点）早已淹没在日志里。
- 暴露基础指标：活跃线程数（
getActiveCount()）、队列长度（getQueue().size()）、已完成任务数（getCompletedTaskCount()） - 集成 Micrometer + Spring Boot Actuator，将指标接入 Prometheus/Grafana，设置队列长度 > 80% 容量时告警
- 用 Arthas 快速诊断：
thread -n 5查看最忙线程，thread -state WAITING定位阻塞点（如锁竞争、远程调用未超时）
