在Java里如何使用线程池提升并发性能_Java线程池工作原理说明_技术教程

直接 new Thread() 会拖垮系统，因每创建一个线程需分配1MB栈内存、触发内核调度、带来创建/销毁开销，高并发下易导致OOM、上下文切换爆炸和延迟飙升；线程池是Java并发基础设施，应避免Executors工厂方法的陷阱，优先使用显式配置的ThreadPoolExecutor。

为什么直接 new Thread() 会拖垮系统

每创建一个 Thread 对象，JVM 就要分配栈内存（默认 1MB）、触发内核线程调度、经历创建/销毁开销。高并发下频繁新建线程会导致：OOM（堆外内存耗尽）、CPU 上下文切换爆炸、响应延迟飙升。线程池不是“可选优化”，而是 Java 并发的基础设施。

Executors 工厂方法的坑必须避开

Executors 提供的静态方法看似方便，但多数在生产环境是危险的：

Executors.newFixedThreadPool(n)：底层用的是无界 LinkedBlockingQueue，任务持续堆积会吃光堆内存
Executors.newCachedThreadPool()：最大线程数为 Integer.MAX_VALUE，突发流量可能瞬间创建数千线程，直接把机器压垮
Executors.newSingleThreadExecutor()：单线程，无法利用多核，且未暴露 ThreadPoolExecutor 的可调参数

正确做法是直接构造 ThreadPoolExecutor，明确控制核心线程数、最大线程数、队列容量和拒绝策略：

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    4,                    // corePoolSize
    8,                    // maximumPoolSize
    60L,                  // keepAliveTime
    TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(100),  // 有界队列，防内存溢出
    new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝时由提交线程自己执行
);

如何设置 corePoolSize 和 maximumPoolSize

没有银弹公式，但有可落地的判断逻辑：

CPU 密集型任务（如加解密、图像处理）：corePoolSize ≈ CPU 核数（Runtime.getRuntime().availableProcessors()），maximumPoolSize 通常不放大，避免上下文切换损耗
I/O 密集型任务（如数据库查询、HTTP 调用）：corePoolSize 可设为 2 × CPU 核数 或更高，因为线程常阻塞在 I/O，需要更多线程维持吞吐
混合型任务：先按 I/O 密集估算，再通过压测观察 CPU 使用率和 GC 频率，动态调整

注意：corePoolSize 是长期存活的线程数；maximumPoolSize 只有在队列满且当前线程数 maximumPoolSize 时才会创建新线程——这个“扩容”行为本身就有成本，别指望它扛住突发流量。