在现代 Java 应用中，多线程几乎是处理高并发、提升系统吞吐量的标配。但如果你每次有任务就new Thread().start()，那你的系统迟早会崩溃——不是因为逻辑错误，而是因为资源耗尽。
线程池（Thread Pool），正是为了解决这一问题而生。它就像一个“调度中心”，统一管理线程的创建、复用与销毁，避免频繁创建/销毁线程带来的性能开销，同时防止无限制创建线程导致内存溢出（OOM）。不论是日常开发还是求职面试中，都必须掌握。今天，我们就来深入聊聊 Java 中的线程池：从基础用法到核心原理，再到真实生产踩坑经验，帮你避开那些“看似无害却致命”的陷阱。
为什么需要线程池？
想象一下：你开了一家快递分拣中心。每来一个包裹（任务），你就临时雇一个人（线程）去处理。如果包裹少还好，但如果突然来了上万个包裹，你是不是要雇上万人？不仅成本爆炸，场地（内存）也撑不住。
更糟的是，人来了又走，频繁招聘和解雇（线程创建/销毁）本身就很耗时。而线程池就像一支常驻的分拣团队：固定人数，按需分配任务，干完活不走，等下一个包裹。这样既省资源，又高效。
在 Java 中，线程是操作系统级别的资源，创建和上下文切换开销大。若不加控制地创建线程，轻则性能下降，重则 OOM。线程池通过复用线程 + 限流机制，完美解决了这个问题。
Java 中线程池的基本用法
Java 提供了java.util.concurrent包来支持线程池。最常用的创建方式是通过Executors工厂类：
// 固定大小线程池 ExecutorService fixedPool = Executors.newFixedThreadPool(4); // 缓存线程池（适合短任务） ExecutorService cachedPool = Executors.newCachedThreadPool(); // 单线程池（保证顺序执行） ExecutorService singlePool = Executors.newSingleThreadExecutor(); // 定时任务线程池 ScheduledExecutorService scheduledPool = Executors.newScheduledThreadPool(2); 但！强烈建议不要直接使用 Executors 创建线程池。原因我们后面会讲。更推荐的方式是显式使用ThreadPoolExecutor构造函数，明确指定所有参数：
ThreadPoolExecutor executor = new ThreadPoolExecutor( 2, // corePoolSize 4, // maximumPoolSize 60L, // keepAliveTime TimeUnit.SECONDS, new LinkedBlockingQueue<>(100), // 有界队列 new ThreadFactoryBuilder().setNameFormat("my-pool-%d").build(), new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略 );这样写虽然啰嗦，但可控、可读、可维护，是生产环境的最佳实践。
ThreadPoolExecutor 核心参数详解
ThreadPoolExecutor 的构造函数有 7 个参数，每个都至关重要：
- corePoolSize 核心线程数。即使空闲，这些线程也不会被回收（除非设置 allowCoreThreadTimeOut(true)）。
- maximumPoolSize 最大线程数。当任务队列满且当前线程数 < max 时，会创建新线程。
- keepAliveTime 非核心线程空闲时的存活时间。超过此时间未被使用，会被回收。
- unit keepAliveTime 的时间单位。
- workQueue 任务队列。用于缓存提交但未执行的任务。必须是有界队列！
- threadFactory 线程工厂。用于自定义线程名称、优先级、是否守护线程等。
- handler 拒绝策略。当线程数达上限且队列满时，如何处理新任务。
🧠 执行流程（关键！）:
- 如果当前线程数 < corePoolSize → 创建新线程执行任务；
- 否则，尝试将任务放入 workQueue；
- 如果队列已满，且当前线程数 < maximumPoolSize → 创建新线程；
- 如果队列满 + 线程数已达上限 → 触发拒绝策略。
⚠️ 注意：只有当workQueue.offer()失败（即队列满）时，才会尝试创建超过 corePoolSize 的线程！
日常实践：线程数、队列、拒绝策略怎么设？
- 线程数设置
CPU 密集型任务（如计算、加密）：
- 线程数 ≈ CPU 核数 + 1（+1 是为了防止某线程因页缺失等阻塞）
- 可通过 Runtime.getRuntime().availableProcessors() 获取核数。
IO 密集型任务（如数据库查询、HTTP 调用）：
- 线程数 ≈ CPU 核数 * (1 + 平均等待时间 / 平均计算时间)
- 实际中可设为 2 * CPU 核数 起步，再根据压测调整。
上面是理论的调参建议，实际项目中需要不断验证压测，找到最佳平衡点。
- 任务队列：一定要有界！
绝对不要用Executors.newFixedThreadPool()默认的LinkedBlockingQueue（无界队列）！ 它的容量是Integer.MAX_VALUE，意味着任务可以无限堆积，最终导致 OOM。
✅ 正确做法：使用有界队列，如：
- ArrayBlockingQueue（基于数组，有界，FIFO）
- LinkedBlockingQueue(capacity)（显式指定容量）
- 队列大小建议根据业务峰值 QPS、平均任务处理时间估算。例如：峰值 1000 QPS，平均处理 100ms → 每秒积压 100 个任务 → 队列设为 200~500 较安全。
- 拒绝策略选择
JDK 提供四种策略：
- AbortPolicy（默认） 抛出 RejectedExecutionException
- CallerRunsPolicy 由提交任务的线程（调用者）自己执行任务
- DiscardPolicy 静默丢弃任务
- DiscardOldestPolicy 丢弃队列中最老的任务，再尝试提交
生产建议：
- 对于关键任务（如支付），用 CallerRunsPolicy 让调用方感知压力，触发降级；
- 对于非关键任务（如日志上报），可用 DiscardPolicy 避免阻塞主线程。
ThreadPoolExecutor 底层体系结构
Java 的线程池体系设计精妙，层层抽象：
Executor：最顶层接口，只有一个execute(Runnable)方法，解耦任务提交与执行。ExecutorService：扩展了Executor，支持关闭、获取Future、批量提交等。ThreadPoolExecutor：标准线程池实现，支持核心/最大线程数、队列、拒绝策略等。ScheduledThreadPoolExecutor：继承自ThreadPoolExecutor，支持定时/周期任务。ForkJoinPool：专为“分治”任务设计（如 parallelStream()），采用工作窃取（Work-Stealing）算法，适合 CPU 密集型递归任务。
💡 小知识：CompletableFuture默认使用的就是ForkJoinPool.commonPool()。
血泪教训：两个真实生产事故
踩坑 1：无界队列引发 OOM 某在线系统，使用了Executors.newFixedThreadPool(10) 处理用户请求。 由于底层依赖的数据库响应变慢，任务处理时间从 10ms 涨到 1s。 而newFixedThreadPool内部使用的是无界LinkedBlockingQueue`，任务不断堆积，最终堆内存爆满，服务宕机。
根因：刚入职场缺乏并发编程经验，无界队列 + 任务积压 = 内存泄漏。
// 改为有界队列 + 自定义拒绝策略 new ThreadPoolExecutor( 10, 20, 60L, SECONDS, new ArrayBlockingQueue<>(200), r -> { /* 记录监控 + 降级 */ } );踩坑 2：异步日志的“伪异步”
某核心系统，配置了 Log4j2 的AsyncLogger（基于Disruptor RingBuffer），以为日志完全不阻塞主线程。
但在一次流量洪峰中，RingBuffer 被写满，Log4j2 默认行为是阻塞写入线程（即业务线程）！
结果：大量 HTTP 请求卡在 http://logger.info()，线程池耗尽，服务不可用。
根因：异步日志也有瓶颈，需要了解底层原理，满时默认会 backpressure（反压）到调用方。
修复：
- 设置 log4j2.asyncQueueFullPolicy=Discard，满时丢弃日志而非阻塞；
- 或增大 RingBuffer 大小（但不能根本解决问题）；
- 关键：监控日志队列深度，及时告警。
✅ 经验：任何“异步”组件都不是无限缓冲的，都要考虑背压处理！
结语
线程池是 Java 并发编程的基石，用得好能极大提升系统稳定性与性能，用不好则可能成为“定时炸弹”。记住三个黄金法则：
- 永远不要用 Executors 的默认线程池；
- 任务队列必须有界；
- 拒绝策略要根据业务场景定制。
最后送大家一句并发编程箴言：
“Don’t create threads; manage them.”
希望这篇文章能帮你避开那些年我们踩过的坑。如果你觉得有用，欢迎转发给团队小伙伴，一起写出更健壮的代码！
