Java并发进阶2把单例、阻塞队列、定时器、线程池一次讲透并发编程这块光看八股文和面试题是远远不够的因为面试题告诉你的只是“结论”而工程里的坑往往藏在“为什么”里。我见过不少人能背出线程池的七大参数也能说出单例模式的双重检查锁但一到线上就出问题——要么线程池满了直接拒绝业务要么定时任务莫名其妙不执行要么单例对象半初始化还被并发线程拿到了。这篇东西我从“这几个案例在并发体系里的真正位置”讲起把单例模式、阻塞队列、定时器、线程池串成一条线。它们并不是四个孤立的考点而是同一个并发模型的几种典型场景资源竞争、线程协作、任务调度、任务复用。读完你会发现理解了它们的内在关联比死记硬背任何面试答案都管用。这篇文章适合已经接触过Java多线程、知道synchronized和volatile基本用法、但还没真正吃透并发组件协作原理的读者。如果你正在准备面试或者在工作中遇到了“线程池该怎么配”“定时任务该用Timer还是ScheduledThreadPoolExecutor”这类问题这篇内容就是给你准备的。1. 内容整体设计与思路拆解1.1 为什么把这些案例放在一起讲很多人在学并发时是“点状学习”的——今天看一个synchronized的用法明天背一下ThreadLocal的原理后天临时抱佛脚看线程池参数。这样学完的知识是零散的遇到问题时会觉得“这个场景好像用A也行、用B也行”然后就靠猜。其实这几个案例在并发体系里的关联非常紧密单例模式解决的是“多线程下如何安全地共享一个对象”核心矛盾是初始化时的竞争。阻塞队列解决的是“多线程下如何安全地传递数据”核心矛盾是生产速度和消费速度不匹配。定时器解决的是“如何在指定时间后或周期性执行任务”核心矛盾是任务的延迟触发和线程生命周期管理。线程池解决的是“如何复用线程、控制并发度”核心矛盾是线程的创建销毁成本和任务队列的平衡。而它们共享着一套底层地基volatile的内存可见性、锁的互斥与可见性、Condition的等待通知机制以及AQSAbstractQueuedSynchronizer这个并发体系的基石。把四个案例放在一起讲其实就是把地基再夯实一遍再用同一套地基解释四种不同场景。1.2 从面试角度和工程角度分别看这套组合从面试角度来说这四个案例几乎是Java并发领域的“必考题”。面试官问单例模式是在考察你对synchronized和volatile的理解深度问阻塞队列是在考察你对生产者-消费者模型是否真的掌握问定时器是在考察你对ScheduledExecutorService和DelayQueue的理解问线程池是在考察你对任务调度、拒绝策略、参数调优的系统性认知。从工程角度来说这四个案例全是实际项目里每天都在用的东西Spring里的bean默认就是单例线程安全问题藏在每个Component里。消息队列削峰、异步处理、数据库连接池的任务分发底层全是阻塞队列的思想。定时任务、延迟任务、分布式锁的自动续期都离不开定时调度器。全公司的所有Java服务几乎没有一个不用线程池的但线程池配得对不对就是另一回事了。所以我在这篇文章里的思路是先用单例模式把“共享对象的线程安全”这件事掰开揉碎再用阻塞队列把“线程间的数据协作”拆解清楚然后通过定时器把“延迟任务的调度机制”串进来最后用线程池把前面所有组件收拢成一个综合场景。2. 核心细节解析与实操要点2.1 单例模式双重检查锁的volatile到底保护了什么单例模式最常见的写法是懒汉式的双重检查锁Double-Checked Locking简称DCL代码长这样public class Singleton { private static volatile Singleton instance; private Singleton() { } public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } }很多人能写出这段代码但被问到“为什么要加volatile”时就开始含糊了。我来把这里面的原理说透。instance new Singleton()这行代码在JVM层面并不是原子操作它实际上会被拆成三步在堆上分配一块内存给Singleton对象分配空间。调用构造方法初始化这个对象把字段赋值都执行完。把instance引用指向这块内存。问题在于JVM在运行时可能做指令重排。如果CPU或者编译器把第2步和第3步调换顺序那么就会先让instance指向一块未完成初始化的内存然后再执行构造方法。在没有volatile修饰的情况下线程A执行到第3步时instance已经不是null了。此时线程B进入getInstance()看到了instance ! null于是直接就return instance了但拿到的这个对象可能还没有执行完构造方法里面的字段可能还是默认值比如int是0Object是null。这就是著名的“半初始化对象”问题。volatile在这里干了两件事一是禁止了instance写入之前的指令重排保证第2步一定在第3步之前完成二是保证线程B读取instance时能看到线程A写入后的最新值因为volatile变量读写都会直接走主内存并加上内存屏障。关于第一点为什么要重点强调——synchronized其实已经保证了“锁内代码块”在同一个线程内的顺序性但JIT编译器在锁退出后可能对锁外的代码做优化而双重检查锁的volatile包裹的正是“对象引用”本身它约束的是“发布引用”这个动作的可见性。这是很多资料讲得模糊的地方。注意如果你使用的是静态内部类的方式就不需要额外加volatile了。因为静态内部类由JVM的类加载机制保证线程安全初始化时ClassLoader有锁保护。但DCL这种“延迟初始化 手动锁”的方案里volatile是必须的不是可选项。我还想多说一句在面试时如果被问到单例不要只说写法要从“为什么要这样写”的角度来讲。DCL的考点从来不是代码本身而是你对JMM、指令重排、对象发布这三个概念的理解。2.2 阻塞队列不只是“放进去拿出来”阻塞队列的核心特点是当队列满时生产者线程会被阻塞直到队列有空位当队列空时消费者线程会被阻塞直到队列里有新元素。这个特性解决了线程间最经典的协作问题生产速度和消费速度不一致怎么办。Java里的BlockingQueue接口提供了几组核心操作每组操作在队列满或空时表现不同操作抛出异常返回特殊值一直阻塞超时退出插入add(e)offer(e)put(e)offer(e, time, unit)移除remove()poll()take()poll(time, unit)检查element()peek()不支持不支持这四组操作背后的语义很清晰面试官很喜欢让人说清楚这些区别其实就是在考察是否真的用过、知道每种方法的适用场景。常见的阻塞队列实现里我挑几个最常用的讲ArrayBlockingQueue基于数组实现的有界队列创建时必须指定容量。它内部的锁是单一锁也就是说生产者和消费者用的是同一把锁。这意味着同一时刻只能有一个线程在操作队列的头部或尾部并发度上有所限制但实现简单、数据结构紧凑。LinkedBlockingQueue基于链表实现的有界队列默认容量是Integer.MAX_VALUE也就是说不传容量的话等于无界。它内部用了两把锁一把是putLock一把是takeLock生产者和消费者可以同时操作队列的不同端吞吐量比ArrayBlockingQueue更好。这也是Executors.newFixedThreadPool()默认使用的队列。SynchronousQueue这个队列比较特殊它内部没有任何容量。它的put必须等一个take出现才能成功反过来一样。它存在的意义是“直接交付”——生产者直接把任务交给消费者线程中间不经过任何缓冲。Executors.newCachedThreadPool()用的就是它。DelayQueue无序存储、按延迟时间排序的无界队列。元素必须实现Delayed接口getDelay()返回剩余延迟时间队头的元素一定是“最早到期”的那一个。ScheduledThreadPoolExecutor内部的定时任务调度队列就是DelayedWorkQueue它本质上就是DelayQueue的一种变体。那么阻塞是怎么实现的其实底层就是ReentrantLock配合Condition。以ArrayBlockingQueue为例内部维护了两个ConditionnotEmpty和notFull。当队列满时put操作的线程调用notFull.await()挂起自己当消费者拿走一个元素后会调用notFull.signal()唤醒一个等待的生产者。反过来当队列空时take操作的线程调用notEmpty.await()生产者放入元素后调用notEmpty.signal()。这个“等待-通知”机制就是阻塞队列的灵魂。理解了它你就理解了为什么阻塞队列天然就是线程安全的所有操作都在锁的保护之下而锁内部的Condition负责协调线程的睡眠与唤醒。2.3 定时器延时任务和无界队列的隐藏配合Java里做定时任务最古老的方案是Timer类但它有几个很严重的毛病Timer底层是单线程的一个任务执行时间过长会延迟后面所有任务的执行。Timer的任务如果抛出未捕获的异常整个线程会终止所有已调度的任务全部取消。Timer没有对任务执行频率做任何保护执行慢的任务可能导致任务堆积。所以现在几乎不建议用Timer了而是使用ScheduledThreadPoolExecutor。它继承自ThreadPoolExecutor因此本质上就是一个带有“延迟调度能力”的线程池。它内部的延迟队列是DelayedWorkQueue这个队列的典型特点就是“队列里的任务不是按照加入顺序排列的而是按照下一次执行时间排序的最先到期的任务排在队头”。当我们在ScheduledThreadPoolExecutor里提交一个定时任务时它会被封装成一个ScheduledFutureTask放进DelayedWorkQueue里。工作线程从队列里取任务时会调用take()方法这个方法会先去执行getDelay()判断队头任务是否到期如果没到期线程就阻塞等待指定的延迟时间。这就是定时任务能“到点执行”的根本原理。写一段简单示例ScheduledExecutorService scheduler Executors.newScheduledThreadPool(2); scheduler.schedule(() - System.out.println(延迟3秒执行), 3, TimeUnit.SECONDS); scheduler.scheduleAtFixedRate(() - { System.out.println(每隔2秒执行一次); }, 0, 2, TimeUnit.SECONDS);注意scheduleAtFixedRate和scheduleWithFixedDelay的区别。前者是“固定频率”也就是每次执行之间的时间间隔是基于起始时间的后者是“固定延迟”也就是每次执行之后间隔固定时间再执行下一次。如果我有一个任务需要耗时3秒而调度频率是2秒用scheduleAtFixedRate的话任务的执行间隔可能变成3秒、4秒甚至更久因为它不会挤掉正在执行的任务而是等当前任务执行完再触发下一次。这个细节线上很容易踩坑尤其是做心跳上报或者缓存刷新时如果不理解这两者的区别可能你以为每2秒刷一次实际是每5秒、6秒才刷一次。个人经验在做定时任务时尽量给ScheduledThreadPoolExecutor设置一个合理的核心线程数不要用单线程的Executors.newSingleThreadScheduledExecutor()。因为如果其中一个定时任务因为某种原因卡住了比如等一个永远不会来的锁其他定时任务也会一起遭殃。用多线程可以隔离部分风险但要注意同一批任务之间不要再互相等待否则还是会死锁。2.4 线程池参数背后的真实意义线程池的核心构造方法长这样public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueueRunnable workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)这七个参数每个都不难理解但它们的协作关系才是重点。我用自己的话给这套逻辑做个“翻译”当新任务进来时如果当前运行的线程数小于corePoolSize即使有空闲线程也会新建线程来执行这个任务。线程池“优先加人不排队”。如果当前运行的线程数大于等于corePoolSize新任务会放到workQueue里排队等待。如果队列也满了线程池才会考虑继续增加线程数直到达到maximumPoolSize。如果线程数已经达到maximumPoolSize队列也满了再来新任务就触发拒绝策略。在corePoolSize以上的线程如果空闲了keepAliveTime时间会被回收掉控制资源使用。很多人背过这套逻辑但实际配置时还是会乱。我来给几个真实的配置建议IO密集型任务比如大量HTTP调用、数据库查询、文件读写这类任务大多数时间在等待IO线程本身并没有满负荷工作。所以核心线程数可以设大一些常见的经验公式是CPU核数 * 2或者更高。CPU密集型任务比如复杂计算、加解密、图像处理这类任务几乎占满了CPU时间片核心线程数设置太多反而会频繁切换上下文降低效率。一般设置为CPU核数 1是常用的选择。混合型任务如果既有计算又有IO建议拆分成两个不同的线程池分别处理不要让一个池子同时承担两种负载不然当计算任务占满线程时IO任务的响应速度会明显下降。在队列选择方面我个人的建议是如果任务数量波动不大用有界队列比如ArrayBlockingQueue容量根据峰值流量预估。如果需要尽可能不拒绝任务但允许一定延迟可以用无界队列比如LinkedBlockingQueue不指定容量。但无界队列意味着maximumPoolSize形同虚设线程数永远不会超过corePoolSize这一点非常重要——有些人配置了maximumPoolSize但队列是无界的结果发现线程数一直上不去就是这个原因。如果希望任务能被消费者“直接处理”不经过缓存用SynchronousQueue这是newCachedThreadPool的默认配置。这就是为什么不建议直接使用Executors提供的静态工厂方法因为newFixedThreadPool和newSingleThreadExecutor用的都是无界队列任务一多会堆积在内存里OOM风险很高。而newCachedThreadPool用的SynchronousQueue要求有消费者立刻接单否则会不断创建线程直到OOM。最安全的做法是自己newThreadPoolExecutor并指定有界队列和拒绝策略。3. 实操过程与核心环节实现3.1 手写一个简化版阻塞队列彻底搞懂Condition光看不练是不够的我建议你自己动手写一个简化版的阻塞队列。当你亲手用ReentrantLock和Condition实现一次put和take之后你对阻塞队列的理解会完全不一样。public class SimpleBlockingQueueT { private final Object[] items; private int takeIndex; private int putIndex; private int count; private final ReentrantLock lock new ReentrantLock(); private final Condition notEmpty lock.newCondition(); private final Condition notFull lock.newCondition(); public SimpleBlockingQueue(int capacity) { if (capacity 0) { throw new IllegalArgumentException(capacity must 0); } items new Object[capacity]; } public void put(T e) throws InterruptedException { lock.lockInterruptibly(); try { while (count items.length) { notFull.await(); } items[putIndex] e; if (putIndex items.length) { putIndex 0; } count; notEmpty.signal(); } finally { lock.unlock(); } } SuppressWarnings(unchecked) public T take() throws InterruptedException { lock.lockInterruptibly(); try { while (count 0) { notEmpty.await(); } T e (T) items[takeIndex]; items[takeIndex] null; if (takeIndex items.length) { takeIndex 0; } count--; notFull.signal(); return e; } finally { lock.unlock(); } } }这里有几个细节值得注意第一个是while而不是if包裹await()。这里面有讲究——Condition.await()在唤醒之后并不会重新检查条件如果在等待期间有其他线程抢占了队列空间唤醒后直接往下走可能又遇到队列空或满的情况。用while是为了在每次唤醒后重新检查条件保证安全性。这是写阻塞代码的一个通用经验不光是这个例子任何使用Condition.await()的地方都建议用while循环包裹。第二个是循环数组的处理。putIndex和takeIndex走到末尾时都要归零这样才能复用数组空间。ArrayBlockingQueue底层用的就是这个套路只是实现得更精细。第三个是lockInterruptibly()和lock()的区别。lockInterruptibly允许线程在等待锁的过程中响应中断这一点在阻塞队列这种场景下很重要——如果线程持锁等待时被中断它可以立即退出而不是一直等到拿到锁后才去判断中断状态。3.2 手写一个线程池把核心参数变成看得见的逻辑理解了阻塞队列之后我建议再实现一个简化的线程池。这个过程能把线程池的所有参数含义具象化。public class SimpleThreadPool { private final BlockingQueueRunnable workQueue; private final int corePoolSize; private final int maximumPoolSize; private final ListWorker workers new ArrayList(); public SimpleThreadPool(int corePoolSize, int maximumPoolSize, int queueCapacity) { this.corePoolSize corePoolSize; this.maximumPoolSize maximumPoolSize; this.workQueue new ArrayBlockingQueue(queueCapacity); } public void execute(Runnable task) { synchronized (workers) { if (workers.size() corePoolSize) { addWorker(task); return; } } boolean offered workQueue.offer(task); if (!offered) { synchronized (workers) { if (workers.size() maximumPoolSize) { addWorker(task); return; } } // 拒绝策略 throw new RejectedExecutionException(queue full and worker pool exhausted); } } private void addWorker(Runnable firstTask) { Worker worker new Worker(firstTask); workers.add(worker); Thread thread new Thread(worker); thread.start(); } private final class Worker implements Runnable { private Runnable firstTask; Worker(Runnable firstTask) { this.firstTask firstTask; } Override public void run() { Runnable task firstTask; firstTask null; while (task ! null || (task workQueue.poll()) ! null) { try { task.run(); } finally { task null; } } } } }这段代码的真实含义是一个Worker线程不止执行一个任务它执行完firstTask之后还会继续从队列里拿下一个任务。这就是“线程复用”的本质——线程本身没有被销毁只是变成了一个循环执行的体力工人任务是一个接一个喂给它的。实际ThreadPoolExecutor的实现复杂度比这个高得多但它核心的机制就是这样的Worker线程是一个Runnable它内部有一个while循环不断从workQueue里取任务。设置keepAliveTime和allowCoreThreadTimeOut之后如果线程在规定时间内没拿到新任务就退出循环线程自然结束。这里我也要提醒一点在上述简化例子中如果队列里的任务永远取不完这些Worker线程就会一直存活这是线程池为什么能减少线程创建销毁开销的原因但也意味着如果你不彻底关闭线程池这块内存和线程资源就不会释放。所以在应用关闭或动态调整线程池时一定要调用shutdown()或shutdownNow()。3.3 定时器 线程池组合应用延迟重试的优雅实现在用定时器做业务开发时有一个很经典的场景是“延迟重试”。比如调用第三方接口失败后希望能过5秒钟再重试一次如果在重试过程中又失败就再过10秒重试。用ScheduledThreadPoolExecutor可以很优雅地实现这种需求。ScheduledExecutorService retryExecutor Executors.newScheduledThreadPool(2); public void retryTask(Runnable task, int retryCount) { scheduleRetry(task, retryCount, 5, TimeUnit.SECONDS); } private void scheduleRetry(Runnable task, int retryCount, int delay, TimeUnit unit) { retryExecutor.schedule(() - { try { task.run(); System.out.println(任务执行成功); } catch (Exception e) { if (retryCount 0) { scheduleRetry(task, retryCount - 1, delay * 2, unit); } else { System.out.println(重试次数耗尽任务失败); } } }, delay, unit); }这段代码的关键点在于“递归地提交定时任务”。每次失败后重新提交一个延迟更长的任务到调度器而不是在同步代码里Thread.sleep()等待。这样做的好处有两个一是不会占用工作线程。如果用Thread.sleep()当前线程会被白白占住什么事都不干而用schedule提交任务后线程可以继续处理其他任务到了延迟时间再回来执行。二是每个重试任务之间是独立的。即使前一次任务抛出异常也不会影响后面已经排队的任务因为它们本质上是独立提交给线程池的。这个模式在实际项目里非常常见比如订单超时检查、支付结果主动查询、消息补偿机制底层大多都是“延迟任务 重试策略”的组合。4. 常见问题与排查技巧实录4.1 线程池提交顺序为什么任务不先排队而是先创建线程很多人对线程池的“任务添加顺序”有误解以为新任务到了以后应该先让已有的线程处理实在忙不过来了再新建线程。但实际逻辑恰恰相反**当运行线程数小于corePoolSize时新任务会直接新建线程来执行而不是让已有线程去队列里取任务。**这个设计初看不够“节省”但仔细想想是有道理的——新建线程只发生在池子还很“空”的阶段此时优先响应新任务能降低任务延迟而且在这个阶段不可能有大量闲置线程存在新建线程的代价是可控的。到了corePoolSize以上任务才开始走队列。这意味着如果线程池核心线程数是10你连续提交了50个任务前10个会直接分配线程执行后面40个进入队列排队。而如果队列满之后继续提交任务线程数才会继续增加到maximumPoolSize。这个逻辑在排查问题时会经常用到。比如你发现某个线程池的线程数一直稳定在corePoolSize、但任务积压很严重那要么是队列太大导致任务堆积要么是每个任务执行时间太长。相反如果线程数经常冲到maximumPoolSize说明队列已经顶不住压力了需要扩容或者优化任务执行速度。4.2 线程池的队列应该怎么选无界队列的风险在Executors的静态方法中newFixedThreadPool和newSingleThreadExecutor采用的都是无界队列LinkedBlockingQueue。这意味着当提交任务的速度长期大于消费速度时队列会无限增长最终导致内存被耗尽、系统OOM。不要觉得OOM离自己很远。我在实际项目中就遇到过这种情况一个数据同步任务由于下游接口突然变慢每个任务执行时间从200毫秒变成5秒而生产端还在源源不断地往线程池里提交任务队列里积压了几百万个任务每个任务还持有一批对象JVM堆直接被占满整个服务都挂了。所以凡是涉及线程池配置我的建议统一是**优先选择有界队列给队列一个明确的容量上限并配置好拒绝策略。**拒绝策略也不是越激进越好AbortPolicy默认直接抛出RejectedExecutionException适合对任务丢失零容忍的场景。CallerRunsPolicy任务不会被丢弃而是由提交任务的线程自己执行。好处是天然的“背压机制”——生产速度会被迫降下来坏处是执行的线程可能不是业务期望的线程而且如果提交任务的是主线程主线程会被阻塞。DiscardPolicy静默丢弃不报错。适合能容忍偶尔丢消息的场景但生产环境不建议直接使用容易留下隐患。DiscardOldestPolicy把队列头最老的任务丢掉再重试提交当前任务。适合追求任务时效性的场景比如做实时统计时旧数据丢弃影响不大。最稳妥的组合是用有界队列 CallerRunsPolicy这样既不会丢任务也不会让系统直接崩溃代价是提交端的线程会被占用从而自然限流。4.3 定时任务不执行或不准时排查思路定时任务不执行最常见的几种情况第一种是线程池里的线程数不够而某个任务执行时间过长占了所有线程。如果是newSingleThreadScheduledExecutor()那就只有一个线程一个阻塞的任务就会拖垮所有定时任务。解决办法是改用多线程调度器并且排查为什么任务会卡住。第二种是任务抛出了异常。注意ScheduledThreadPoolExecutor中如果任务执行抛出异常这个异常会被吞掉吗实际上在任务执行过程中抛出异常会中断当前任务的后续执行而且异常会被封装到Future里如果你使用schedule()返回的ScheduledFuture而不调用get()异常可能很难发现。因此我的建议是所有定时任务的方法体里都要自己try-catch至少打一条日志。千万不要让异常冒出去。第三种是时间不准。ScheduledThreadPoolExecutor的定时精度依赖系统时钟如果服务器时间被手动调整定时任务可能提前或延后触发。这在生产环境很少见但如果你的部署环境有NTP时间校准理论上有时间跳动导致误触发的风险可以在任务里增加逻辑二次校验。4.4 单例模式导致死循环或栈溢出单例模式在Spring容器里特别常见但有一个隐患是构造方法里如果调用了其他Bean的方法而这些Bean又反过来依赖当前Bean就会形成循环依赖。Spring的循环依赖在单例模式下有三级缓存机制能解决但在某些情况下比如构造函数注入会直接报BeanCurrentlyInCreationException。用双重检查锁手写单例时还有一个隐蔽的问题如果你的单例类里维护了可变状态比如一个共享的Map、一个计数器、一个缓存列表即使单例对象的创建是线程安全的对这些可变字段的读写也必须加锁或使用并发容器。很多线上bug就是这么来的单例创建的线程安全保证了但共享数据本身的线程安全没保证两码事。4.5 排查工具怎么确认线程池状态和任务积压线上排查线程池问题时我常用的思路是把ThreadPoolExecutor的核心指标暴露到监控系统里。比如getPoolSize()当前线程数看是否到达maximumPoolSize。getActiveCount()活跃线程数看有多少线程在干活。getQueue().size()队列积压数量这是最直观的压力指标。getTaskCount()/getCompletedTaskCount()累计任务数和已完成数用来计算吞吐量和平均执行耗时。配合jstack命令还能直接看到线程栈里的线程名、状态和正在执行的任务。如果一个Worker线程长期处于RUNNABLE状态而总是不结束多半是有个任务卡住了。如果线程一直处于WAITING状态可能是队列空线程在take()那里等任务。这些信息结合起来可以快速定位线程池的大部分问题。如果是在JDK 8之后还可以使用ThreadPoolExecutor的submit()方法配Future来获取任务执行结果配合Future.get(timeout)来做超时控制防止某个任务把线程池拖垮。但要注意Future.get()超时后只是当前线程不再等待任务本身还会继续执行。换句话说超时取消并不会中断任务除非你在超时处理逻辑里主动去cancel(true)而cancel(true)是否能真正中断任务又取决于任务是否响应了中断标志。5. 几个容易忽略的并发细节5.1 线程工厂线程名不设置排查问题难上天很多人用线程池时不设置ThreadFactory导致线程池里生成的线程名字千篇一律比如pool-1-thread-1。一旦线上出现线程占用过高、死锁等问题你拿jstack一看满屏都是pool-1-thread-*根本分不清是哪个业务模块的线程。我在实际项目中吃过这个亏后来养成了一个习惯所有线程池必须自定义ThreadFactory把线程名设置为有业务语义的格式比如order-sync-worker-1、mq-consumer-1。这样排查问题时看到线程名就能立刻知道是哪个业务链路出了问题。ThreadFactory threadFactory new ThreadFactory() { private final AtomicInteger counter new AtomicInteger(1); Override public Thread newThread(Runnable r) { Thread thread new Thread(r); thread.setName(order-sync-worker- counter.getAndIncrement()); thread.setDaemon(false); return thread; } };在Java 8之后还有更简洁的写法比如new ThreadFactoryBuilder()Guava或者直接用Thread.ofPlatform()配合name()方法Java 21。但核心思路是一致的线程名要有辨识度不能图省事。5.2 线程池参数动态调整不用重启也能改ThreadPoolExecutor提供了几个动态调整参数的方法setCorePoolSize()修改核心线程数。如果新值小于当前线程数多余的线程会在空闲后回收如果新值大于当前线程数线程池会在后续任务到来时直接新建线程补齐。setMaximumPoolSize()修改最大线程数。setKeepAliveTime()修改空闲线程存活时间。这些方法在运行期是安全的可以用来做动态扩缩容。比如在业务流量高峰前把核心线程数调大流量回落后再调回正常值。很多中间件比如Dubbo、Sentinel的线程池动态调整就是基于这个能力实现的。不过要注意setCorePoolSize()在向下调整时并不会立刻销毁线程它只是允许空闲线程被回收。如果线程正处于执行任务中会等任务执行完并空闲一段时间后才退出。因此调整后并不是马上见效预留足够的“冷却时间”。5.3 线程池优雅关闭别用shutdownNow()一把梭应用关闭时如果线程池里还有正在执行的任务直接调用shutdownNow()会向所有工作线程发送中断信号强制终止任务执行。如果一个任务正在写数据库、发消息被中断可能造成数据不一致或者重复执行。更稳妥的做法是分两步先调用shutdown()让线程池停止接收新任务同时让已经提交的任务继续执行完然后再根据业务情况设置一个等待时间超时后再调用shutdownNow()兜底。executor.shutdown(); if (!executor.awaitTermination(30, TimeUnit.SECONDS)) { executor.shutdownNow(); }这段代码是标准的优雅关闭模板。第一行关闭入口第二行给30秒的“宽限期”让现有任务跑完。如果30秒后还有任务没结束说明任务执行时间不可控或存在死锁这时候再强制中断。这个策略在微服务应用优雅下线时特别重要否则你正在处理的请求可能在服务停止的瞬间被硬切造成用户侧看到大量超时或错误。5.4 线程池与ThreadLocal子线程拿不到父线程的值在使用线程池时如果一个任务里用到了ThreadLocal你需要特别注意线程池里的线程是复用的ThreadLocal的值在任务之间会相互污染。同一个线程执行任务A时往ThreadLocal里存了值如果它没有被清理执行任务B时会仍然看到任务A的数据。这在做租户隔离、链路追踪时是致命的bug。解决办法有两个一是每次任务执行完成后在finally块里调用ThreadLocal.remove()。但这样要求每个业务代码都记得清理容易漏。二是使用TransmittableThreadLocal阿里开源的TTL它能在线程池场景下传递线程上下文并在任务执行完毕后自动清理。这是目前公认的“线程池 ThreadLocal”的最佳实践方案。如果你们项目里已经引入了阿里巴巴的规范插件大概率也会建议你避免在Runnable里直接使用ThreadLocal至少要在任务入口和出口手动清理。这个坑我踩过不止一次写出来给大家提个醒。6. 写在最后的实战心得在写这篇文章的过程中我又把JDK里ThreadPoolExecutor的源码翻了一遍每次翻都有新的理解。最大的体会是并发编程不是“记住多少锁的名字、背过多少参数”就能解决的真正决定水平的是你能不能在一个具体的业务场景里把共享对象的可见性、互斥性、等待通知机制、任务调度策略这些基础概念组合起来设计出一套可靠又高效的方案。单例模式教会我“发布共享对象要小心指令重排”阻塞队列教会我“生产消费之间的节奏不匹配要用缓冲来缓解”定时器教会我“延迟调度要考虑到线程的生命周期”线程池教会我“资源复用是有上限的超限就要有兜底策略”。这四个案例串起来其实就是一套完整的并发思维模型。如果你刚学完多线程基础建议按这篇文章的顺序把每个案例自己动手敲一遍再想想“如果不这样做会怎样”。比如把双重检查锁里的volatile去掉写个循环去创建单例对象观察不同线程拿到的对象状态比如用手写的阻塞队列做一次生产者-消费者再把队列容量改成1试试看会发生什么。这些实验比背十道八股文有意义得多。最后分享一个小技巧在实际项目里给线程池命名时我习惯把业务模块名和线程类型都加进去比如order-query-pool、pay-timeout-check-pool。因为线上问题排查时能一眼从线程名定位到出问题的模块能省下大量时间。这个习惯我保持了很多年强烈推荐你也养成。
Java并发进阶2把单例、阻塞队列、定时器、线程池一次讲透并发编程这块光看八股文和面试题是远远不够的因为面试题告诉你的只是“结论”而工程里的坑往往藏在“为什么”里。我见过不少人能背出线程池的七大参数也能说出单例模式的双重检查锁但一到线上就出问题——要么线程池满了直接拒绝业务要么定时任务莫名其妙不执行要么单例对象半初始化还被并发线程拿到了。这篇东西我从“这几个案例在并发体系里的真正位置”讲起把单例模式、阻塞队列、定时器、线程池串成一条线。它们并不是四个孤立的考点而是同一个并发模型的几种典型场景资源竞争、线程协作、任务调度、任务复用。读完你会发现理解了它们的内在关联比死记硬背任何面试答案都管用。这篇文章适合已经接触过Java多线程、知道synchronized和volatile基本用法、但还没真正吃透并发组件协作原理的读者。如果你正在准备面试或者在工作中遇到了“线程池该怎么配”“定时任务该用Timer还是ScheduledThreadPoolExecutor”这类问题这篇内容就是给你准备的。1. 内容整体设计与思路拆解1.1 为什么把这些案例放在一起讲很多人在学并发时是“点状学习”的——今天看一个synchronized的用法明天背一下ThreadLocal的原理后天临时抱佛脚看线程池参数。这样学完的知识是零散的遇到问题时会觉得“这个场景好像用A也行、用B也行”然后就靠猜。其实这几个案例在并发体系里的关联非常紧密单例模式解决的是“多线程下如何安全地共享一个对象”核心矛盾是初始化时的竞争。阻塞队列解决的是“多线程下如何安全地传递数据”核心矛盾是生产速度和消费速度不匹配。定时器解决的是“如何在指定时间后或周期性执行任务”核心矛盾是任务的延迟触发和线程生命周期管理。线程池解决的是“如何复用线程、控制并发度”核心矛盾是线程的创建销毁成本和任务队列的平衡。而它们共享着一套底层地基volatile的内存可见性、锁的互斥与可见性、Condition的等待通知机制以及AQSAbstractQueuedSynchronizer这个并发体系的基石。把四个案例放在一起讲其实就是把地基再夯实一遍再用同一套地基解释四种不同场景。1.2 从面试角度和工程角度分别看这套组合从面试角度来说这四个案例几乎是Java并发领域的“必考题”。面试官问单例模式是在考察你对synchronized和volatile的理解深度问阻塞队列是在考察你对生产者-消费者模型是否真的掌握问定时器是在考察你对ScheduledExecutorService和DelayQueue的理解问线程池是在考察你对任务调度、拒绝策略、参数调优的系统性认知。从工程角度来说这四个案例全是实际项目里每天都在用的东西Spring里的bean默认就是单例线程安全问题藏在每个Component里。消息队列削峰、异步处理、数据库连接池的任务分发底层全是阻塞队列的思想。定时任务、延迟任务、分布式锁的自动续期都离不开定时调度器。全公司的所有Java服务几乎没有一个不用线程池的但线程池配得对不对就是另一回事了。所以我在这篇文章里的思路是先用单例模式把“共享对象的线程安全”这件事掰开揉碎再用阻塞队列把“线程间的数据协作”拆解清楚然后通过定时器把“延迟任务的调度机制”串进来最后用线程池把前面所有组件收拢成一个综合场景。2. 核心细节解析与实操要点2.1 单例模式双重检查锁的volatile到底保护了什么单例模式最常见的写法是懒汉式的双重检查锁Double-Checked Locking简称DCL代码长这样public class Singleton { private static volatile Singleton instance; private Singleton() { } public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } }很多人能写出这段代码但被问到“为什么要加volatile”时就开始含糊了。我来把这里面的原理说透。instance new Singleton()这行代码在JVM层面并不是原子操作它实际上会被拆成三步在堆上分配一块内存给Singleton对象分配空间。调用构造方法初始化这个对象把字段赋值都执行完。把instance引用指向这块内存。问题在于JVM在运行时可能做指令重排。如果CPU或者编译器把第2步和第3步调换顺序那么就会先让instance指向一块未完成初始化的内存然后再执行构造方法。在没有volatile修饰的情况下线程A执行到第3步时instance已经不是null了。此时线程B进入getInstance()看到了instance ! null于是直接就return instance了但拿到的这个对象可能还没有执行完构造方法里面的字段可能还是默认值比如int是0Object是null。这就是著名的“半初始化对象”问题。volatile在这里干了两件事一是禁止了instance写入之前的指令重排保证第2步一定在第3步之前完成二是保证线程B读取instance时能看到线程A写入后的最新值因为volatile变量读写都会直接走主内存并加上内存屏障。关于第一点为什么要重点强调——synchronized其实已经保证了“锁内代码块”在同一个线程内的顺序性但JIT编译器在锁退出后可能对锁外的代码做优化而双重检查锁的volatile包裹的正是“对象引用”本身它约束的是“发布引用”这个动作的可见性。这是很多资料讲得模糊的地方。注意如果你使用的是静态内部类的方式就不需要额外加volatile了。因为静态内部类由JVM的类加载机制保证线程安全初始化时ClassLoader有锁保护。但DCL这种“延迟初始化 手动锁”的方案里volatile是必须的不是可选项。我还想多说一句在面试时如果被问到单例不要只说写法要从“为什么要这样写”的角度来讲。DCL的考点从来不是代码本身而是你对JMM、指令重排、对象发布这三个概念的理解。2.2 阻塞队列不只是“放进去拿出来”阻塞队列的核心特点是当队列满时生产者线程会被阻塞直到队列有空位当队列空时消费者线程会被阻塞直到队列里有新元素。这个特性解决了线程间最经典的协作问题生产速度和消费速度不一致怎么办。Java里的BlockingQueue接口提供了几组核心操作每组操作在队列满或空时表现不同操作抛出异常返回特殊值一直阻塞超时退出插入add(e)offer(e)put(e)offer(e, time, unit)移除remove()poll()take()poll(time, unit)检查element()peek()不支持不支持这四组操作背后的语义很清晰面试官很喜欢让人说清楚这些区别其实就是在考察是否真的用过、知道每种方法的适用场景。常见的阻塞队列实现里我挑几个最常用的讲ArrayBlockingQueue基于数组实现的有界队列创建时必须指定容量。它内部的锁是单一锁也就是说生产者和消费者用的是同一把锁。这意味着同一时刻只能有一个线程在操作队列的头部或尾部并发度上有所限制但实现简单、数据结构紧凑。LinkedBlockingQueue基于链表实现的有界队列默认容量是Integer.MAX_VALUE也就是说不传容量的话等于无界。它内部用了两把锁一把是putLock一把是takeLock生产者和消费者可以同时操作队列的不同端吞吐量比ArrayBlockingQueue更好。这也是Executors.newFixedThreadPool()默认使用的队列。SynchronousQueue这个队列比较特殊它内部没有任何容量。它的put必须等一个take出现才能成功反过来一样。它存在的意义是“直接交付”——生产者直接把任务交给消费者线程中间不经过任何缓冲。Executors.newCachedThreadPool()用的就是它。DelayQueue无序存储、按延迟时间排序的无界队列。元素必须实现Delayed接口getDelay()返回剩余延迟时间队头的元素一定是“最早到期”的那一个。ScheduledThreadPoolExecutor内部的定时任务调度队列就是DelayedWorkQueue它本质上就是DelayQueue的一种变体。那么阻塞是怎么实现的其实底层就是ReentrantLock配合Condition。以ArrayBlockingQueue为例内部维护了两个ConditionnotEmpty和notFull。当队列满时put操作的线程调用notFull.await()挂起自己当消费者拿走一个元素后会调用notFull.signal()唤醒一个等待的生产者。反过来当队列空时take操作的线程调用notEmpty.await()生产者放入元素后调用notEmpty.signal()。这个“等待-通知”机制就是阻塞队列的灵魂。理解了它你就理解了为什么阻塞队列天然就是线程安全的所有操作都在锁的保护之下而锁内部的Condition负责协调线程的睡眠与唤醒。2.3 定时器延时任务和无界队列的隐藏配合Java里做定时任务最古老的方案是Timer类但它有几个很严重的毛病Timer底层是单线程的一个任务执行时间过长会延迟后面所有任务的执行。Timer的任务如果抛出未捕获的异常整个线程会终止所有已调度的任务全部取消。Timer没有对任务执行频率做任何保护执行慢的任务可能导致任务堆积。所以现在几乎不建议用Timer了而是使用ScheduledThreadPoolExecutor。它继承自ThreadPoolExecutor因此本质上就是一个带有“延迟调度能力”的线程池。它内部的延迟队列是DelayedWorkQueue这个队列的典型特点就是“队列里的任务不是按照加入顺序排列的而是按照下一次执行时间排序的最先到期的任务排在队头”。当我们在ScheduledThreadPoolExecutor里提交一个定时任务时它会被封装成一个ScheduledFutureTask放进DelayedWorkQueue里。工作线程从队列里取任务时会调用take()方法这个方法会先去执行getDelay()判断队头任务是否到期如果没到期线程就阻塞等待指定的延迟时间。这就是定时任务能“到点执行”的根本原理。写一段简单示例ScheduledExecutorService scheduler Executors.newScheduledThreadPool(2); scheduler.schedule(() - System.out.println(延迟3秒执行), 3, TimeUnit.SECONDS); scheduler.scheduleAtFixedRate(() - { System.out.println(每隔2秒执行一次); }, 0, 2, TimeUnit.SECONDS);注意scheduleAtFixedRate和scheduleWithFixedDelay的区别。前者是“固定频率”也就是每次执行之间的时间间隔是基于起始时间的后者是“固定延迟”也就是每次执行之后间隔固定时间再执行下一次。如果我有一个任务需要耗时3秒而调度频率是2秒用scheduleAtFixedRate的话任务的执行间隔可能变成3秒、4秒甚至更久因为它不会挤掉正在执行的任务而是等当前任务执行完再触发下一次。这个细节线上很容易踩坑尤其是做心跳上报或者缓存刷新时如果不理解这两者的区别可能你以为每2秒刷一次实际是每5秒、6秒才刷一次。个人经验在做定时任务时尽量给ScheduledThreadPoolExecutor设置一个合理的核心线程数不要用单线程的Executors.newSingleThreadScheduledExecutor()。因为如果其中一个定时任务因为某种原因卡住了比如等一个永远不会来的锁其他定时任务也会一起遭殃。用多线程可以隔离部分风险但要注意同一批任务之间不要再互相等待否则还是会死锁。2.4 线程池参数背后的真实意义线程池的核心构造方法长这样public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueueRunnable workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)这七个参数每个都不难理解但它们的协作关系才是重点。我用自己的话给这套逻辑做个“翻译”当新任务进来时如果当前运行的线程数小于corePoolSize即使有空闲线程也会新建线程来执行这个任务。线程池“优先加人不排队”。如果当前运行的线程数大于等于corePoolSize新任务会放到workQueue里排队等待。如果队列也满了线程池才会考虑继续增加线程数直到达到maximumPoolSize。如果线程数已经达到maximumPoolSize队列也满了再来新任务就触发拒绝策略。在corePoolSize以上的线程如果空闲了keepAliveTime时间会被回收掉控制资源使用。很多人背过这套逻辑但实际配置时还是会乱。我来给几个真实的配置建议IO密集型任务比如大量HTTP调用、数据库查询、文件读写这类任务大多数时间在等待IO线程本身并没有满负荷工作。所以核心线程数可以设大一些常见的经验公式是CPU核数 * 2或者更高。CPU密集型任务比如复杂计算、加解密、图像处理这类任务几乎占满了CPU时间片核心线程数设置太多反而会频繁切换上下文降低效率。一般设置为CPU核数 1是常用的选择。混合型任务如果既有计算又有IO建议拆分成两个不同的线程池分别处理不要让一个池子同时承担两种负载不然当计算任务占满线程时IO任务的响应速度会明显下降。在队列选择方面我个人的建议是如果任务数量波动不大用有界队列比如ArrayBlockingQueue容量根据峰值流量预估。如果需要尽可能不拒绝任务但允许一定延迟可以用无界队列比如LinkedBlockingQueue不指定容量。但无界队列意味着maximumPoolSize形同虚设线程数永远不会超过corePoolSize这一点非常重要——有些人配置了maximumPoolSize但队列是无界的结果发现线程数一直上不去就是这个原因。如果希望任务能被消费者“直接处理”不经过缓存用SynchronousQueue这是newCachedThreadPool的默认配置。这就是为什么不建议直接使用Executors提供的静态工厂方法因为newFixedThreadPool和newSingleThreadExecutor用的都是无界队列任务一多会堆积在内存里OOM风险很高。而newCachedThreadPool用的SynchronousQueue要求有消费者立刻接单否则会不断创建线程直到OOM。最安全的做法是自己newThreadPoolExecutor并指定有界队列和拒绝策略。3. 实操过程与核心环节实现3.1 手写一个简化版阻塞队列彻底搞懂Condition光看不练是不够的我建议你自己动手写一个简化版的阻塞队列。当你亲手用ReentrantLock和Condition实现一次put和take之后你对阻塞队列的理解会完全不一样。public class SimpleBlockingQueueT { private final Object[] items; private int takeIndex; private int putIndex; private int count; private final ReentrantLock lock new ReentrantLock(); private final Condition notEmpty lock.newCondition(); private final Condition notFull lock.newCondition(); public SimpleBlockingQueue(int capacity) { if (capacity 0) { throw new IllegalArgumentException(capacity must 0); } items new Object[capacity]; } public void put(T e) throws InterruptedException { lock.lockInterruptibly(); try { while (count items.length) { notFull.await(); } items[putIndex] e; if (putIndex items.length) { putIndex 0; } count; notEmpty.signal(); } finally { lock.unlock(); } } SuppressWarnings(unchecked) public T take() throws InterruptedException { lock.lockInterruptibly(); try { while (count 0) { notEmpty.await(); } T e (T) items[takeIndex]; items[takeIndex] null; if (takeIndex items.length) { takeIndex 0; } count--; notFull.signal(); return e; } finally { lock.unlock(); } } }这里有几个细节值得注意第一个是while而不是if包裹await()。这里面有讲究——Condition.await()在唤醒之后并不会重新检查条件如果在等待期间有其他线程抢占了队列空间唤醒后直接往下走可能又遇到队列空或满的情况。用while是为了在每次唤醒后重新检查条件保证安全性。这是写阻塞代码的一个通用经验不光是这个例子任何使用Condition.await()的地方都建议用while循环包裹。第二个是循环数组的处理。putIndex和takeIndex走到末尾时都要归零这样才能复用数组空间。ArrayBlockingQueue底层用的就是这个套路只是实现得更精细。第三个是lockInterruptibly()和lock()的区别。lockInterruptibly允许线程在等待锁的过程中响应中断这一点在阻塞队列这种场景下很重要——如果线程持锁等待时被中断它可以立即退出而不是一直等到拿到锁后才去判断中断状态。3.2 手写一个线程池把核心参数变成看得见的逻辑理解了阻塞队列之后我建议再实现一个简化的线程池。这个过程能把线程池的所有参数含义具象化。public class SimpleThreadPool { private final BlockingQueueRunnable workQueue; private final int corePoolSize; private final int maximumPoolSize; private final ListWorker workers new ArrayList(); public SimpleThreadPool(int corePoolSize, int maximumPoolSize, int queueCapacity) { this.corePoolSize corePoolSize; this.maximumPoolSize maximumPoolSize; this.workQueue new ArrayBlockingQueue(queueCapacity); } public void execute(Runnable task) { synchronized (workers) { if (workers.size() corePoolSize) { addWorker(task); return; } } boolean offered workQueue.offer(task); if (!offered) { synchronized (workers) { if (workers.size() maximumPoolSize) { addWorker(task); return; } } // 拒绝策略 throw new RejectedExecutionException(queue full and worker pool exhausted); } } private void addWorker(Runnable firstTask) { Worker worker new Worker(firstTask); workers.add(worker); Thread thread new Thread(worker); thread.start(); } private final class Worker implements Runnable { private Runnable firstTask; Worker(Runnable firstTask) { this.firstTask firstTask; } Override public void run() { Runnable task firstTask; firstTask null; while (task ! null || (task workQueue.poll()) ! null) { try { task.run(); } finally { task null; } } } } }这段代码的真实含义是一个Worker线程不止执行一个任务它执行完firstTask之后还会继续从队列里拿下一个任务。这就是“线程复用”的本质——线程本身没有被销毁只是变成了一个循环执行的体力工人任务是一个接一个喂给它的。实际ThreadPoolExecutor的实现复杂度比这个高得多但它核心的机制就是这样的Worker线程是一个Runnable它内部有一个while循环不断从workQueue里取任务。设置keepAliveTime和allowCoreThreadTimeOut之后如果线程在规定时间内没拿到新任务就退出循环线程自然结束。这里我也要提醒一点在上述简化例子中如果队列里的任务永远取不完这些Worker线程就会一直存活这是线程池为什么能减少线程创建销毁开销的原因但也意味着如果你不彻底关闭线程池这块内存和线程资源就不会释放。所以在应用关闭或动态调整线程池时一定要调用shutdown()或shutdownNow()。3.3 定时器 线程池组合应用延迟重试的优雅实现在用定时器做业务开发时有一个很经典的场景是“延迟重试”。比如调用第三方接口失败后希望能过5秒钟再重试一次如果在重试过程中又失败就再过10秒重试。用ScheduledThreadPoolExecutor可以很优雅地实现这种需求。ScheduledExecutorService retryExecutor Executors.newScheduledThreadPool(2); public void retryTask(Runnable task, int retryCount) { scheduleRetry(task, retryCount, 5, TimeUnit.SECONDS); } private void scheduleRetry(Runnable task, int retryCount, int delay, TimeUnit unit) { retryExecutor.schedule(() - { try { task.run(); System.out.println(任务执行成功); } catch (Exception e) { if (retryCount 0) { scheduleRetry(task, retryCount - 1, delay * 2, unit); } else { System.out.println(重试次数耗尽任务失败); } } }, delay, unit); }这段代码的关键点在于“递归地提交定时任务”。每次失败后重新提交一个延迟更长的任务到调度器而不是在同步代码里Thread.sleep()等待。这样做的好处有两个一是不会占用工作线程。如果用Thread.sleep()当前线程会被白白占住什么事都不干而用schedule提交任务后线程可以继续处理其他任务到了延迟时间再回来执行。二是每个重试任务之间是独立的。即使前一次任务抛出异常也不会影响后面已经排队的任务因为它们本质上是独立提交给线程池的。这个模式在实际项目里非常常见比如订单超时检查、支付结果主动查询、消息补偿机制底层大多都是“延迟任务 重试策略”的组合。4. 常见问题与排查技巧实录4.1 线程池提交顺序为什么任务不先排队而是先创建线程很多人对线程池的“任务添加顺序”有误解以为新任务到了以后应该先让已有的线程处理实在忙不过来了再新建线程。但实际逻辑恰恰相反**当运行线程数小于corePoolSize时新任务会直接新建线程来执行而不是让已有线程去队列里取任务。**这个设计初看不够“节省”但仔细想想是有道理的——新建线程只发生在池子还很“空”的阶段此时优先响应新任务能降低任务延迟而且在这个阶段不可能有大量闲置线程存在新建线程的代价是可控的。到了corePoolSize以上任务才开始走队列。这意味着如果线程池核心线程数是10你连续提交了50个任务前10个会直接分配线程执行后面40个进入队列排队。而如果队列满之后继续提交任务线程数才会继续增加到maximumPoolSize。这个逻辑在排查问题时会经常用到。比如你发现某个线程池的线程数一直稳定在corePoolSize、但任务积压很严重那要么是队列太大导致任务堆积要么是每个任务执行时间太长。相反如果线程数经常冲到maximumPoolSize说明队列已经顶不住压力了需要扩容或者优化任务执行速度。4.2 线程池的队列应该怎么选无界队列的风险在Executors的静态方法中newFixedThreadPool和newSingleThreadExecutor采用的都是无界队列LinkedBlockingQueue。这意味着当提交任务的速度长期大于消费速度时队列会无限增长最终导致内存被耗尽、系统OOM。不要觉得OOM离自己很远。我在实际项目中就遇到过这种情况一个数据同步任务由于下游接口突然变慢每个任务执行时间从200毫秒变成5秒而生产端还在源源不断地往线程池里提交任务队列里积压了几百万个任务每个任务还持有一批对象JVM堆直接被占满整个服务都挂了。所以凡是涉及线程池配置我的建议统一是**优先选择有界队列给队列一个明确的容量上限并配置好拒绝策略。**拒绝策略也不是越激进越好AbortPolicy默认直接抛出RejectedExecutionException适合对任务丢失零容忍的场景。CallerRunsPolicy任务不会被丢弃而是由提交任务的线程自己执行。好处是天然的“背压机制”——生产速度会被迫降下来坏处是执行的线程可能不是业务期望的线程而且如果提交任务的是主线程主线程会被阻塞。DiscardPolicy静默丢弃不报错。适合能容忍偶尔丢消息的场景但生产环境不建议直接使用容易留下隐患。DiscardOldestPolicy把队列头最老的任务丢掉再重试提交当前任务。适合追求任务时效性的场景比如做实时统计时旧数据丢弃影响不大。最稳妥的组合是用有界队列 CallerRunsPolicy这样既不会丢任务也不会让系统直接崩溃代价是提交端的线程会被占用从而自然限流。4.3 定时任务不执行或不准时排查思路定时任务不执行最常见的几种情况第一种是线程池里的线程数不够而某个任务执行时间过长占了所有线程。如果是newSingleThreadScheduledExecutor()那就只有一个线程一个阻塞的任务就会拖垮所有定时任务。解决办法是改用多线程调度器并且排查为什么任务会卡住。第二种是任务抛出了异常。注意ScheduledThreadPoolExecutor中如果任务执行抛出异常这个异常会被吞掉吗实际上在任务执行过程中抛出异常会中断当前任务的后续执行而且异常会被封装到Future里如果你使用schedule()返回的ScheduledFuture而不调用get()异常可能很难发现。因此我的建议是所有定时任务的方法体里都要自己try-catch至少打一条日志。千万不要让异常冒出去。第三种是时间不准。ScheduledThreadPoolExecutor的定时精度依赖系统时钟如果服务器时间被手动调整定时任务可能提前或延后触发。这在生产环境很少见但如果你的部署环境有NTP时间校准理论上有时间跳动导致误触发的风险可以在任务里增加逻辑二次校验。4.4 单例模式导致死循环或栈溢出单例模式在Spring容器里特别常见但有一个隐患是构造方法里如果调用了其他Bean的方法而这些Bean又反过来依赖当前Bean就会形成循环依赖。Spring的循环依赖在单例模式下有三级缓存机制能解决但在某些情况下比如构造函数注入会直接报BeanCurrentlyInCreationException。用双重检查锁手写单例时还有一个隐蔽的问题如果你的单例类里维护了可变状态比如一个共享的Map、一个计数器、一个缓存列表即使单例对象的创建是线程安全的对这些可变字段的读写也必须加锁或使用并发容器。很多线上bug就是这么来的单例创建的线程安全保证了但共享数据本身的线程安全没保证两码事。4.5 排查工具怎么确认线程池状态和任务积压线上排查线程池问题时我常用的思路是把ThreadPoolExecutor的核心指标暴露到监控系统里。比如getPoolSize()当前线程数看是否到达maximumPoolSize。getActiveCount()活跃线程数看有多少线程在干活。getQueue().size()队列积压数量这是最直观的压力指标。getTaskCount()/getCompletedTaskCount()累计任务数和已完成数用来计算吞吐量和平均执行耗时。配合jstack命令还能直接看到线程栈里的线程名、状态和正在执行的任务。如果一个Worker线程长期处于RUNNABLE状态而总是不结束多半是有个任务卡住了。如果线程一直处于WAITING状态可能是队列空线程在take()那里等任务。这些信息结合起来可以快速定位线程池的大部分问题。如果是在JDK 8之后还可以使用ThreadPoolExecutor的submit()方法配Future来获取任务执行结果配合Future.get(timeout)来做超时控制防止某个任务把线程池拖垮。但要注意Future.get()超时后只是当前线程不再等待任务本身还会继续执行。换句话说超时取消并不会中断任务除非你在超时处理逻辑里主动去cancel(true)而cancel(true)是否能真正中断任务又取决于任务是否响应了中断标志。5. 几个容易忽略的并发细节5.1 线程工厂线程名不设置排查问题难上天很多人用线程池时不设置ThreadFactory导致线程池里生成的线程名字千篇一律比如pool-1-thread-1。一旦线上出现线程占用过高、死锁等问题你拿jstack一看满屏都是pool-1-thread-*根本分不清是哪个业务模块的线程。我在实际项目中吃过这个亏后来养成了一个习惯所有线程池必须自定义ThreadFactory把线程名设置为有业务语义的格式比如order-sync-worker-1、mq-consumer-1。这样排查问题时看到线程名就能立刻知道是哪个业务链路出了问题。ThreadFactory threadFactory new ThreadFactory() { private final AtomicInteger counter new AtomicInteger(1); Override public Thread newThread(Runnable r) { Thread thread new Thread(r); thread.setName(order-sync-worker- counter.getAndIncrement()); thread.setDaemon(false); return thread; } };在Java 8之后还有更简洁的写法比如new ThreadFactoryBuilder()Guava或者直接用Thread.ofPlatform()配合name()方法Java 21。但核心思路是一致的线程名要有辨识度不能图省事。5.2 线程池参数动态调整不用重启也能改ThreadPoolExecutor提供了几个动态调整参数的方法setCorePoolSize()修改核心线程数。如果新值小于当前线程数多余的线程会在空闲后回收如果新值大于当前线程数线程池会在后续任务到来时直接新建线程补齐。setMaximumPoolSize()修改最大线程数。setKeepAliveTime()修改空闲线程存活时间。这些方法在运行期是安全的可以用来做动态扩缩容。比如在业务流量高峰前把核心线程数调大流量回落后再调回正常值。很多中间件比如Dubbo、Sentinel的线程池动态调整就是基于这个能力实现的。不过要注意setCorePoolSize()在向下调整时并不会立刻销毁线程它只是允许空闲线程被回收。如果线程正处于执行任务中会等任务执行完并空闲一段时间后才退出。因此调整后并不是马上见效预留足够的“冷却时间”。5.3 线程池优雅关闭别用shutdownNow()一把梭应用关闭时如果线程池里还有正在执行的任务直接调用shutdownNow()会向所有工作线程发送中断信号强制终止任务执行。如果一个任务正在写数据库、发消息被中断可能造成数据不一致或者重复执行。更稳妥的做法是分两步先调用shutdown()让线程池停止接收新任务同时让已经提交的任务继续执行完然后再根据业务情况设置一个等待时间超时后再调用shutdownNow()兜底。executor.shutdown(); if (!executor.awaitTermination(30, TimeUnit.SECONDS)) { executor.shutdownNow(); }这段代码是标准的优雅关闭模板。第一行关闭入口第二行给30秒的“宽限期”让现有任务跑完。如果30秒后还有任务没结束说明任务执行时间不可控或存在死锁这时候再强制中断。这个策略在微服务应用优雅下线时特别重要否则你正在处理的请求可能在服务停止的瞬间被硬切造成用户侧看到大量超时或错误。5.4 线程池与ThreadLocal子线程拿不到父线程的值在使用线程池时如果一个任务里用到了ThreadLocal你需要特别注意线程池里的线程是复用的ThreadLocal的值在任务之间会相互污染。同一个线程执行任务A时往ThreadLocal里存了值如果它没有被清理执行任务B时会仍然看到任务A的数据。这在做租户隔离、链路追踪时是致命的bug。解决办法有两个一是每次任务执行完成后在finally块里调用ThreadLocal.remove()。但这样要求每个业务代码都记得清理容易漏。二是使用TransmittableThreadLocal阿里开源的TTL它能在线程池场景下传递线程上下文并在任务执行完毕后自动清理。这是目前公认的“线程池 ThreadLocal”的最佳实践方案。如果你们项目里已经引入了阿里巴巴的规范插件大概率也会建议你避免在Runnable里直接使用ThreadLocal至少要在任务入口和出口手动清理。这个坑我踩过不止一次写出来给大家提个醒。6. 写在最后的实战心得在写这篇文章的过程中我又把JDK里ThreadPoolExecutor的源码翻了一遍每次翻都有新的理解。最大的体会是并发编程不是“记住多少锁的名字、背过多少参数”就能解决的真正决定水平的是你能不能在一个具体的业务场景里把共享对象的可见性、互斥性、等待通知机制、任务调度策略这些基础概念组合起来设计出一套可靠又高效的方案。单例模式教会我“发布共享对象要小心指令重排”阻塞队列教会我“生产消费之间的节奏不匹配要用缓冲来缓解”定时器教会我“延迟调度要考虑到线程的生命周期”线程池教会我“资源复用是有上限的超限就要有兜底策略”。这四个案例串起来其实就是一套完整的并发思维模型。如果你刚学完多线程基础建议按这篇文章的顺序把每个案例自己动手敲一遍再想想“如果不这样做会怎样”。比如把双重检查锁里的volatile去掉写个循环去创建单例对象观察不同线程拿到的对象状态比如用手写的阻塞队列做一次生产者-消费者再把队列容量改成1试试看会发生什么。这些实验比背十道八股文有意义得多。最后分享一个小技巧在实际项目里给线程池命名时我习惯把业务模块名和线程类型都加进去比如order-query-pool、pay-timeout-check-pool。因为线上问题排查时能一眼从线程名定位到出问题的模块能省下大量时间。这个习惯我保持了很多年强烈推荐你也养成。
