搞线程控制的这些年我最大的感触是很多人不是不会写并发代码而是不会“管”线程。先讲个真实经历。之前维护过一个定时任务系统某天凌晨所有任务突然全部卡死线上日志一片寂静。jstack一看十几个线程全部停在Object.wait()上而负责notify()的那个线程早就因为异常死掉了。那次事故之后我花了整整一周时间重写了线程控制相关的底层模块也彻底搞懂了wait/notify、interrupt、线程池这些机制在实战中到底是怎样工作的。这篇文章就把我对“线程控制”的理解和踩过的坑完整记录下来适合刚接触并发编程、或者写过一点多线程但总感觉控制不住线程运行节奏的开发者。1. 线程控制的本质搞懂生命周期再说怎么管1.1 为什么说线程控制是并发编程的“方向盘”如果把并发编程比作开车那线程就是路上的车控制机制就是方向盘、油门、刹车。没有控制线程就是脱缰的野马想停停不下来想协作还互相打架。线程控制说到底就四件事怎么启动、怎么暂停、怎么协作、怎么终止。很多初学者觉得“启动一个线程还不简单new 一个 Thread 然后 start() 就完事了”。真正到了生产环境你会发现线程的启动只是最基础的一环更关键的是后续的控制任务跑到一半怎么优雅地停下来多个线程之间怎么互相通知线程卡死了怎么定位和恢复这些都需要对 Java 线程模型有一个系统性的认知。1.2 六种状态与状态迁移控制线程的前提Java 线程从创建到销毁一共六种状态Thread.State枚举很多人背过但真正遇到问题时往往对应不上。我用一个表格先把它说清楚状态含义进入方式退出方式NEW已创建未启动new Thread()start()RUNNABLE运行中或可运行start()或从阻塞恢复抢占CPU、调用yieldBLOCKED等待监视器锁进入synchronized块时锁被占用获取到锁WAITING无限期等待wait()、join()、LockSupport.park()被notify/notifyAll、被join线程结束、unparkTIMED_WAITING有超时等待sleep(ms)、wait(timeout)、join(ms)超时、被唤醒TERMINATED已终止run() 方法正常结束或抛出未捕获异常无这张表看起来简单但里面有最容易被忽视的细节BLOCKED 和 WAITING 是两种完全不同的阻塞。BLOCKED 是“锁被别人拿走了我在门口等着”WAITING 是“我主动让出CPU等别人来叫我”。很多线上排查时把这两者混为一谈导致定位方向南辕北辙。1.3 状态迁移的典型陷阱sleep不会释放锁这里有个面试高频题也是实战大坑Thread.sleep()在执行时会释放锁吗答案是不释放。sleep只是让当前线程暂停执行但它持有的监视器锁一个都不会释放。这意味着你在synchronized代码块里调用sleep其他线程只能在锁外面干等着哪怕它们在TIMED_WAITING状态也不会触发notify唤醒。反观wait()方法它一调用就会释放当前线程持有的锁然后进入 WAITING 状态。这是sleep和wait最本质的区别也是控制线程协作时必须想清楚的底层机制。2. 线程启停的正确姿势stop已经被判死刑了2.1 为什么 Thread.stop() 是设计缺陷先问个问题你想停一个线程第一反应是不是找有没有stop()方法有但这个方法在 JDK 文档里明晃晃地标注了Deprecated而且注释里的措辞非常严厉根本就是不安全的。原因其实很直观。Thread.stop()会在任意位置直接抛出ThreadDeath异常把线程正在执行的任何逻辑都打断包括正在写文件、正在提交事务、正在更新内存数据的过程中。锁会突然释放资源来不及清理数据可能只写了一半。如果被中断的这段代码正在执行一个金额转账操作那线上就等着出事吧。实际工作中我就见过这种事故。同事图方便用stop()去终止一个轮询线程结果线程在写数据库的半途被干掉连接池里的连接全乱了最后整个应用重启才恢复。这个问题的本质是stop()强行打断了线程的原子操作破坏了数据一致性。2.2 interrupt 中断机制协作式取消的正解正确的做法是用中断机制也就是interrupt()方法。Java 的中断是协作式的它不是从外部强行杀死线程而是给线程打一个“中断标志”由线程自己决定在合适的时机如何响应。写法上通常是这样public class InterruptibleTask implements Runnable { Override public void run() { while (!Thread.currentThread().isInterrupted()) { doWork(); } // 收到中断信号后做清理工作再退出 cleanUp(); } }这里最关键的是isInterrupted()的判断它不会清除中断标志只是查看当前线程是否有中断请求。另一种写法是interrupted()它会同时清除标志位使用时要想清楚是否需要重置状态。除了轮询标志位还有一个重要的渠道阻塞方法的中断响应。当线程正在执行wait()、sleep()、join()这类可中断方法时如果其他线程调用了它的interrupt()这个方法会立刻抛出InterruptedException同时清除中断标志。2.3 处理 InterruptedException 的两种正确姿势很多人遇到InterruptedException习惯性catch完就不管了这是非常糟糕的做法。中断信号是重要的线程控制指令你把它吞掉就相当于对发令员说“我没收到”。处理方式分两种第一种直接向上抛如果当前方法本身就声明了可以抛该异常直接throws InterruptedException让上层决定怎么处理。这适合不需要清理资源的场景。第二种恢复中断标志后继续往下走如果当前代码不能抛异常比如实现的是Runnable.run()那就在 catch 块里恢复中断状态让上层逻辑有机会感知try { Thread.sleep(1000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 记录日志必要时直接return return; }这里我特别强调重置中断标志不是可选项而是必须做的。你catch住异常之后如果不重新设置标志位外层代码通过isInterrupted()检查时会发现线程一切正常拦截不到任何中止信号最终导致线程无法优雅退出。这个坑我踩了至少两回每次都排查到怀疑人生。3. 线程协作控制wait/notify 与 join 的底层真相3.1 wait/notify 为什么必须放在 synchronized 里先上一段最经典的“等待-通知”模板synchronized (lock) { while (condition) { // 必须用while不能用if lock.wait(); } doSomething(); }很多新手不理解为什么wait()必须要放在synchronized块里直接调用会抛IllegalMonitorStateException。我的理解是这样的wait()的作用是“等待某个条件成立”而这个条件必然涉及共享变量。要判断条件、等待条件、改变条件这三步必须是原子性的。synchronized保证了同一时刻只有一个线程能执行条件检查和状态修改而wait()在阻塞前会自动释放锁这才把机会交给其他人。用大白话说你进了一个房间拿到锁发现条件不满足比如队列空了于是你把房间钥匙交出来wait释放锁在门口等着。另一个线程拿到钥匙进去往队列里放数据放完通知你notify你再拿钥匙进去继续干活。关键点来了为什么检查条件要用while而不是if因为从wait()返回后线程必须重新竞争锁才能继续执行。在它等待的这段时间里可能有好几个生产者都往队列里放了数据也可能有别的消费者早就把数据消费光了。等你拿到锁的时候之前的条件可能已经不成立。如果用的是if线程会无脑往下走比如从空队列里取数据直接取到 null 然后空指针。while保证你醒来之后再检查一次条件不满足就继续等这叫“循环条件检查”是等待-通知机制的规范写法。3.2 join 的底层实现其实就是 wait(0)再来说join()。它是控制线程之间“先后顺序”的利器主线程调用t.join()会等 t 线程执行完再继续。但很多人不知道的是join()的底层实现就是wait()。看 JDK 源码可以看到public final synchronized void join(long millis) throws InterruptedException { while (isAlive()) { wait(0); } }也就是说join 的核心逻辑是把当前线程放到“被join线程对象”的等待队列上一直等到被join线程结束系统会调用notifyAll()唤醒等待者。这里有个非常隐蔽的坑join()方法是synchronized的锁对象是线程对象本身。如果你在线程对象上做其他同步控制和join()发生锁竞争可能导致意外的阻塞。所以线上代码我基本不直接在线程对象上用synchronized更推荐用专门的锁对象或并发工具类。3.3 用 CountDownLatch 替代裸 wait/notify 的实战建议说了这么多 wait/notify其实我个人的建议是能用并发工具类就尽量别自己手写 wait/notify。Java 并发包提供了CountDownLatch、CyclicBarrier、Semaphore它们的设计更安全、意图更明确。比如要控制“三个子任务全部完成后主线程再继续”CountDownLatch的写法几乎不会出错CountDownLatch latch new CountDownLatch(3); ExecutorService pool Executors.newFixedThreadPool(3); for (int i 0; i 3; i) { pool.submit(() - { try { doTask(); } finally { latch.countDown(); } }); } latch.await();注意我特意把countDown()写在了finally里。如果任务抛异常导致没调用countDown主线程就会永远等下去。这是并发编程里最常见也最隐蔽的「永久阻塞」来源。4. 生产者-消费者实战一个完整的线程控制案例4.1 场景设定与设计思路光说理论不过瘾直接上一个实战场景一个文件处理中间件上游不断产生待处理文件路径下游多个工作线程并发消费。设计上的核心诉求有三个队列不满时生产者不阻塞、队列不空时消费者不空转、控制线程的启停保证系统能优雅关闭。这个场景里线程控制的难点主要集中在“协作”和“终止”。生产者要往队列放数据消费者要从队列取数据两者之间既要互斥又要协作还要能随时响应关闭指令。4.2 基于 wait/notify 的经典实现用wait/notify手写一版方便理解底层逻辑class FileQueue { private final LinkedListString queue new LinkedList(); private final int capacity 100; public synchronized void put(String filePath) throws InterruptedException { while (queue.size() capacity) { wait(); // 队列满了等着消费者腾位置 } queue.addLast(filePath); notifyAll(); // 通知消费者可以取数据了 } public synchronized String take() throws InterruptedException { while (queue.isEmpty()) { wait(); // 队列空了等着生产者放数据 } String filePath queue.removeFirst(); notifyAll(); // 通知生产者有位置了 return filePath; } }这段代码有两个细节值得注意第一notifyAll()用的是“唤醒所有”而不是notify()只唤醒一个。原因在于 Java 的notify()唤醒的线程是随机选择的如果没有唤醒正确的线程比如消费者都睡了但唤醒的还是一个消费者系统可能会假死。虽然notifyAll()性能略低一点但安全性高得多。第二wait()必须放在while循环里。队列满的时候即使被notifyAll()唤醒也可能被别的生产者抢先占用了位置必须重新检查条件。4.3 用 BlockingQueue 实现更省心的线程控制手写 wait/notify 适合理解原理但生产环境我更推荐直接用ArrayBlockingQueue。它内部封装好了锁和条件队列几乎不会写错BlockingQueueString queue new ArrayBlockingQueue(100); // 生产者 queue.put(filePath); // 满则阻塞 // 消费者 String filePath queue.take(); // 空则阻塞配合线程池的版本大概是这样ExecutorService consumerPool Executors.newFixedThreadPool(4); while (running.get()) { try { String filePath queue.poll(500, TimeUnit.MILLISECONDS); if (filePath ! null) { consumerPool.submit(() - processFile(filePath)); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } }这里poll(500, TimeUnit.MILLISECONDS)是很关键的设计。如果队列空了take()会永久等着万一running被置为 false线程也无法退出。poll带超时可以让线程每隔 500 毫秒检查一次退出标志兼顾了“等待数据”和“响应终止”两个需求。4.4 优雅关闭先停生产者再停消费者线程控制的另一个核心场景是系统关闭。我见过很多应用重启时直接System.exit()导致积压任务丢失、数据损坏。正确的关闭顺序应该是先把running标志位设为 false让生产线程不再产生新任务等待生产者线程真正结束调用线程池的shutdown()禁止新任务提交调用awaitTermination()等待已有任务执行完running.set(false); producerThread.join(); consumerPool.shutdown(); if (!consumerPool.awaitTermination(30, TimeUnit.SECONDS)) { consumerPool.shutdownNow(); }shutdownNow()会向线程池中所有线程发送中断信号这时就体现出了前面“响应中断”的重要性如果任务线程正确处理了InterruptedException就能在中断后完成资源清理而不是被暴力终止。5. 线程池场景下的线程控制池化之后更考验管理能力5.1 核心参数如何决定线程的创建与回收线程池本质上是把线程生命周期统一托管但托管不等于放任不管。ThreadPoolExecutor有 7 个构造参数真正决定线程行为的是其中三个corePoolSize、maximumPoolSize、workQueue。它们之间的配合关系是提交任务时线程数小于corePoolSize就直接新建线程达到核心线程数且队列未满任务入队等待队列满了且线程数小于maximumPoolSize继续新建线程队列满且线程数达到上限执行拒绝策略。这里有个常见的认知误区核心线程空闲时不会自动回收除非设置了allowCoreThreadTimeOut(true)。如果你用Executors.newFixedThreadPool(4)创建了一个固定线程池即使所有线程空闲程序也不会自动把线程数降下来它们会一直占着资源。需要注意的一个细节是队列类型会极大影响线程池行为。LinkedBlockingQueue默认无界意味着队列几乎永远不满线程数永远不会涨到maximumPoolSize。所以如果你设置了maximumPoolSize10同时用了无界队列那另外 6 个线程实际上就是摆设。5.2 线程池关闭的正确姿势上一节提了一嘴shutdown和shutdownNow这里再展开说说两者的细微区别。shutdown()是优雅关闭停止接收新任务但已提交的任务继续执行。shutdownNow()是立即关闭给每个工作线程发中断信号同时返回尚未执行的任务列表让你有机会自己处理这些积压任务。实际工作中我的策略是先shutdown()然后调用awaitTermination(timeout)等待如果超时还未终止再调用shutdownNow()强制中断。这里的超时时间要根据任务的平均执行时长来定不能拍脑袋。还要注意一个细节不要在关闭线程池后立即提交任务这会抛RejectedExecutionException。高并发场景下这种异常很容易被忽略导致业务数据悄无声息地丢失。建议统一用Future.get()捕获或用submit()时的返回值做兜底。5.3 自定义拒绝策略不能只是简单抛异常当任务提交速率超过线程池处理能力队列也满了就会触发拒绝策略。JDK 默认提供了四种AbortPolicy直接抛异常这是默认策略CallerRunsPolicy让提交者线程自己执行这个任务DiscardPolicy默默丢弃DiscardOldestPolicy丢弃最老的任务我用的最多的是CallerRunsPolicy它在任务量过大时把压力反向传递给调用方迫使调用方线程去执行任务天然起到背压效果削峰填谷非常好用。不过如果你不想让调用线程被慢任务拖垮可以自定义策略写个日志然后放到一个单独的“兜底队列”里异步重试RejectedExecutionHandler handler (r, executor) - { // 记录告警日志或者写入重试队列 retryQueue.offer(r); };这种方案比直接丢弃稳得多也比抛异常更柔顺。核心思路是拒绝不是目的让任务不丢才是目的。6. 常见问题与排查技巧实录6.1 线程“假死”问题notify 丢了还是等待条件误用开篇提到的那个故障就是典型的线程假死。所有工作线程都停在wait()上没有异常日志没有死锁但系统就是一动不动。排查思路是这样先jstack看线程栈确认线程停在哪一行代码。然后重点检查两个地方一是notify和wait的调用是否保证了对同一把锁、同一个条件二是是否有异常发生在notify之前导致通知没有执行。我那次故障的根因是某个任务处理中抛了运行时异常导致notify()那行代码没执行消费者线程全部沉睡。修复措施很简单——把所有notify移动放到finally块中保证任何情况下都能发出唤醒信号。这个教训现在变成了我的一个强制规范wait/notify 代码块中任何可能抛异常的操作都要用 try-finally 包住确保通知一定被发出。6.2 死锁排查jstack 定位 锁顺序统一死锁和假死最大的区别是死锁线程通常处于 BLOCKED 状态互相持有对方需要的锁。jstack输出最后几行里如果出现Found one Java-level deadlock恭喜你定位就完成了。排查死锁我最常用的套路是jps找到进程号jstack pid导出线程快照搜索deadlock关键字看哪些线程互相持有锁死锁的根治靠代码规范所有地方按同一顺序获取锁。比如有两个锁 A 和 B所有线程都先拿 A 再拿 B死锁就不存在了。实在无法统一顺序时用tryLock带超时获取不到就释放已有锁重试。6.3 线程泄漏线程池只增不减的隐患线程泄漏比内存泄漏更隐蔽。常见场景是每次请求进来都新建一个线程池任务跑完不做shutdown。时间一长线程池对象不会被 GC 回收因为池里的活跃线程是 GC Root 可达的对象。更隐蔽的泄漏场景是使用ThreadLocal但忘记清理。线程池里线程是复用的前一个请求设置的值会被后一个请求读到轻则数据串位重则业务逻辑出错。我处理过一起线上事故用户 A 的订单信息被用户 B 看到了就是线程池复用 ThreadLocal未清理导致的。解决方案只有一句话必须显式 remove。try { // 业务逻辑 } finally { threadLocal.remove(); }在线程复用场景下不清理ThreadLocal等于犯罪。6.4 锁竞争激烈导致CPU飙升synchronized 过度使用的代价这种情况也很典型CPU 使用率持续 100%但业务吞吐量极低。jstack看到大量线程处于BLOCKED都挤在同一个synchronized方法上。这里的核心问题是临界区过大。把synchronized加在方法上等于整个方法体都成了串行区并发完全失效。优化方向就两个缩小临界区只把真正需要同步的几行代码锁住用更细粒度的锁比如读写锁ReentrantReadWriteLock读多写少场景下能明显提升并发度不过我要提醒一句锁粒度太细也可能带来额外开销比如获取锁、上下文切换的成本。取舍的标准是实际压测数据不要凭感觉。6.5 常见问题速查表症状可能原因检查命令/方法线程全部停住无异常wait 后没有 notifyjstack 查看线程栈检查 notify 是否在 finally 中线程互相等待CPU 低死锁jstack 搜索 deadlock 关键字CPU 高吞吐低锁竞争激烈查看 BLOCKED 线程数量缩小临界区线程数不断增长内存上涨线程池未关闭或未复用检查代码中是否频繁新建线程池数据串位出现脏数据ThreadLocal 未清理代码审查检查线程池中 ThreadLocal 使用6.6 几个实战中的独家建议最后分享几个我用血的教训换来的经验第一线程名字一定要取好。比如async-order-processor-1、batch-file-worker-2排查问题时 jstack 输出里看到有意义的名字能省一半时间。不要都叫pool-1-thread-1当你有几十个线程池时真的会疯。第二给每个线程池设置独立的命名工厂。用 Guava 的ThreadFactoryBuilder或者自定义ThreadFactory把线程名前缀和服务名、业务类型关联起来。这个习惯在查线上问题时价值连城。第三处理中断异常时永远先响应中断再决定下一步动作。不要看着InterruptedException是 checked 异常就随手catch完事。它承载着“别人希望这个线程停下来”的信号职责很重。第四异步线程一定要配置独立的异常处理器。通过setUncaughtExceptionHandler或者线程池的afterExecute钩子记录异常否则子线程里的异常会无声无息地消失等你想排查时日志里什么都看不到。说实话线程控制这门手艺靠的从来不是记住某个 API而是对线程状态、锁、协作机制的整体把握。把生命周期搞懂、把中断机制用好、把协作工具选对你已经超越了大部分只在面试题里见过线程的开发者。遇到诡异的问题不要慌jstack 走一遍线程栈永远会告诉你真相。