1. JUC线程池的核心价值与适用场景Java并发编程中线程池是最基础也最容易被误用的组件之一。我见过太多团队在线上环境因为线程池配置不当导致服务雪崩的案例。JUCjava.util.concurrent包提供的线程池实现本质上是一套经过工业级验证的并发控制框架它解决了两个核心问题第一是线程生命周期管理的成本问题。在Web应用中每个请求都创建新线程的话光是线程创建/销毁的开销就能吃掉30%以上的性能。线程池通过维护固定数量的工作线程让线程可以重复利用实测下来QPS至少能提升2-3倍。第二是资源分配的边界控制。去年我们有个支付系统就因为没有限制线程数在促销时创建了上万个线程直接导致OOM。通过ThreadPoolExecutor的corePoolSize、maximumPoolSize等参数可以精确控制并发水位。2. 线程池的底层工作原理拆解2.1 核心参数的血泪教训先看这个最容易被问到的面试题线程池的七个参数是什么 背概念容易但真正理解每个参数的边界条件才是关键corePoolSize核心线程数我建议设置为CPU核心数的1-2倍。但要注意在IO密集型场景下这个值可能要到100。去年我们日志服务就设了8服务器是8核结果大量线程阻塞在磁盘IO上吞吐量直接腰斩。maximumPoolSize最大线程数千万别设成Integer.MAX_VALUE我们线上曾经有个配置失误高峰期创建了5000线程整个JVM都卡死了。建议用这个公式估算线程池大小 CPU数量 * CPU期望的利用率 * (1 IO操作等待时间/CPU计算时间)比如4核服务器目标利用率70%IO等待时间是计算时间的2倍那就是40.7(12)8.4取整8。keepAliveTime非核心线程的空闲存活时间。有个坑如果allowCoreThreadTimeOut设为true连核心线程也会被回收。我们有个定时任务线程池就因为这个配置每次执行前都要重建线程。2.2 任务队列的选型陷阱队列类型直接影响线程池行为常见的有SynchronousQueue直接移交适用于瞬时高并发但去年双11我们就因为用它导致大量任务被拒绝ArrayBlockingQueue有界队列需要谨慎设置队列容量我们曾经设了1000结果堆积了800多个任务时GC开始频繁STWLinkedBlockingQueue无界队列最大坑爹之处会导致maximumPoolSize参数失效我们有个服务内存爆掉就是因为这个2.3 拒绝策略的实战选择当队列满且线程数达到maximum时会触发拒绝策略。默认的AbortPolicy会直接抛RejectedExecutionException但在电商场景下我们更常用CallerRunsPolicy让提交任务的线程自己执行。虽然会降低提交速度但能保证不会丢任务自定义策略比如把拒绝的任务存入Redis等线程池空闲时再重新提交3. 线程池的实战配置方案3.1 IO密集型服务配置以我们订单系统为例主要瓶颈在数据库和RedisThreadPoolExecutor executor new ThreadPoolExecutor( 16, // corePoolSize: 略大于CPU核数 64, // maximumPoolSize: 根据上述公式计算 30, // keepAliveTime: 适当延长 TimeUnit.SECONDS, new LinkedBlockingQueue(1000), // 需要明确设置队列大小 new CustomRejectedPolicy() // 自定义拒绝策略记录到监控系统 );关键技巧用ThreadPoolExecutor的getActiveCount()监控活跃线程数通过JMX或Micrometer暴露线程池指标重要一定要给线程池设置有意义的名称用Guava的ThreadFactoryBuilder3.2 计算密集型任务配置比如我们的风控模型计算ThreadPoolExecutor executor new ThreadPoolExecutor( Runtime.getRuntime().availableProcessors(), // 严格等于CPU核数 Runtime.getRuntime().availableProcessors(), // 不超过核数 0L, // 不需要保活 TimeUnit.MILLISECONDS, new ArrayBlockingQueue(100) // 防止内存溢出 );这里特别注意队列容量不能太大否则会占用过多内存存放待计算对象建议配合Semaphore做全局并发控制4. 线程池监控与问题排查4.1 必须监控的黄金指标活跃线程数如果长期等于maximumPoolSize说明需要扩容队列积压量我们设置过报警规则超过容量80%就触发告警任务执行耗时通过装饰Runnable实现比如public class TimedRunnable implements Runnable { private final Runnable target; public void run() { long start System.nanoTime(); target.run(); long cost (System.nanoTime() - start)/1000000; Metrics.record(threadpool.task.time, cost); } }4.2 典型问题排查案例案例1线程池卡死 现象所有线程处于RUNNING状态但无任务执行 排查用jstack发现线程都在poll队列但队列是空的 原因有人误用了SynchronousQueue却没有足够的消费者线程案例2内存泄漏 现象老年代持续增长Full GC频繁 排查发现线程池用了无界队列队列里积压了上万个Future对象 解决改用有界队列合适的拒绝策略5. 高级特性与最佳实践5.1 ForkJoinPool的特殊场景对于可以拆分的计算型任务比如大数据处理用ForkJoinPool比ThreadPoolExecutor更高效ForkJoinPool pool new ForkJoinPool(4); pool.invoke(new RecursiveTask() { protected Long compute() { // 任务拆分逻辑 } });但要注意不要用于IO操作我们踩过这个坑工作窃取work-stealing机制会导致CPU使用率忽高忽低5.2 CompletableFuture的线程池选择Java8的CompletableFuture默认使用ForkJoinPool.commonPool()这在生产环境很危险// 正确的做法是指定专属线程池 CompletableFuture.supplyAsync(() - { // 业务逻辑 }, businessExecutor);5.3 Spring中的线程池陷阱Spring的Async注解有两个大坑默认使用SimpleAsyncTaskExecutor每次新建线程同一个类内调用异步方法会失效正确姿势Configuration EnableAsync public class AsyncConfig implements AsyncConfigurer { Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); executor.setQueueCapacity(50); executor.initialize(); return executor; } }6. 线程池的演进与替代方案随着虚拟线程Project Loom的成熟传统线程池的使用场景可能会发生变化。但目前来看在以下场景线程池仍是首选需要精确控制并发度的场景已有基于线程池的遗留系统改造需要与现有监控体系集成的场景我在实际项目中总结的线程池配置检查清单[ ] 核心线程数是否根据业务类型设置CPU/IO密集型[ ] 最大线程数是否有硬性限制[ ] 队列是否设置了合理容量[ ] 是否设置了有意义的线程名称前缀[ ] 拒绝策略是否考虑业务容错[ ] 是否有对应的监控指标暴露