corePoolSize 和 maximumPoolSize 应依任务类型设定：IO 密集型用公式计算，CPU 密集型≈CPU 核数；maximumPoolSize 仅在有界队列下有效，LinkedBlockingQueue 默认无界致其失效；keepAliveTime 建议60秒，过短增调度压力，过长占资源；拒绝策略应自定义日志告警而非直接使用JDK默认策略。
corePoolSize 和 maximumPoolSize 怎么设才不踩坑
这两个参数决定线程池“常态”和“峰值”能开多少线程，设错直接导致 CPU 打满或任务积压。关键不是拍脑袋定数字，而是看任务类型：
IO 密集型：corePoolSize ≈ CPU 核数 × (1 + 平均等待时间 / 平均工作时间)<br>CPU 密集型：corePoolSize ≈ CPU 核数（通常 2–4 倍也够用，再高反而上下文切换开销大）maximumPoolSize 一般只在使用
LinkedBlockingQueue（无界队列）时才真正起作用——但注意：LinkedBlockingQueue 默认容量是 Integer.MAX_VALUE，等于事实上的无界，此时 maximumPoolSize 完全失效，所有新任务都会进队列，线程数永远卡在 corePoolSize。所以除非你明确要用有界队列+动态扩容，否则别乱调大 maximumPoolSize。
keepAliveTime 设太短或太长各有什么后果
keepAliveTime 控制空闲线程的存活时长，单位由 TimeUnit 指定。设太短（比如 10ms）会导致线程频繁销毁重建，增加 GC 和调度压力；设太长（比如 30 分钟）则可能让大量空闲线程长期占着内存和句柄，尤其在线程数曾被顶到 maximumPoolSize 后回落时更明显。
- 默认场景建议设为 60 秒，配合
allowCoreThreadTimeOut(true)可让 core 线程也参与超时回收 - 若任务突发性强、间隔长（如每小时一次批处理），可设为 5–10 分钟
- 绝对不要用
TimeUnit.DAYS或TimeUnit.HOURS，除非你真需要线程永不退出
拒绝策略（RejectedExecutionHandler）选哪个，怎么自定义
当队列满且线程数已达 maximumPoolSize 时触发。JDK 自带四种策略，但生产环境基本不能直接用：
-
AbortPolicy：抛RejectedExecutionException—— 最危险，可能让上游静默失败 -
CallerRunsPolicy：由提交线程自己执行任务 —— 会拖慢调用方，适合低吞吐、强一致性场景 -
DiscardPolicy/DiscardOldestPolicy：静默丢弃 —— 数据丢失风险高，仅限日志等可丢场景
toString()、堆栈、提交时间，并发异步告警或落库待补偿。示例关键逻辑：public class LoggingRejectHandler implements RejectedExecutionHandler {<br> private static final Logger log = LoggerFactory.getLogger(LoggingRejectHandler.class);<br><br> @Override<br> public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {<br> log.warn("Task rejected: {}, pool: active={} queue={} poolSize={} max={}",<br r, executor.getActiveCount(), executor.getQueue().size(),<br executor.getPoolSize(), executor.getMaximumPoolSize());<br }<br>}
workQueue 用 ArrayBlockingQueue 还是 SynchronousQueue
这不是性能高低问题，而是语义取舍：
-
ArrayBlockingQueue：有界，适合想控制总资源消耗的场景。容量必须显式指定（比如 1024），否则容易因队列积压掩盖线程不足问题 -
SynchronousQueue：无缓冲，每个put()必须立刻有take()配对，本质是“手递手”传递任务。它迫使线程池优先复用现有线程，只有没空闲线程时才新建，直到达maximumPoolSize才触发拒绝策略 —— 这才是“真正的”线程池弹性行为 -
LinkedBlockingQueue（无界）：慎用。表面稳定，实则把背压转移到内存，OOM 风险极高
SynchronousQueue；任务耗时长 + 需削峰填谷 → 选有界 ArrayBlockingQueue；别碰无界队列，除非你监控到位且能接受 OOM。立即学习“Java免费学习笔记（深入）”；
线程池调优最常被忽略的一点：没有绑定监控指标。光调参数没用，得实时看 getActiveCount()、getQueue().size()、getCompletedTaskCount() 和拒绝次数。否则你根本不知道 corePoolSize 是设高了还是低了。
