线程池需系统性设计，核心/最大线程数依任务类型设定：cpu密集型为cpu核数+1，io密集型为2～4倍；阻塞队列须有界，禁用无界队列；拒绝策略应匹配业务容错等级，并配套限流、监控、异步化等工程实践。
高并发场景下，线程池不是“多开几个线程”就能解决问题的工具，而是需要结合业务特征、资源边界和失败处理机制做系统性设计。削峰填谷的本质，是让瞬时洪峰流量被缓冲、平滑、可控地消化，而不是靠硬扛或丢弃。
核心线程数与最大线程数要区分任务类型
不能统一按CPU核数设置。CPU密集型任务（如加解密、图像处理）应保守配置，核心线程数建议设为 CPU核数 + 1；IO密集型任务（如HTTP调用、数据库查询）因线程常处于等待状态，可适当放大，常见做法是设为 2～4倍CPU核数。最大线程数则需预留弹性空间，但必须有明确上限——避免线程爆炸拖垮JVM。
- 例如：4核机器处理大量远程API调用，corePoolSize=8，maximumPoolSize=32 是合理区间
- 若任务平均耗时200ms，QPS达500，则理论最小并发需求约100，此时max=32明显不足，需重新评估或引入异步化
- 切忌盲目设成 Integer.MAX_VALUE 或依赖 newCachedThreadPool —— 这是线上OOM高频诱因
阻塞队列选型决定削峰能力与风险边界
队列不是越大越好，也不是越小越安全。它承担着“缓冲器”角色，但过度依赖队列会掩盖真实瓶颈，甚至把内存压垮。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- LinkedBlockingQueue（有界）：推荐用于订单、支付等关键链路，容量显式设为1000或2000，配合拒绝策略快速暴露压力
- ArrayBlockingQueue：性能略优于Linked，适合对吞吐敏感且队列长度可预估的场景
- SynchronousQueue：无缓冲，直接移交任务，适用于短平快任务+动态伸缩模型（如newCachedThreadPool语义），但要求maximumPoolSize足够大且keepAliveTime合理
- 绝对避免使用无界 LinkedBlockingQueue（默认构造）—— 它会让任务无限堆积，最终触发Full GC甚至OOM
拒绝策略必须匹配业务容错等级
当队列满、线程已达上限时，拒绝不是“出错了”，而是系统在主动做取舍。不同策略对应不同业务语义：
- CallerRunsPolicy：由提交线程自己执行任务，能自然降速，适合后台批处理类任务
- AbortPolicy（默认）：抛RejectedExecutionException，适合强一致性场景，调用方必须捕获并做重试/降级
- DiscardPolicy：静默丢弃，仅适用于日志采集、监控上报等非关键路径
- DiscardOldestPolicy：丢弃队列头任务，适合时效性强的推送类任务（如消息通知）
配套机制缺一不可
单靠线程池参数无法实现稳定削峰。必须叠加以下工程实践：
- 任务提交前做轻量级限流（如令牌桶），从源头控制流入速率
- 关键线程池命名+监控埋点，实时观察活跃线程数、队列积压、拒绝率
- 搭配异步非阻塞I/O（如Netty、WebFlux）减少线程阻塞，提升单位线程吞吐
- 将耗时操作（如DB写入、外部调用）剥离到独立线程池，避免主业务线程池被拖死
- 必要时接入消息队列（如Kafka、RocketMQ），把同步调用转为异步事件，真正实现跨系统级削峰
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
