io密集型线程池配置需动态平衡：核心线程数按w/c比估算（如cpu核数×2～4起步），队列必须有界（推荐arrayblockingqueue或synchronousqueue），maxpoolsize与keepalivetime协同设置（如2×coresize、60秒），拒绝策略首选callerrunspolicy并配合监控。
IO 密集型任务的线程池不能靠“堆数量”硬扛，关键在于让空闲线程及时承接新任务，同时避免资源耗尽和内存失控。配置必须结合等待行为、下游瓶颈与系统承载力来动态平衡。
核心线程数：按 W/C 比估算，而非简单翻倍
单个任务若平均耗时 500ms，其中 450ms 在等网络响应（如 HTTP 调用），则等待时间与 CPU 工作时间之比 W/C ≈ 9，理论并发线程数可接近 CPU 核心数 × (1 + W/C) ≈ 核心数 × 10。但这是上限值，实际应从 CPU 核心数 × 2～4 起步，再通过压测验证：
- 观察吞吐量是否随线程数增加而上升；一旦持平或下降，就回退 1～2 个线程
- 注意数据库连接池（如 HikariCP）、HTTP 客户端（如 OkHttp）本身的并发限制——线程池再大，下游撑不住也会堆积 WAITING 线程
- Spring Boot 默认 spring.task.execution.pool.core-size=8，生产环境务必调高
队列必须有界，优先选 ArrayBlockingQueue
绝不可用 new LinkedBlockingQueue()（默认容量 Integer.MAX_VALUE）。大量 IO 任务排队会持续申请内存，极易触发 OOM。推荐做法：
- 使用
ArrayBlockingQueue，容量按「目标 TPS × 可容忍平均排队时长」预估，例如 1000 QPS × 1 秒 = 容量 1000 - 若追求低延迟且上游可控，可用
SynchronousQueue：不缓存任务，直接触发扩容或拒绝，快速暴露真实瓶颈 - 避免用无界队列掩盖问题——它只是把压力从线程调度转移到内存和 GC
最大线程数与存活时间需协同设置
maxPoolSize 不是越大越好，要配合 keepAliveTime 控制弹性伸缩节奏：
- IO 场景常见配法：maxPoolSize = 2 × corePoolSize，keepAliveTime = 60 秒
- keepAliveTime 设为 0L 会导致频繁创建/销毁线程，加重 GC 压力
- keepAliveTime 过长（如 300 秒）+ maxPoolSize 过大，会使突发流量退去后大量空闲线程长期驻留，浪费内存和文件句柄
- 慎用
allowCoreThreadTimeOut(true)，它会让核心线程也受 keepAliveTime 约束，可能破坏稳定性
拒绝策略首选 CallerRunsPolicy，实现自然反压
当队列满且线程达上限时，CallerRunsPolicy 让提交任务的线程自己执行该任务，效果直接：
- 上游线程被阻塞，天然减缓请求流入速度
- 压力传导回网关或 Nginx，便于统一限流，防止后端雪崩
- 比 AbortPolicy（丢弃）、DiscardPolicy（静默丢失）更利于系统可观测性和稳定性
- 务必配合监控：重点关注
getActiveCount()、getQueue().size()和拒绝任务数，持续高位说明配置已失衡
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
