最常踩的坑是线程池创建方式选择不当：自动创建（Executors）存在无界队列OOM、线程数失控、拒绝策略不可控三大风险；手动创建需显式控制corePoolSize、maximumPoolSize、有界队列及拒绝策略，并遵循单例复用与任务隔离原则。
Java线程池开发中，最常踩的坑不是“会不会用”，而是“怎么创建”。自动创建看似省事，实则埋雷；手动创建看似繁琐，却是生产环境的底线要求。
自动创建方法（Executors）的三大硬伤
Executors 提供的 newFixedThreadPool、newCachedThreadPool、newSingleThreadExecutor 等方法，本质是封装了固定参数的 ThreadPoolExecutor 实例，但封装得过于“武断”：
-
无界队列风险：如
newFixedThreadPool内部使用LinkedBlockingQueue（默认容量 Integer.MAX_VALUE），任务积压时内存持续上涨，极易触发 OOM； -
线程数失控：如
newCachedThreadPool允许无限创建线程（仅受限于系统资源），高并发下可能抛出java.lang.OutOfMemoryError: unable to create new native thread； -
拒绝策略不可控：默认采用
AbortPolicy（直接抛异常），在关键业务中会导致任务无声丢失或接口报错，缺乏兜底能力。
手动创建（ThreadPoolExecutor）的核心控制点
手动构造 ThreadPoolExecutor 不是为了炫技，而是为了把每个关键行为显式暴露出来，让开发者真正“看得见、管得住”：
- 核心线程数（corePoolSize）：按任务类型设——CPU 密集型建议设为 CPU 核心数 ±1；IO 密集型可设为 2–4 倍核数；
- 最大线程数（maximumPoolSize）：与核心数形成弹性区间，避免资源浪费，也防止无限扩容；
-
有界队列（workQueue）：优先选
ArrayBlockingQueue并明确指定容量（如 1024），让积压可控、失败可感； -
拒绝策略（handler）：不推荐默认
AbortPolicy，可根据场景选CallerRunsPolicy（降级回主线程执行）、DiscardOldestPolicy（丢老任务保新），或自定义策略（如落库重试、发告警）。
线程池生命周期与复用原则
线程池不是一次性的，它应作为单例长期持有，而非每次请求都 new 一个：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
- 频繁新建线程池 = 频繁创建销毁线程 = 资源浪费 + GC 压力上升；
- 全局共享线程池需注意任务隔离——不同业务类型（如支付异步通知 vs 日志归档）不应共用同一池，避免慢任务拖垮快任务；
- 务必配合监控：通过
getActiveCount()、getQueue().size()、getCompletedTaskCount()等指标，及时发现队列堆积、线程饱和等异常。
一个安全的手动创建示例
以下是一个兼顾合理性与可观测性的典型配置：
new ThreadPoolExecutor(
4, // corePoolSize：4核机器上处理IO密集型任务
8, // maximumPoolSize：预留弹性空间
60L, // keepAliveTime：空闲线程60秒后回收
TimeUnit.SECONDS,
new ArrayBlockingQueue<>(256), // 有界队列，最多缓冲256个待执行任务
new ThreadFactoryBuilder().setNameFormat("biz-task-pool-%d").build(),
new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝时由提交线程自己执行，自然限流
);
这个配置把“容量”“缓冲”“熔断”全落在实处，既防 OOM，也防雪崩，还能让问题暴露得更早。
