线程池参数需依业务执行频率动态权衡：高频轻量任务防积压与争抢，低频重量任务避闲置与延迟；先识别任务类型，再结合监控指标与压测验证调参效果。
线程池参数不是固定公式，而是要贴合业务执行频率来动态权衡——高频短任务要防队列积压和线程争抢，低频长任务则需避免资源闲置和响应延迟。
识别业务执行频率特征
先明确任务是“高频轻量”还是“低频重量”，这是调参起点：
- 高频轻量型：如秒级定时统计、API网关鉴权、消息ACK确认，单次耗时通常
- 低频重量型：如报表导出、批量文件解析、跨系统同步，单次耗时常达数秒至分钟级，触发间隔长（如每小时/每天）
- 混合型建议拆分：用不同线程池隔离，避免互相阻塞（例如：I/O密集型任务单独配池）
核心参数与频率的对应关系
重点看三个参数如何随频率变化而调整：
- corePoolSize：设为「平均并发请求数」的 1.2–1.5 倍。高频场景可略高（防突发），低频场景可设为 1–2（避免空转）
- maximumPoolSize：高频场景建议 ≤ corePoolSize × 2（防线程爆炸），低频且偶发长任务时可适当放宽（如设为 core + 4），但不宜超过 CPU 核数 × 2
- workQueue 容量：高频短任务慎用无界队列（如 LinkedBlockingQueue），推荐有界队列（如 ArrayBlockingQueue），容量 ≈ 平均 1–3 秒的请求量；低频任务可用较小队列（如 8–32），配合拒绝策略快速反馈
配合频率选择拒绝策略与存活策略
高频场景下队列满是常态，拒绝策略直接影响稳定性：
立即学习“Java免费学习笔记（深入）”；
- 高频短任务优先选 CallerRunsPolicy：让调用线程自己执行，自然限流，避免丢任务
- 低频长任务可选 AbortPolicy（抛异常）或自定义策略，便于监控告警并触发降级
- keepAliveTime 对高频场景意义不大（线程基本不回收），低频场景建议设为 60–300 秒，及时释放闲置线程
验证与调优方法
参数不是一次设定就完事，需结合真实流量观察：
- 用 Micrometer + Prometheus 监控 activeCount、poolSize、queueSize、rejectedExecutionCount
- 高频场景重点关注 queueSize 是否持续 > 70% 容量、rejectedExecutionCount 是否突增
- 低频场景关注 peak poolSize 是否长期远低于 maximumPoolSize（说明配置过大）
- 压测时模拟真实频率节奏（如每秒 200 次请求持续 5 分钟），而非只看峰值吞吐
