推荐手动构造ThreadPoolExecutor，因其可显式控制队列容量、线程数上限、拒绝策略、线程工厂及监控调参，避免Executors默认方法导致的OOM或失控问题。
Java中自定义线程池的核心是使用ThreadPoolExecutor构造函数，而不是依赖Executors工具类提供的“快捷”方法——后者创建的线程池在高并发或任务异常堆积时容易引发OOM或拒绝策略失控等问题。
为什么推荐手动构造ThreadPoolExecutor
Executors.newFixedThreadPool()、newCachedThreadPool()等方法封装了默认参数，但隐藏了关键控制点：比如无界队列（LinkedBlockingQueue无参构造）、无限制的线程增长（Integer.MAX_VALUE核心/最大线程数）、默认的AbortPolicy拒绝策略。生产环境需要显式掌控这些行为。
- 队列容量需结合业务吞吐与内存约束设定（如用
ArrayBlockingQueue(100)代替无界队列） - 核心线程数建议参考CPU密集型（
cpu核心数 + 1）或IO密集型（cpu核心数 × (1 + 平均等待时间/平均工作时间)）经验公式 - 最大线程数不宜设为
Integer.MAX_VALUE，应设合理上限（如50~200），避免线程过多拖垮JVM
如何设置合理的拒绝策略
当线程池饱和（线程数达上限且队列已满）时，拒绝策略决定新任务的处理方式。JDK提供4种内置策略，但多数场景需自定义：
-
AbortPolicy（默认）：直接抛RejectedExecutionException，适合强一致要求、不可丢任务的场景 -
CallerRunsPolicy：由提交线程自己执行任务，可自然降速，适合突发流量但允许延迟的场景 - 自定义策略示例：记录日志 + 落库重试 + 发送告警
写法：new ThreadPoolExecutor(..., new RejectedExecutionHandler() { public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { /* 自定义逻辑 */ } })
线程工厂：统一命名与异常处理
通过ThreadFactory可为线程池内所有线程指定名称前缀、设置守护状态、捕获未处理异常：
- 命名便于排查问题（如
"order-processor-pool-%d"） - 设置
setUncaughtExceptionHandler防止线程因异常静默退出 - 避免使用
Executors.defaultThreadFactory()，它不支持自定义命名
简单实现：new ThreadFactoryBuilder().setNameFormat("my-pool-%d").setUncaughtExceptionHandler((t, e) -> log.error("Thread {} crashed", t.getName(), e)).build()（若用Guava）；或手写匿名类/lambda
监控与动态调参：让线程池“活”起来
线程池不是配置完就一劳永逸的。可通过暴露JMX、集成Micrometer或定期打印指标来观察运行状态：
- 关注核心指标：活跃线程数（
getActiveCount()）、队列大小（getQueue().size()）、已完成任务数（getCompletedTaskCount()）、拒绝任务数（需自定义拒绝策略中计数） - 支持运行时调整：调用
setCorePoolSize()、setMaximumPoolSize()、setKeepAliveTime()（注意部
分参数调整有生效条件） - 配合Spring可注入
@ConfigurationProperties类，实现配置中心驱动的动态刷新
分参数调整有生效条件）不复杂但容易忽略
