IO密集型任务应以CPU核心数×2～4设corePoolSize，maximumPoolSize不超过其2倍；用ArrayBlockingQueue限容配合理拒绝策略；结合异步、批处理与非阻塞提升吞吐。
IO密集型任务在线程池中主要卡在等待网络响应上，CPU实际占用低，但线程被阻塞挂起。提升网络通信中的变量并发吞吐，关键不是堆线程数，而是让有限线程更高效地“轮转”处理请求，减少空等、避免堆积、控制资源边界。
核心线程数与最大线程数的合理设定
盲目设高线程数会加剧上下文切换，反而拖慢整体吞吐。推荐以 CPU 核心数为基准动态估算：
- 基础值：取 Runtime.getRuntime().availableProcessors() × 2～4 作为 corePoolSize，覆盖常见 IO 等待比（如等待时间:处理时间 ≈ 3:1 时，×4 更稳）
- 上限控制：maximumPoolSize 建议不超过 corePoolSize × 2，防止突发流量触发大量线程创建导致 GC 频繁或内存陡增
- 实测建议：从 ×3 开始压测，观察平均响应时间、线程活跃率（jstack 或 Micrometer 指标）、TPS 变化趋势，而非只盯 CPU 使用率
队列选型与容量必须有界
无界队列（如默认 LinkedBlockingQueue）是生产环境的高危配置，它会让拒绝策略失效，任务持续堆积引发 OOM 和 GC 停顿。
- 首选 ArrayBlockingQueue，显式指定容量（如 500～2000），配合拒绝策略快速暴露瓶颈
- 若需短时弹性（如秒杀预热），可考虑 SynchronousQueue，但仅适用于平均负载低、突发持续时间短的场景
- 绝对避免 PriorityBlockingQueue——排序开销大，且破坏任务执行顺序公平性，实测吞吐常下降 30% 以上
拒绝策略要能兜底并反馈问题
当队列满、线程达上限时，拒绝不是失败，而是系统健康信号。选错策略会导致雪崩或掩盖真实瓶颈。
- CallerRunsPolicy：适合对延迟敏感、允许降级的接口，由调用方线程执行任务，自然限流并降低提交速率
- 自定义拒绝策略：记录日志 + 上报监控（如 Prometheus counter），同时返回降级结果（如缓存值、默认值），保障可用性
- 禁用 AbortPolicy（静默丢弃）和 DiscardOldestPolicy（丢旧任务），它们无法帮助定位根因
配套优化不可少：异步+批处理+非阻塞
单靠调大线程池参数只是治标。真正释放 IO 吞吐潜力，需结合编程模型升级：
- 用 CompletableFuture + 非阻塞 HTTP 客户端（如 Netty-based WebClient）替代 RestTemplate，把等待转为回调，线程不阻塞
- 对高频小变量读写，合并为 批量请求（如一次查 50 个 key 而非循环 50 次），大幅减少网络往返次数
- 避免在任务中混入 CPU 密集操作（如 JSON 序列化大对象），否则 GIL 或线程争用会拖垮整个池
