生产环境应手动创建ThreadPoolExecutor，显式配置核心线程数、最大线程数、队列容量和拒绝策略；submit()适用于需结果和异常处理的场景，execute()仅执行无返回任务；shutdown后须调用awaitTermination等待任务完成。
怎么创建一个能用的线程池
别一上来就写 new ThreadPoolExecutor(...)，大多数场景直接用 Executors 工厂方法更安全。但要注意：它提供的几个静态方法有隐藏陷阱。
-
Executors.newFixedThreadPool(int)底层用的是无界LinkedBlockingQueue，任务堆积时可能 OOM -
Executors.newCachedThreadPool()允许无限创建线程，突发流量下容易耗尽系统资源 - 生产环境推荐手动构造
ThreadPoolExecutor，显式控制核心线程数、最大线程数、队列容量和拒绝策略
例如启动一个最多 8 个线程、队列最多存 100 个任务、超时 60 秒自动回收空闲线程的池：
ThreadPoolExecutor executor = new ThreadPoolExecutor(
4, // corePoolSize
8, // maxPoolSize
60L, // keepAliveTime
TimeUnit.SECONDS,
new ArrayBlockingQueue<Runnable>(100),
new ThreadPoolExecutor.CallerRunsPolicy()
);
submit() 和 execute() 到底该用哪个
区别不在“能不能跑”，而在“要不要结果”和“异常处理方式”。
-
execute(Runnable)：只负责执行，不返回任何东西，如果任务抛出未捕获异常，会直接打印到 stderr，且无法被调用方感知 -
submit(Runnable)或submit(Callable<T>)：返回Future，可主动检查状态、获取结果、等待完成；异常会被包装进Future.get()抛出，便于集中处理 - 如果你需要异步计算结果（比如查数据库后聚合），必须用
submit()+Callable
常见错误：用 execute() 提交可能抛异常的任务，又没配 ThreadFactory 设置 UncaughtExceptionHandler，导致异常静默丢失。
立即学习“Java免费学习笔记（深入）”；
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
线程池 shutdown 的正确姿势
不关干净会导致 JVM 不退出，或任务被丢弃却不通知。关键不是“调 shutdown”，而是“等完再停”。
- 先调
shutdown()：停止接收新任务，但会继续执行已提交和队列中的任务 - 再调
awaitTermination(long, TimeUnit)等待执行完成，建议设合理超时（如 30 秒） - 如果超时仍未结束，可考虑
shutdownNow()尝试中断正在运行的任务（注意：不是所有任务都能被中断）
典型误操作：shutdown() 后立刻 return，没等任务结束，主线程就退出了。
拒绝策略选哪个才不丢任务也不卡死
当线程池满 + 队列满时触发，选错会导致数据丢失或线程阻塞。四种内置策略行为差异很大：
-
AbortPolicy（默认）：直接抛RejectedExecutionException，调用方必须处理，否则崩溃 -
CallerRunsPolicy：由提交任务的线程自己执行该任务，能自然降速，适合非关键任务 -
DiscardPolicy：静默丢弃，不报错，适合允许丢失的监控类任务 -
DiscardOldestPolicy：丢掉队列头任务，再尝试提交当前任务，有一定风险（可能反复丢老任务）
自定义策略可以记录日志、发告警、写入重试队列——但别在拒绝策略里做耗时操作（比如远程调用），会卡住 submit() 线程。
