高响应系统线程池需精准匹配任务特征与承载边界：核心线程数按cpu或i/o密集型设定；最大线程数与有界队列协同控弹性；空闲时间设10～30秒平衡响应与资源；拒绝策略依业务语义选型。
高响应系统对线程池的参数设置极为敏感——不是越大越好，也不是越小越省资源，而是要让线程数、队列容量和存活策略精准匹配任务特征与系统承载边界。
核心线程数（corePoolSize）：稳态吞吐的锚点
它决定系统在常规负载下能并行处理多少任务，且这些线程长期驻留，不因空闲而销毁（除非启用 allowCoreThreadTimeOut）。
- CPU密集型任务（如计算、编码、加密）：设为 Runtime.getRuntime().availableProcessors()，避免线程争抢CPU导致频繁上下文切换
- I/O密集型任务（如HTTP调用、数据库读写、文件操作）：通常设为 2×CPU核心数～4×CPU核心数，预留空间等待I/O返回
- 混合型任务：可先按I/O比例估算，再结合压测结果下调——例如8核机器上，从16起步，逐步收敛到10～12
最大线程数（maximumPoolSize）与任务队列（workQueue）：应对突发的关键组合
二者协同决定线程池“弹性扩容”的能力边界。错误搭配会导致要么永远不扩容，要么瞬间打爆内存。
- 选 SynchronousQueue：无缓冲，任务直接移交线程执行；此时 maximumPoolSize 必须显著大于 corePoolSize（如 2×～3×），否则稍一并发就触发拒绝策略
- 选 ArrayBlockingQueue（有界）：例如容量设为 200，则当 corePoolSize=8 且队列满时，才开始创建非核心线程，直到达 maximumPoolSize（建议设为 16～24）；这种组合最可控，推荐用于高响应要求场景
- 避免 LinkedBlockingQueue（无界）：默认容量 Integer.MAX_VALUE，任务持续涌入会无限堆积，OOM风险极高；若真需大缓存，请显式指定合理容量（如 1000），并同步调高 maximumPoolSize 以保障队列满后仍可扩容
空闲线程存活时间（keepAliveTime + unit）：平衡资源释放与响应延迟
它只约束超出 corePoolSize 的非核心线程，控制它们在无事可做时多久退出。设置过短会频繁启停线程；过长则浪费资源。
- 微服务/网关类高响应系统：建议 keepAliveTime = 10～30 秒，unit 用 TimeUnit.SECONDS；既能快速回收冗余线程，又避免突发流量来临时重新创建开销
- 后台批处理系统：可设为 5～10 分钟，减少线程反复创建销毁的抖动
- 注意：若启用 allowCoreThreadTimeOut(true)，该时间也适用于核心线程——慎用，除非你明确需要“零线程待命”模式
拒绝策略（handler）：最后一道防线的业务语义
当线程已达 maximumPoolSize 且队列已满，新任务必须被处置。选择取决于你能否容忍丢失、延迟或阻塞。
- AbortPolicy（默认）：抛出 RejectedExecutionException ——适合不允许丢任务、且上层有重试或降级逻辑的场景
- CallerRunsPolicy：由提交线程自己执行任务 ——可自然节流，但会拖慢调用方，适用于非关键路径或低频突发
- DiscardOldestPolicy：丢弃队列头任务，重试提交当前任务 ——适合任务有天然时效性（如实时行情更新），老任务本就该被淘汰
- 生产环境建议封装自定义 handler，记录日志+上报指标，便于事后分析瓶颈根源
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
