应按任务类型匹配线程池规模：cpu密集型设为cpu核心数+1，io密集型用公式cpu核心数×(1+平均等待时长÷平均cpu耗时)；必须使用有界队列（如arrayblockingqueue或synchronousqueue）；拒绝策略优选callerrunspolicy实现反压；不同业务需线程池隔离并监控活跃线程数、队列积压量和拒绝任务数。
按任务类型匹配线程池规模
资源竞争往往源于线程数与任务特性错配。CPU密集型任务（如实时风控计算、图像编码）应限制并发线程数，避免频繁上下文切换——核心线程数设为 CPU核心数 + 1 即可；IO密集型任务（如HTTP调用、数据库查询）因大量时间处于等待状态，可适当提高并发度，推荐公式：CPU核心数 × (1 + 平均等待时长 ÷ 平均CPU耗时)。例如单任务平均500ms，其中450ms在等网络响应，则理论线程数可接近核心数×10，但必须配合有界队列与拒绝策略做压力验证，不能仅靠公式拍板。
用有界队列控制资源水位
无界队列是资源竞争失控的隐形推手。使用 new LinkedBlockingQueue()（默认容量为 Integer.MAX_VALUE）会让所有新任务排队堆积，内存随请求量线性增长，最终OOM。必须显式选用有界队列：ArrayBlockingQueue 是首选，容量建议按业务峰值TPS × 可容忍最大排队时长预估（如200 TPS × 5秒 = 1000）；若追求低延迟且上游具备限流能力，SynchronousQueue 更合适——它不缓存任务，直接触发线程扩容逻辑，让系统瓶颈提前暴露，倒逼流量治理。
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
拒绝策略选 CallerRunsPolicy 实现反压
当线程池与队列都满时，CallerRunsPolicy 让提交任务的线程自己执行该任务，天然形成反压机制：上游线程被阻塞，自然减缓请求提交速率。这比 AbortPolicy（丢任务抛异常）或 DiscardPolicy（静默丢失）更能保护系统稳定性。尤其在Web层接入线程池时，它能把压力传导回Nginx、API网关或客户端，避免后端雪崩。注意：该策略对上游调用方有阻塞影响，需确保其能承受短时延迟。
线程池隔离 + 监控驱动调优
不同业务任务混用同一套线程池极易引发资源抢占。应按优先级、SLA、失败影响范围进行垂直隔离——例如将支付核心链路、用户登录、日志异步落盘分别配置独立线程池，防止慢日志任务拖垮支付处理。同时必须监控三项关键指标：活跃线程数（是否长期逼近 maximumPoolSize）、队列积压量（是否持续上升）、拒绝任务数（是否突增）。可用 Micrometer 对接 Prometheus，设置告警阈值（如队列使用率＞80%持续1分钟即预警），再结合动态调整能力（如 Spring 的 ThreadPoolTaskExecutor 支持运行时修改 corePoolSize）实现闭环优化。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
