线程池参数需按业务负载类型动态适配：CPU密集型设核心数+1线程、小容量ArrayBlockingQueue、AbortPolicy；IO密集型设核心数2～4倍线程、LinkedBlockingQueue限容、CallerRunsPolicy；混合/突发型用SynchronousQueue+监控告警；容器环境须按cgroup动态计算CPU核数。
线程池参数不能一套配置打天下，必须按业务负载类型动态适配。关键不是套公式，而是理解任务行为对线程资源的真实消耗方式。
CPU密集型任务：控制并发，减少争抢
这类任务（如图像压缩、数值计算、加解密）几乎持续占用CPU，线程数过多反而引发频繁上下文切换，拖慢整体吞吐。
- 核心线程数设为 CPU核心数 + 1，例如8核机器设为9，留一个冗余应对瞬时调度抖动
- 最大线程数不宜超过核心数的1.5倍，避免线程“挤”在一起抢CPU
- 推荐使用 ArrayBlockingQueue 配合较小容量（如50～100），防止任务堆积占用过多内存
- 拒绝策略建议用 AbortPolicy 或自定义策略快速失败，避免低优先级任务阻塞高优先级计算
IO密集型任务：扩大并发，覆盖等待间隙
这类任务（如HTTP调用、数据库查询、文件读写）大部分时间在等待网络或磁盘响应，CPU空闲率高，可并行更多线程来“填满”等待窗口。
- 核心线程数建议设为 CPU核心数 × 2 ～ 4，例如8核可设16～32，具体值需结合平均IO等待时长压测确定
- 最大线程数可设为核心数的8～10倍（如8核设64～80），但需配合JVM堆内存与系统文件句柄上限做约束
- 队列选 LinkedBlockingQueue 可接受，但务必显式指定容量（如200），禁用无界默认构造
- 拒绝策略倾向 CallerRunsPolicy，让上游线程降速提交，比丢弃或抛异常更能维持服务水位
混合型与突发型负载：分层+监控驱动
真实业务常是混合型（如Web请求中既有DB查询又有本地计算），且流量存在明显波峰波谷。硬编码固定参数风险高。
立即学习“Java免费学习笔记（深入）”；
- 用 SynchronousQueue 搭配较大 maximumPoolSize，实现“来一个任务启一个线程”，适合短平快、波动剧烈的场景
- 通过 Spring ThreadPoolTaskExecutor 或 Micrometer + Prometheus 暴露活跃线程数、队列长度、拒绝数等指标
- 设置告警阈值：当队列填充率持续 >80% 或活跃线程数达 max 的90%，触发参数微调或扩容预案
- 预热机制很重要：启动时调用
prestartAllCoreThreads()，避免冷启动瞬间大量任务排队
容器与云环境下的特别约束
在K8s或Docker中，线程池不再只看物理机CPU，而要对齐容器的 cpu.shares 或 cpu quota 限制。
- 读取
/sys/fs/cgroup/cpu/cpu.cfs_quota_us和/sys/fs/cgroup/cpu/cpu.cfs_period_us动态算出可用CPU核数，而非直接调Runtime.getRuntime().availableProcessors() - 堆内存紧张时，队列容量必须严格限制，避免 LinkedBlockingQueue 默认的 Integer.MAX_VALUE 导致 OOM
- 拒绝策略可扩展：记录被拒任务到日志或消息队列，后续异步重试或告警，尤其适用于支付、订单类关键链路
