🚫 首要原则：拒绝 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 密集任务无法执行，从而实现独立调优，互不影响。📊 核心参数配置方法论除了任务类型，还需要结合具体的业务指标进行量化估算。参数配置规则与推导逻辑核心线程数 (corePoolSize)基础公式：CPU 核心数 * (1 + 等待时间 / 计算时间)业务公式：稳态 QPS * 平均响应时间(秒)。例如，QPS 为 1200，平均响应时间 150ms，则核心线程数至少为1200 * 0.15 = 180。最大线程数 (maximumPoolSize)用于应对突发流量。可估算为：corePoolSize + (突发QPS增量 * 响应时间 / 0.8)。其中 0.8 是线程创建开销的折损系数。工作队列 (workQueue)必须使用有界队列（如ArrayBlockingQueue）。队列容量可根据内存约束计算：(可用堆内存 * 安全水位) / 单个任务平均对象大小。例如，1.2GB 可用内存，每个任务 8KB，则队列容量约为 150000。空闲线程存活时间 (keepAliveTime)非核心线程空闲多久后被回收。建议设置为P95 响应时间 * 3左右，确保突发流量回落后，临时线程能被及时回收。拒绝策略 (handler)核心业务：CallerRunsPolicy（调用者执行），避免任务丢失，实现自然限流。非核心业务：AbortPolicy（抛异常），快速失败。高级用法：自定义拒绝策略，实现日志记录、监控告警、任务持久化到数据库以便后续重试等降级逻辑。线程工厂 (ThreadFactory)强制要求：自定义线程工厂，为线程设置有意义的名称（如order-service-pool-1），便于线上问题排查。🛠️ 生产环境实战示例以下是一个针对 IO 密集型任务的线程池配置示例，它遵循了上述所有最佳实践。importjava.util.concurrent