线程池解决频繁创建销毁线程、资源耗尽和响应延迟问题，通过复用线程、限流和解耦任务提交与调度来提升稳定性；需依cpu/io密集型任务类型合理设置corepoolsize、workqueue、keepalivetime等参数，并选用合适拒绝策略。
线程池解决什么问题
直接创建 Thread 对象执行任务，会导致频繁创建销毁线程、资源耗尽、响应延迟不可控。线程池通过复用已创建的线程、限制并发数、统一管理生命周期，把「任务提交」和「线程调度」解耦。它不是银弹，但能避免大多数因线程滥用引发的 OutOfMemoryError 或 RejectedExecutionException。
如何选对 ThreadPoolExecutor 参数
核心参数不是拍脑袋定的，得结合任务类型反推：
-
CPU 密集型任务：比如大量计算、加解密，
corePoolSize通常设为Runtime.getRuntime().availableProcessors()或 +1，避免线程过多导致上下文切换开销激增 -
IO 密集型任务：比如数据库查询、HTTP 调用，
corePoolSize可设为2 * availableProcessors()甚至更高，因为线程常阻塞在等待响应上 -
workQueue别无脑用LinkedBlockingQueue：它默认无界，容易掩盖负载问题，导致 OOM；高吞吐场景优先考虑SynchronousQueue（配合newCachedThreadPool思路），或有界队列如ArrayBlockingQueue配合拒绝策略 -
keepAliveTime对allowCoreThreadTimeOut(true)生效——只有明确需要动态缩容时才开，否则核心线程常驻更稳
execute() 和 submit() 的行为差异
二者底层都走 execute()，但语义和异常处理完全不同：
-
execute(Runnable)：不返回结果，任务中抛出的未捕获异常会由ThreadFactory设置的UncaughtExceptionHandler处理，若没设置就直接打印到stderr，极易静默失败 -
submit(Runnable)或submit(Callable)：返回Future，异常被封装进Future.get()，必须显式调用才会暴露——不get()就永远看不到异常 - 常见坑：
submit()后忘记get()或没做超时控制，导致主线程卡死或异常丢失
拒绝策略不是摆设，得按场景选
当线程池饱和（队列满 + 线程数达最大）时，新任务触发拒绝策略。JDK 提供四种，但生产环境几乎不用 AbortPolicy（直接抛异常）和 CallerRunsPolicy（让调用线程执行，可能拖垮业务线程）：
立即学习“Java免费学习笔记（深入）”；
-
DiscardPolicy：静默丢弃，适合日志、监控等非关键任务 -
DiscardOldestPolicy：丢弃队列头任务，腾位置给新任务，适合有“新鲜度”要求的场景（如实时行情推送） - 更稳妥的做法是自定义策略：记录被拒任务到本地文件或发告警，再异步重试或降级
public class AlertDiscardPolicy implements RejectedExecutionHandler {
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
// 记录日志 + 上报 Prometheus / 发钉钉
log.warn("Task rejected: {}, pool: {}", r.getClass().getSimpleName(), executor);
Metrics.counter("threadpool.rejected", "name", executor.getThreadFactory().toString()).increment();
}
}线程池的复杂点不在配置本身，而在于它把「资源竞争」「异常传播」「背压控制」全揉在一起。一个没设拒绝策略的无界队列，可能撑爆堆内存；一个没处理 Future.get() 异常的 submit()，会让故障石沉大海。这些细节不写在文档里，只藏在压测失败和线上告警里。
