ThreadPoolExecutor使用时，如何合理配置线程池参数？

🚫 首要原则：拒绝 Executors，手动创建

在生产环境中，严禁使用Executors工具类（如newFixedThreadPool,newCachedThreadPool）来创建线程池。

• newFixedThreadPool/newSingleThreadExecutor: 它们使用LinkedBlockingQueue且默认容量为Integer.MAX_VALUE（无界队列）。当任务提交速度远超处理速度时，队列会无限堆积，最终耗尽内存，引发 OOM。
• newCachedThreadPool: 它允许创建的最大线程数为Integer.MAX_VALUE。在高并发场景下，可能会创建大量线程，导致 CPU 在频繁的上下文切换中耗尽，同样可能引发 OOM。

正确做法是始终使用ThreadPoolExecutor的构造函数手动创建，明确指定所有核心参数，实现对资源的精确控制。

🎯 按任务类型分类配置

配置线程池的第一步是识别你的任务属于哪种类型。不同类型的任务，其资源配置策略截然不同。

1. CPU 密集型任务

• 特征：任务主要消耗 CPU 资源进行计算，如加密解密、数据压缩、复杂算法运算等，线程很少处于等待状态。
• 配置策略：
  • 核心线程数 (corePoolSize)：应尽可能少，以减少线程上下文切换的开销。一个经典的经验公式是CPU 核心数 + 1。这里的+1是为了应对偶尔的页面缺失或其他暂停情况。
  • 最大线程数 (maximumPoolSize)：可以与核心线程数保持一致，或略大一点以应对短暂的峰值。
  • 工作队列 (workQueue)：推荐使用有界队列，如ArrayBlockingQueue，容量不宜过大。
  • 拒绝策略 (handler)：通常使用AbortPolicy，快速失败，以便及时发现问题。

2. IO 密集型任务

• 特征：任务大部分时间在等待 IO 操作完成，如数据库查询、网络请求、文件读写等，CPU 利用率较低。
• 配置策略：
  • 核心线程数 (corePoolSize)：需要设置得较大，以便在一个线程等待 IO 时，其他线程可以利用 CPU。经验公式通常是CPU 核心数 * 2，对于 IO 等待时间特别长的场景，可以设置为CPU 核心数 * 4到8。
  • 最大线程数 (maximumPoolSize)：可以设置为核心线程数的 2 倍左右，以应对流量高峰。
  • 工作队列 (workQueue)：使用有界队列，容量根据业务吞吐量和内存限制来设定。
  • 拒绝策略 (handler)：对于核心业务，建议使用CallerRunsPolicy。当线程池饱和时，由提交任务的线程（如 Web 容器线程）来执行任务，这能有效减缓请求流入的速度，起到“背压”作用，保护后端服务。

3. 混合型任务

• 特征：任务中既有计算也有 IO 操作。
• 配置策略：
  • 线程池隔离：这是最佳实践。将 CPU 密集型和 IO 密集型任务拆分到不同的线程池中执行。这样可以避免慢 IO 任务占满所有线程，导致 CPU 密集任务无法执行，从而实现独立调优，互不影响。

📊 核心参数配置方法论

除了任务类型，还需要结合具体的业务指标进行量化估算。

🛠️ 生产环境实战示例

以下是一个针对 IO 密集型任务的线程池配置示例，它遵循了上述所有最佳实践。

importjava.util.concurrent<