Java线程池一篇讲透：Executors三大方法、7大参数、4种拒绝策略

大家好，我是晚安code。

Java线程池这篇，我拖到今天才敢写——不是它难，是它太"讲道理"了。网上讲线程池的文章一抓一大把，但大多上来就甩一张参数表，把人看懵。这篇我换种讲法：从"为什么要池化"讲起，用银行柜台把 7 大参数串起来，最后落到 CPU 密集/IO 密集线程数怎么配。点个收藏，我们开始。

一、线程池就一句话：事先备好，用完归还

程序跑起来，本质就是在占系统资源。其中最烧钱的，就是反复创建、销毁线程——每来一个任务就 new 一个线程，用完就扔，高峰期能把机器内存和上下文切换时间全吃光。线程池解决的，正是这个浪费。

池化技术（Pooling）：一种资源管理思想——事先准备好一批资源放在"池子"里，有人要用就来拿，用完再还回去，避免反复创建和销毁。你可以理解为「公共洗衣房，机器随取随用，用完整理好放回」。

线程池（Thread Pool）：池化技术在并发上的落地，提前创建一批线程复用，同时控制最大并发数、统一管理线程。创建、调度、回收这些脏活累活，它全包了。

好处就三条：降低资源消耗（线程复用，不反复建）、提高响应速度（线程现成，来了就能干活）、方便管理（并发数可控，出问题好排查）。

二、先别背参数：Executors 三大方法

Java 里创建线程池最省事的入口是 Executors 工具类，就三个常用方法（2026 年 8 月基于 JDK 8+ 验证）：

// 单线程池：串行执行，像只有一个柜员的银行
ExecutorService pool1 = Executors.newSingleThreadExecutor();

// 固定大小：始终只有 5 个线程，超出进队列排队
ExecutorService pool2 = Executors.newFixedThreadPool(5);

// 可伸缩：遇强则强、遇弱则弱，没人用时线程自动回收
ExecutorService pool3 = Executors.newCachedThreadPool();

问题来了：这三个方法看着简单，生产环境却不建议用——因为它们把 7 大参数全藏起来了。newFixedThreadPool 的队列默认容量是 Integer.MAX_VALUE，请求一多任务全堆进队列，内存直接被撑爆 OOM；newCachedThreadPool 的线程数上限同样是 Integer.MAX_VALUE，并发一冲线程多到飞起，一样 OOM。阿里 Java 开发手册干脆把它写进了强制规范：线程池不允许用 Executors 创建。

我第一次跑出这种 OOM 时，就是这种表情。

可能有人会问：Executors 是不是完全不能用？

不至于。本地 demo、低并发的内部工具，图省事用它没问题；但凡接口要扛线上流量，老老实实手动配 ThreadPoolExecutor，就这。

三、手动创建线程池：7 大参数逐个拆

手动创建线程池，用的就是 ThreadPoolExecutor。它构造器里有 7 个参数，每一个都有明确含义：

ThreadPoolExecutor：JDK 并发包里最核心的线程池实现类，Java 里所有线程池创建方式最终都落在它身上。你可以理解为「线程池的总阀门」。

public ThreadPoolExecutor(
        int corePoolSize,                  // 核心线程数
        int maximumPoolSize,               // 最大线程数
        long keepAliveTime,                // 空闲线程存活时间
        TimeUnit unit,                     // 存活时间的单位
        BlockingQueue<Runnable> workQueue, // 阻塞队列
        ThreadFactory threadFactory,       // 线程工厂
        RejectedExecutionHandler handler)  // 拒绝策略

这 7 个参数看着抽象，用一个场景就全活了——银行办业务：

• 核心线程数 = 常驻柜台窗口，开门就上班
• 最大线程数 = 最多能开几个窗口（含临时加开的）
• 阻塞队列 = 候客区，窗口全忙时进来排队
• 空闲存活时间 = 临时窗口闲太久就撤掉
• 线程工厂 = 给线程起名、定属性，一般不用动
• 拒绝策略 = 大堂都满了，再来人怎么办

阻塞队列（BlockingQueue）：线程池用来暂存"来不及处理"的任务的队列，窗口全忙时任务先在这儿排队，队列满了才走后面的分支。你可以理解为银行的「候客区」。

