线程池需动态调优而非静态配置，应基于任务耗时、等待时间、队列积压和活跃线程波动等指标，用轻量监控驱动安全微调。

复杂业务重构中，线程池不再是“设一次就不管”的静态配置，而是需要随流量特征、任务行为和系统状态实时响应的运行时组件。关键不在于记住七个参数的定义，而在于理解它们如何在重构场景中相互牵制、动态博弈。

识别重构期的任务行为漂移

业务重构常带来任务耗时分布、阻塞比例、并发模式的显著变化。比如从同步调用改为异步补偿，或引入新缓存层导致IO等待时间缩短。此时需重点监控：

• 平均任务执行时间（compute time）与平均等待时间（wait time），用于校准 corePoolSize 公式：CPU核数 × (1 + wait/compute)
• 队列平均积压深度与峰值长度，判断 workQueue 容量是否仍匹配当前突发节奏
• 活跃线程数波动幅度和非核心线程创建频次，暴露 maximumPoolSize 是否过紧或冗余

用轻量级监控驱动参数微调

避免在业务主线程中做复杂计算，推荐用独立守护线程每10–30秒采样一次关键指标，并触发安全范围内的参数调整：

• 当 workQueue.size() > 队列容量 × 0.7 且持续2个周期，可 increment corePoolSize（每次+1，上限 ≤ maximumPoolSize）
• 当 getActiveCount()
• 若 rejectCount 在1分钟内上升明显，优先检查 handler 是否适配（如 CallerRunsPolicy 可缓解瞬时尖峰，但会拖慢调用方）

按任务域隔离 + 分层弹性策略

重构中不同模块演进节奏不一，强行共用一个线程池易互相拖累。建议：

• 拆分线程池：读服务、写事务、定时补偿、消息投递各用独立 ThreadPoolExecutor，参数按各自 SLA 单独调优
• 核心任务池保守配置：corePoolSize 固定为 CPU 核数 + 1，workQueue 用 ArrayBlockingQueue（容量=预估TPS×P99延迟），拒绝策略选 AbortPolicy + 告警
• 非核心任务池弹性配置：corePoolSize 初始为2，maximumPoolSize 设为20，keepAliveTime = 10s，搭配 SynchronousQueue，让线程“即来即走”

拒绝策略与可观测性必须绑定

重构期间异常路径增多，拒绝不是失败信号，而是关键反馈源：

• 每种拒绝策略都配套埋点：AbortPolicy 记录堆栈+任务类型；CallerRunsPolicy 统计调用方线程阻塞时长；DiscardOldestPolicy 跟踪被丢弃任务的入队时间戳
• 把 rejection rate、queue wait time、active thread count 做成看板核心指标，与业务成功率、延迟 P95 同屏对比
• 上线前用混沌工程注入延迟/失败，验证线程池在任务变慢、下游抖动等典型重构风险下的退化表现