线程池优化需精准匹配任务特征、队列控制行为边界、拒绝策略守住执行底线：CPU密集型设corePoolSize为CPU核数+1，IO密集型取核数×2–4；必须用有界队列并配明确拒绝策略，禁用无界LinkedBlockingQueue；需持续监控activeCount、queue.size及拒绝数，配合命名线程工厂与异常兜底。
线程池优化不是调几个数字，而是让线程资源与业务节奏严丝合缝地咬合。关键在参数匹配任务特征、队列控制行为边界、异常守住执行底线。
按任务类型定线程数
CPU密集型任务（如加解密、图像处理）线程数不宜超过 CPU 核心数 + 1，避免过度上下文切换；I/O密集型任务（如HTTP调用、数据库查询）因线程常处于等待状态，可设为 CPU 核心数 × (1 + 平均等待时间/平均CPU时间)，实践中常取 2–4 倍核心数。例如 16 核服务器跑数据库批量导入，可设 corePoolSize = 24，maximumPoolSize = 48。
- 不要直接用 Executors.newFixedThreadPool() —— 它用无界 LinkedBlockingQueue，任务堆积会 OOM
- 压测时重点观察 activeCount 和 queue.size()：若长期 queue > 70% 容量，说明线程不足或任务响应慢
- 避免 corePoolSize = 0 或 maximumPoolSize 过大（如 > 200），前者延迟高，后者易触发系统级调度抖动
选对队列，管住任务流向
队列不是缓存，是行为控制器。ArrayBlockingQueue（有界）配合拒绝策略，能暴露真实瓶颈；SynchronousQueue（无缓冲）强制“来即执行”，适合短平快任务但要求 maximumPoolSize 必须合理；LinkedBlockingQueue（默认无界）只应在你完全掌控任务生成速率时谨慎使用，否则等于把内存当队列。
- 秒杀类场景推荐 SynchronousQueue + moderate maximumPoolSize，靠快速失败+降级兜底，不积压
- 定时批处理推荐 ArrayBlockingQueue（容量设为单批次最大任务数 × 2），溢出即告警，不掩盖吞吐问题
- 绝对避免 new LinkedBlockingQueue()（无参构造），务必显式指定容量，如 new LinkedBlockingQueue(500)
拒绝策略不是摆设，是熔断开关
CallerRunsPolicy 让调用线程自己执行任务，可自然限流，适合后台任务；DiscardOldestPolicy 丢最老任务，适合实时性要求高的消息处理；自定义策略可结合日志、告警、降级（如写入 Kafka 重试队列）。关键是——拒绝发生时，系统必须“有感”，不能静默丢弃。
立即学习“Java免费学习笔记（深入）”；
- 线上环境禁用 AbortPolicy（抛 RejectedExecutionException），除非上层已统一捕获并兜底
- 搭配监控：每分钟拒绝任务数 > 5 次，自动触发告警；连续 3 分钟 > 20 次，触发线程池扩容或服务降级
- 拒绝后建议记录 task.toString() 或 traceId，便于事后追溯是哪类任务被挡下
运行时必须盯住这三件事
线程池不是配完就完事。要持续看它是否“健康”：有没有线程卡死？队列是不是越堆越长？异常有没有吃掉线程？这些都得靠可观测性落地。
- 通过 Actuator /actuator/threaddump 或 JMX 暴露 getActiveCount()、getCompletedTaskCount()、getQueue().size()
- 为每个线程池命名（用 CustomThreadFactory），jstack 时一眼识别归属，排查阻塞链更快
- 所有 submit(Runnable) 都包装 try-catch，或统一设置 UncaughtExceptionHandler，防止未捕获异常导致线程静默退出