来看任务提交后的完整流转（图 1）：

流程就一句：核心线程忙 → 进队列排队 → 队列满且线程数没到上限 → 开临时线程 → 全满了 → 走拒绝策略。

现在动手配一个，数字故意调小，方便看清每一段：

ExecutorService pool = new ThreadPoolExecutor(
        2,                           // 核心线程 2 个
        5,                           // 最大线程 5 个
        3, TimeUnit.SECONDS,         // 空闲 3 秒回收
        new ArrayBlockingQueue<>(3), // 队列容量 3
        Executors.defaultThreadFactory(),
        new ThreadPoolExecutor.AbortPolicy());

// 最大承载 = 队列 3 + 最大线程 5 = 8
// 提交 9 个任务，第 9 个会触发拒绝策略
for (int i = 1; i <= 9; i++) {
   
    pool.execute(() -> System.out.println(Thread.currentThread().getName() + " OK"));
}
pool.shutdown();

我第一次跑这段时，盯着"线程名 + OK"看了好一会儿才看懂：前 2 个任务走核心线程，第 3~5 个进队列排队，第 6~8 个开临时线程，第 9 个直接被拒。

四、线程池满了怎么办：4 种拒绝策略

拒绝策略不是越狠越好，选错了，会在最忙的时候悄悄丢任务。

拒绝策略（RejectedExecutionHandler）：线程池满载（队列和最大线程都到顶）时，对"加塞不进来的任务"的处理方案。你可以理解为银行的「满员处理流程」。

四种策略，两种"硬"，两种"软"：

1. AbortPolicy（默认）：直接抛 RejectedExecutionException，任务丢了，但你会立刻知道
2. CallerRunsPolicy：谁提交的，谁自己拿回去跑，不丢任务，但提交方会被拖慢
3. DiscardPolicy：静默丢弃新任务，不抛异常，最危险——丢了没声音
4. DiscardOldestPolicy：把队列里排最久的那条挤掉，让新任务进来

我最开始以为"不抛异常就是好的"，其实恰恰相反——静默丢弃会在线上最忙的时候悄悄丢单，等对账才发现。想到这个场景，血压就上来了。

选策略的核心就一条：能不能接受丢任务，以及丢了要不要有声音。求稳选 CallerRunsPolicy，宁可慢不丢单；省事就接受默认的 AbortPolicy，让异常替你把问题喊出来。

五、最大线程数设多少：CPU 密集 vs IO 密集

最后一个高频问题：核心线程数和最大线程数到底填多少？没有标准答案，但判断标准就一条——看任务是 CPU 吃得多，还是 IO 等得多。

• CPU 密集型：任务在拼命算，线程数设成 CPU 核数最合适，多了反而来回切换更慢
• IO 密集型：任务一大半时间在等（等网络、等磁盘），可以让线程数翻倍，用"等"的时间多干活

// 拿到本机 CPU 核数，它是 CPU 密集型的参考基准
int cores = Runtime.getRuntime().availableProcessors();
// CPU 密集型：核心线程数 ≈ cores
// IO 密集型：核心线程数 ≈ cores * 2 起，压测再微调

IO 密集这个"乘 2"只是起点。我今天的笔记里就写了：程序里 15 个大型任务一大半都在等 IO，线程数就该按"等待时间 / 干活时间"的比例往上加，配完用压测说话。没有标准答案，只能自己试。

好了，Java线程池这一块算是啃完了。它不神秘，就是"事先备好、用完归还"八个字，外加 7 大参数这一整套"银行系统"。生产环境记住一条：别用 Executors，自己配 ThreadPoolExecutor——参数看得见，心里才有底。

可能有人会问：线程池用完一定要 shutdown 吗？

要。非守护线程不关闭，JVM 就不会退出，进程会一直挂着。程序结束前记得 shutdown()，不然会莫名其妙发现进程杀不掉。

参考与说明

• 本文在 Java线程池主题上结合个人学习笔记独立撰写。
• 涉及 JDK 源码与参数以官方文档为准；示例代码基于 JDK 8+（2026 年 8 月验证）。

我是晚安code，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你用 Executors 还是手动配 ThreadPoolExecutor？配线程池踩过哪些坑？