在Java中如何自定义线程池_JavaExecutorService实战解析_技术教程

应手动创建 ThreadPoolExecutor 实例而非使用 Executors 工厂方法，因其可精确控制核心/最大线程数、有界队列、拒绝策略等；Executors 的无界队列和无限线程易引发 OOM 或资源耗尽，且隐藏关键参数。

Java中自定义线程池的核心是使用 ThreadPoolExecutor 构造函数或 Executors 工具类的底层方法，但真正可控、可维护的做法是**绕过 Executors 的快捷工厂方法，手动创建 ThreadPoolExecutor 实例**——这样能明确控制核心线程数、最大线程数、队列类型与容量、拒绝策略等关键参数。

为什么不用 Executors.xxx()？

Executors 提供的 newFixedThreadPool、newCachedThreadPool 等方法看似方便，但存在隐患：

newFixedThreadPool 使用无界 LinkedBlockingQueue，任务持续提交可能导致 OOM；
newCachedThreadPool 允许创建无限线程（上限为 Integer.MAX_VALUE），高并发下易耗尽系统资源；
newSingleThreadExecutor 同样用无界队列，且单点故障风险高；
所有这些方法都**隐藏了拒绝策略和队列细节**，线上出问题时难以定位。

如何正确创建自定义线程池？

推荐使用 ThreadPoolExecutor 的完整构造器：

new ThreadPoolExecutor(
    int corePoolSize,          // 核心线程数（常驻）
    int maximumPoolSize,       // 最大线程数（应对突发）
    long keepAliveTime,        // 非核心线程空闲存活时间
    TimeUnit unit,             // 存活时间单位
    BlockingQueue workQueue,  // 任务队列（必须有界！）
    ThreadFactory threadFactory,         // 自定义线程创建方式（建议设名称）
    RejectedExecutionHandler handler     // 拒绝策略（勿用默认的 AbortPolicy）
);

关键实践建议：

队列优先选 ArrayBlockingQueue（有界）或 SynchronousQueue（不存储，直接移交），避免无界队列；
线程名务必通过 ThreadFactory 设置（如 "biz-task-pool-%d"），便于日志排查；
拒绝策略建议用 CallerRunsPolicy（由调用线程执行任务，自然降速）或自定义策略（如记录告警+落库重试）；
核心线程数参考公式：CPU核数 × (1 + 平均等待时间 / 平均工作时间)，IO密集型可适当调高。

线程池的生命周期管理

线程池不是“创建即用”，需规范启停：

启动后不要立即 shutdown()，应结合业务场景在应用关闭前优雅终止；
调用 shutdown() 停止接收新任务，等待已有任务完成；
必要时调用 shutdownNow() 尝试中断运行中任务（注意：仅对响应中断的代码有效）；
建议在 Spring 中通过 @PreDestroy 或实现 DisposableBean 保证 shutdown 被调用；
监控线程池状态（如 getActiveCount()、getQueue().size()、getCompletedTaskCount()）接入 Prometheus 或日志告警。

实战中的典型配置示例

例如一个处理下游 HTTP 请求的业务线程池：

ThreadFactory namedFactory = new ThreadFactoryBuilder()
    .setNameFormat("http-call-pool-%d")
    .build();

BlockingQueue queue = new ArrayBlockingQueue<>(200);

ThreadPoolExecutor httpExecutor = new ThreadPoolExecutor(
    4,                    // 核心 4 线程（CPU × 2，兼顾 IO 等待）
    12,                   // 最大 12 线程（防突发）
    60, TimeUnit.SECONDS,
    queue,
    namedFactory,
    new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝时由业务线程自己执行
);