✅ 核心速览：

JDK 版本	关键演进	说明
JDK 1.0~1.4	原生 Thread + Runnable	手动管理，无池化，资源易泄漏
JDK 5 (1.5)	java.util.concurrent 诞生	Executor 框架、ThreadPoolExecutor、Executors 工厂、Future/Callable
JDK 7	ForkJoinPool 引入	支持工作窃取（Work-Stealing），适配分治算法/并行流
JDK 8	Lambda & CompletableFuture	异步编程链式化，函数式风格普及
JDK 9~16	性能调优 & 模块化	CompletableFuture 增强、线程局部变量优化、GC 协同改进
JDK 17 (LTS)	稳定期 & 规范收紧	官方文档明确警告：避免使用 Executors 创建无界池/队列
JDK 19~21	Project Loom 落地	虚拟线程（Virtual Threads）、结构化并发预览、Thread.ofVirtual() API
JDK 22~25	新范式标准化	结构化并发正式毕业，虚拟线程生产级优化，传统线程池定位收窄

---

1、线程池核心架构

Java 线程池的抽象位于 java.util.concurrent 包，核心类图如下：

Executor (提交任务)
  └─ ExecutorService (生命周期管理: submit, shutdown, invokeAll 等)
        └─ AbstractExecutorService (基础实现)
              └─ ThreadPoolExecutor (核心引擎)
              └─ ScheduledThreadPoolExecutor (定时任务)
              └─ ForkJoinPool (工作窃取，JDK 7+)

设计目标：

• 复用线程，降低创建/销毁开销
• 控制并发度，防止资源耗尽
• 解耦任务提交与执行逻辑
• 提供队列缓冲与拒绝机制

---

2、ThreadPoolExecutor 的 7 大构造参数

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

2.1、任务调度流程

新任务 → 核心线程未满？ → 是 → 创建核心线程执行
        ↓否
        队列未满？ → 是 → 入队等待
        ↓否
        最大线程未满？ → 是 → 创建非核心线程执行
        ↓否
        触发拒绝策略

2.2、关键细节

• allowCoreThreadTimeOut(true)：允许核心线程超时回收
• 线程池状态机：RUNNING → SHUTDOWN → STOP → TIDYING → TERMINATED
• 线程数动态调整依据：队列是否饱和、任务是否堆积、空闲超时

3、工作队列与拒绝策略

3.1、常用阻塞队列

队列类型	特点	适用场景
ArrayBlockingQueue	有界、数组实现、公平/非公平	生产首选，防止 OOM
LinkedBlockingQueue	默认容量 Integer.MAX_VALUE	需显式指定容量，否则等同无界
SynchronousQueue	容量为0，直接传递	Executors.newCachedThreadPool 底层使用
PriorityBlockingQueue	支持优先级，无界	需配合最大线程数使用
DelayQueue	延迟执行	定时/延时任务

3.2、拒绝策略（RejectedExecutionHandler）

• AbortPolicy：默认，抛 RejectedExecutionException
• CallerRunsPolicy：调用者线程执行，天然背压（Backpressure）
• DiscardPolicy：静默丢弃
• DiscardOldestPolicy：丢弃队头最老任务
• 自定义策略：生产推荐记录日志+降级/监控告警，或动态扩容

4、最新 JDK（21/22+）重大变化

4.1、虚拟线程（Virtual Threads）

• 本质：JVM 管理的轻量级纤程，非 OS 线程，创建成本极低（~KB 内存）
• 适用：高并发 I/O 密集型（网络请求、DB 查询、文件读写）
• 使用方式：

  // JDK 21+ 推荐方式
  ExecutorService vExecutor = Executors.newVirtualThreadPerTaskExecutor();
  vExecutor.submit(() -> doIoTask());
  

• 注意：虚拟线程不是传统线程池的替代品。它们采用“每任务一个虚拟线程”模型，底层由少量平台线程（Carrier Threads）调度。CPU 密集型任务仍应使用 ThreadPoolExecutor 控制并发度。

4.2、结构化并发（Structured Concurrency）

• 定位：替代“散弹式”异步任务管理，提供确定性生命周期
• 核心 API：StructuredTaskScope

  try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
      Subtask<String> t1 = scope.fork(() -> callServiceA());
      Subtask<Integer> t2 = scope.fork(() -> callServiceB());
      scope.join();
      scope.throwIfFailed();
      return Result.of(t1.get(), t2.get());
  }
  

• 优势：自动传播异常、支持超时、天然支持取消、线程关系可视化

4.3、Executors 工厂类定位变化

Oracle 官方已明确：newFixedThreadPool、newCachedThreadPool 等不再推荐用于生产，原因：

• 无界队列 → OOM 风险
• 无界线程数 → 线程爆炸/上下文切换风暴
• 现代替代方案：显式构造 ThreadPoolExecutor 或 newVirtualThreadPerTaskExecutor()

5、最佳实践

场景	推荐方案	配置要点
CPU 密集型	ThreadPoolExecutor	core = CPU核心数，有界队列（如 2×core），AbortPolicy 或降级
I/O 密集型	虚拟线程（JDK 21+）	Executors.newVirtualThreadPerTaskExecutor()，无需调参
定时/周期任务	ScheduledThreadPoolExecutor	固定核心线程，避免 Timer 单线程缺陷
分治/并行计算	ForkJoinPool	ForkJoinPool.commonPool() 默认并行度=CPU核数-1
复杂异步编排	StructuredTaskScope + CompletableFuture	优先结构化，避免回调地狱

5.1、生产配置模板

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    Runtime.getRuntime().availableProcessors(),
    Runtime.getRuntime().availableProcessors() * 2,
    60L, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(1000),
    r -> {
        Thread t = new Thread(r);
        t.setName("biz-pool-" + t.getId());
        t.setUncaughtExceptionHandler((th, ex) -> log.error("Uncaught", ex));
        return t;
    },
    new ThreadPoolExecutor.CallerRunsPolicy()
);
executor.allowCoreThreadTimeOut(true);

5.2、常见陷阱与排查建议

1. 线程泄漏：未正确 shutdown() 或任务阻塞导致线程永久占用 → 使用 try-with-resources 或 Spring @PreDestroy
2. 队列积压：无界队列掩盖系统瓶颈 → 必须设置合理容量 + 监控队列深度
3. 上下文切换风暴：线程数 >> CPU核数 → 使用 jstack/async-profiler 分析线程状态
4. 虚拟线程阻塞陷阱：在 synchronized 或原生阻塞调用中长时间持有 → 改用 ReentrantLock 或非阻塞 API

---

一键三连，让我的信心像气球一样膨胀！