首先抛出那个经典问题在Java中有三个线程T1、T2、T3如何保证顺序执行我最早看到这题是在各种Java面试八股文里当时觉得就是个入门题背个join就完事了。直到后来做支付对账系统早上启动时要先加载基础配置、再拉取商户白名单、最后才把批量任务丢进线程池每一步都必须等上一步完成否则数据全乱。我才意识到所谓顺序执行在真实项目里根本不是一句背答案能糊弄过去的。它背后牵扯线程的调度机制、任务编排思想、并发工具的选择艺术同样的问题在不同场景下答案完全不同。这篇文章我打算把从最简到最工程化的几种写法全部拆开连同原理和坑一起讲希望对正在准备面试或者正在设计初始化流程的你有用。1. 先想清楚顺序执行到底要控制什么1.1 线程的启动和执行本来就是两件事很多初学者有一个误解调用start()方法线程就会立刻从头跑到尾。实际上不是。start()只是把线程从新建状态丢进就绪队列告诉操作系统这个线程准备好了至于它什么时候真正拿到CPU时间片、能跑多久取决于操作系统的调度器。也就是说你在代码里写Thread t1 new Thread(() - System.out.println(T1)); Thread t2 new Thread(() - System.out.println(T2)); Thread t3 new Thread(() - System.out.println(T3)); t1.start(); t2.start(); t3.start();日志顺序完全可能输出T3 T1 T2甚至每次都不一样。多核环境下三个线程是并行跑的谁先打日志全看天意。所以想保证顺序第一步必须放弃靠启动顺序来保证执行顺序这个幻想。1.2 面试题里藏着两种完全不同的语义这种题目我第一次看到时很自然地写了t1.join(); t2.join(); t3.join()但后来被面试官追问了一句如果三个线程已经被同时 start 了你还能保证顺序吗 我才意识到这里藏着一个关键分歧点第一种语义主线程依次启动T1、T2、T3要求T1执行完再做T2T2执行完再做T3。这本质上是串行提交任务你可以在主线程里用join控制。第二种语义三个线程已经同时处于运行状态T2、T3自己在代码里等待只有收到前一个线程完成的信号才继续。这是并发约束需要用到同步工具。这两种思路没有对错但要看你面前的需求是哪种。真实开发里两种都有可能一次性启动引导流程多半用第一种三个线程已经在跑、希望它们交替完成某些阶段多半用第二种。搞清楚这个再往下看各种方案就不会乱。1.3 先排除那几个不靠谱的土办法网上能看到不少人推荐用Thread.sleep(固定时间)来排序比如让T1先睡0秒、T2睡500毫秒、T3睡1000毫秒以此期望错开执行。我只能说这种代码在演示环境偶尔能跑对生产环境一上去必翻车。线程被抢占、遇到GC停顿、CPU频率波动任何一点都会让时间估算失效。还有人说用Thread.setPriority优先级这同样不靠谱优先级只是给调度器一个参考并不是强制顺序。真正可行的方案都基于一个底层思想让后一个线程在某个锁、队列或信号量上阻塞直到前一个线程主动释放。接下来我们就按这个思路把常用方案一个个过。2. 最直接的方案Thread.join 背后的等待与唤醒2.1 三行代码解决主线程串行提交如果你只需要在主线程里按顺序跑完三个线程最直接的就是joinThread t1 new Thread(() - System.out.println(T1 执行)); Thread t2 new Thread(() - System.out.println(T2 执行)); Thread t3 new Thread(() - System.out.println(T3 执行)); t1.start(); t1.join(); t2.start(); t2.join(); t3.start(); t3.join(); System.out.println(三个线程都结束了);关键点在于t1.join()会让调用它的主线程进入等待直到t1死亡后再执行t2.start()。所以t2根本不会在t1结束前启动顺序天然成立。这个方案代码量最少也是多数面试者能脱口而出的答案。但它只适合主线程亲自编排的场景如果T2内部必须等到T1完成后自己才能干活join就管不着了。2.2 底层原理join 其实就是 wait/notifyjoin为什么能等到线程结束它不是靠轮询而是靠wait/notify。打开Thread.java源码join()最终会调用join(0)而join(0)的核心逻辑大概是public final synchronized void join(long millis) throws InterruptedException { // 处理超时时间 while (isAlive()) { wait(0); } }这里this就是当前线程对象比如主线程调用t1.join()主线程就是拿到t1对象的监视器锁然后进入while (isAlive()) wait(0)。只要t1还活着主线程就挂起。当t1运行结束JVM会在这个线程对象上调用notifyAll把正在等待该对象锁的线程唤醒。所以本质上join使用的是对象监视器 等待通知机制这也是为什么当你带着这个结论回去看面试题会明显比一句可以直接调用join更有料。2.3 join 的坑死等、超时和中断join()是无参版本会一直等下去。万一T1里有个死循环或者T1持有一把永远拿不到的锁主线程就会跟着永久阻塞。所以生产代码我更推荐带超时的版本t1.join(3000);这表示最多等3秒超时后主线程继续执行。但这样一来T1可能还没跑完T2就已经开始顺序又被破坏了。因此更稳妥的做法是配合Future做超时控制而不是盲目依赖join。另外join会抛出InterruptedException一定要记得处理比较好习惯是恢复中断状态try { t1.join(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 记录日志决定是否中止后续流程 }2.4 join 适合什么场景我自己使用join最多的场景是脚本类工具、单次启动逻辑、嵌入在main方法里等待后台线程完成收尾。它简单、直观不需要引入额外对象。但一旦任务数量变多、需要复用线程、要处理异常结果join就会显得笨重。这时候就该换线程池了。3. 工程化方案线程池和 Future 怎么把并发变成编排3.1 单线程线程池把任务排进同一个队列如果业务希望T1任务、T2任务、T3任务严格串行执行而且代码要尽量清爽我会用单线程线程池ExecutorService executor Executors.newSingleThreadExecutor(); executor.execute(() - System.out.println(T1 执行)); executor.execute(() - System.out.println(T2 执行)); executor.execute(() - System.out.println(T3 执行)); executor.shutdown();为什么这个能保证顺序newSingleThreadExecutor内部核心线程数是1其他任务会进入一个无界的LinkedBlockingQueue。唯一的工作线程从队列头部取任务取一个执行一个执行完再取下一个。只要提交顺序确定执行顺序就确定。但这里有个隐含坑如果你从多个线程并发提交任务提交顺序本身是竞争产生的那么执行顺序也会跟着乱。要保证顺序要么统一由一个主线程提交要么提交前也做好同步。否则你会看到明明用了单线程池顺序还是乱的——问题不在执行而在提交入口。3.2 多线程线程池用 Future.get 当接力棒如果不想用单线程队列这个路子而是需要一个普通线程池然后让多个任务按顺序执行最可靠的是submit加getExecutorService pool Executors.newFixedThreadPool(3); Future? future1 pool.submit(() - System.out.println(T1 执行)); future1.get(); Future? future2 pool.submit(() - System.out.println(T2 执行)); future2.get(); Future? future3 pool.submit(() - System.out.println(T3 执行)); future3.get(); pool.shutdown();Future.get()是一个阻塞方法调用它后当前线程会等任务执行完成拿到结果或异常。所以future1.get()返回后才执行下一次submitT2任务不会在T1完成前被调度。这个做法和join的思路很像但好处是任务提交在线程池里线程可以被复用而且能拿到返回值和异常。3.3 别再用 execute 裸奔了很多朋友习惯用execute提交任务但它有个麻烦任务内部抛出未检查异常线程池默认只会把异常打印到控制台调用方完全感知不到。如果这个任务恰好是T1T2还在后面傻等整个流程就处在一种看起来正常实际状态错误的尴尬局面。改用submitget任务抛出的异常会被包装成ExecutionException你可以在主线程捕获记录甚至可以决定后续任务要不要继续。这在编排多步操作时极其重要。3.4 实战案例启动初始化流程我曾经做一个对接服务启动时需要完成三个步骤加载本地方案配置、从远端拉取费率表、预热本地缓存。三步之间有强依赖而且任何一步失败就不能继续。用单线程池正好合适ExecutorService bootstrapExecutor Executors.newSingleThreadExecutor(); bootstrapExecutor.execute(this::loadLocalConfig); bootstrapExecutor.execute(this::loadRemoteRate); bootstrapExecutor.execute(this::buildLocalCache);每个execute都在同一个 worker 里顺序执行省去手写Future.get的样板代码。缺点是无界队列在极端情况下会堆积大量任务所以启动流程这种有限任务还好如果是高并发的业务任务我更倾向自定义有界线程池而不是直接使用newSingleThreadExecutor。4. 用 CountDownLatch 制造两扇门让 T2 等 T1、T3 等 T24.1 三个线程已经同时启动怎么排顺序现在回到面试官更常追问的场景三个线程已经同时start()了主线程不能再用join控制靠什么我会立刻想到CountDownLatch。思路很直白T2运行后先在一扇门前等待等T1执行完开门T3在另一扇门前等待等T2执行完开门。两扇门就可以拉出T1 - T2 - T3的次序。public class SequentialWithLatch { public static void main(String[] args) throws InterruptedException { CountDownLatch t1Done new CountDownLatch(1); CountDownLatch t2Done new CountDownLatch(1); Thread t1 new Thread(() - { System.out.println(T1 执行); t1Done.countDown(); }); Thread t2 new Thread(() - { try { t1Done.await(); System.out.println(T2 执行); t2Done.countDown(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }); Thread t3 new Thread(() - { try { t2Done.await(); System.out.println(T3 执行); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }); t1.start(); t2.start(); t3.start(); } }你会发现T2、T3虽然一启动就在那等着但真正打印日志的时机被两扇门牢牢卡住。CountDownLatch初始化数量设为1代表只需要一个通知信号。t1Done.countDown()把计数减到0所有等待t1Done的线程放行。这里等待的只有T2T3等待的是另一个锁存器t2Done所以不会出现T3抢跑。4.2 为什么是两个 Latch 而不是一个有些朋友想用一个CountDownLatch(2)让T2、T3都等它归零。这样T1执行完countDown把2减成1他们还都在等T2、T3都不会放行顺序根本实现不了。真正要做的是每个先后关系配一个独立门闩T2等T1完成用一个T3等T2完成再用一个。这也是CountDownLatch名字里CountDown的含义——每件事完成就减一减到零才开门。4.3 CountDownLatch 的底层你也得懂一点CountDownLatch基于 AQSAbstractQueuedSynchronizer实现state存的是剩余计数。await()会在state ! 0时把当前线程包装成等待节点挂起countDown()调用releaseShared把state减1减到0时唤醒所有等待线程。这属于共享锁的释放逻辑。理解这一点之后你至少能回答为什么 CountDownLatch 不能复用——计数减到0以后就永久打开不像CyclicBarrier可以循环使用。4.4 异常处理忘记 countDown 会怎么样我最想强调的是countDown()必须放在finally或确保执行路径一定走到。比如T1的任务里抛了运行时异常没有执行到countDownT2会一直卡在await()上整个流程直接死等。所以稳妥写法是try { // 真正的业务逻辑 } finally { t1Done.countDown(); }甚至更保险的是用await(3, TimeUnit.SECONDS)这种带超时的等待避免把等待变成永久阻塞。我在真实项目里的习惯是只要能设置超时就不要用无限等待因为你永远不知道依赖的那个线程哪天会挂掉。4.5 为什么不太建议用 CyclicBarrier有人会问CyclicBarrier也是让线程等待能不能用它它和CountDownLatch侧重点不同。CyclicBarrier的语义是多个线程互相等待直到所有线程都到达同一个屏障点然后一起放行更适合并行跑步前所有人一起站在起跑线这种场景。如果硬要用它来排T1、T2、T3顺序你要设计多个屏障并让不同线程在不同轮次等待代码会绕很多。顺序编排这种前一个完成放行下一个的场景CountDownLatch更加直观。5. 更高阶的操作Semaphore 和 Lock/Condition 手动信号传递5.1 Semaphore把允许执行当成许可证发放Semaphore天生适合控制访问许可。顺序执行也可以看成只有拿到许可证的线程才能继续。我们可以把许可证数量初始化为0表示一开始谁都不许过T1执行完发放一张许可证给后面的人T2拿到许可证后执行执行完再给T3发一张。Semaphore s2 new Semaphore(0); Semaphore s3 new Semaphore(0); Thread t1 new Thread(() - { System.out.println(T1 执行); s2.release(); }); Thread t2 new Thread(() - { try { s2.acquire(); System.out.println(T2 执行); s3.release(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }); Thread t3 new Thread(() - { try { s3.acquire(); System.out.println(T3 执行); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } });信号量的内部计数就是许可证数量。初始化0acquire()时发现没有许可证就阻塞release()时许可证加1唤醒等待的线程。这和CountDownLatch的思路很像但Semaphore更灵活许可证可以重复发放还能同时放行多个线程。如果某个阶段需要允许最多两个线程并行比如T2和T3在一定条件下同时跑信号量也能轻松支持。5.2 Lock Condition一个状态变量撑起完整流水线如果任务不止一轮而是多个线程循环交替执行不同阶段用多个锁存器或者信号量会很难维护。这时候我倾向用一把ReentrantLock加一个Condition再加一个state状态变量做一个简单的状态机。class SequentialWorker { private final ReentrantLock lock new ReentrantLock(); private final Condition condition lock.newCondition(); private int state 1; public void execute(int expectedState, Runnable task, int nextState) { lock.lock(); try { while (state ! expectedState) { condition.await(); } task.run(); state nextState; condition.signalAll(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { lock.unlock(); } } }然后让三个线程分别调用SequentialWorker worker new SequentialWorker(); Thread t1 new Thread(() - worker.execute(1, () - System.out.println(T1 执行), 2)); Thread t2 new Thread(() - worker.execute(2, () - System.out.println(T2 执行), 3)); Thread t3 new Thread(() - worker.execute(3, () - System.out.println(T3 执行), 4)); t1.start(); t2.start(); t3.start();三个线程同时启动但由于state初始为1只有T1的条件满足T2、T3会进入condition.await()挂起。T1执行完把state改成2并signalAll唤醒所有等待线程T2醒过来发现state 2于是继续执行。这里务必用while而不是if去检查状态因为多线程环境下存在虚假唤醒即使没有signal等待线程也可能被唤醒。用while重新检查条件才是正确姿势。5.3 锁内执行任务的代价和优化思路上面这个例子我为了让代码好理解把task.run()放到了持锁状态下执行。这在任务非常快的时候没问题但如果任务内部有网络请求、等待 IO就会导致锁持有时间过长其他线程即使状态已满足也没法进入。更合理的设计是锁内只判断和更新状态真正执行任务放到锁外。public void execute(int expectedState, Runnable task, int nextState) { lock.lock(); try { while (state ! expectedState) { condition.await(); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } finally { lock.unlock(); } task.run(); lock.lock(); try { state nextState; condition.signalAll(); } finally { lock.unlock(); } }这个版本更符合实际场景不过对并发初学者来说先掌握锁内版本也没问题重点是理解状态转移和等待唤醒机制。5.4 关于 Semaphore 和 Condition 的常见死锁用信号量时最常见的坑是把许可证数量当成线程数初始化。比如你误写成new Semaphore(1)T2第一次acquire确实能拿到许可直接就跑了顺序根本控制不住。初始值0才代表不放行直到有人发许可。还有用Lock做状态机时signalAll和await的顺序不能反必须在持锁状态下调用否则会丢唤醒信号。这些细节不踩一遍不会长记性我基本全部踩过。6. Java 异步时代的解法CompletableFuture 链式编排6.1 thenRun 天然自带顺序依赖如果你的项目已经用Java 8以上我强烈建议直接考虑CompletableFuture。它把任务A完成后执行BB完成后执行C这种依赖关系写成了链式调用不需要手动创建线程对象也不需要在主线程阻塞等待。CompletableFuture.runAsync(() - System.out.println(T1 执行)) .thenRun(() - System.out.println(T2 执行)) .thenRun(() - System.out.println(T3 执行)) .join();逻辑非常清楚runAsync异步执行第一个任务thenRun注册一个回调等第一个任务完成后在同一线程池线程或者按规则选的线程上继续执行。链路最后一个join()是为了让主线程等待整条链路完成特别是在写测试用例时不加这个join主线程可能先结束了日志还没打出来。6.2 多个线程已经启动怎么用 CompletableFuture 替代 CountDownLatch也许你会问如果T1、T2、T3是三个已有的Thread还能用CompletableFuture吗当然可以把他们的执行结果包装成CompletableFuture即可CompletableFutureVoid f1 CompletableFuture.runAsync(() - System.out.println(T1 执行)); CompletableFutureVoid f2 f1.thenRun(() - System.out.println(T2 执行)); CompletableFutureVoid f3 f2.thenRun(() - System.out.println(T3 执行)); f3.join();这种方式比手动维护CountDownLatch更符合现代代码风格尤其是在处理异常时CompletableFuture提供了exceptionally、handle等方法能在链路任意一步挂掉时优雅降级。6.3 默认线程池的坑commonPool 和自定义 ExecutorCompletableFuture.runAsync如果没传执行器默认使用ForkJoinPool.commonPool()。这个线程池是所有CompletableFuture共用的如果我在里面跑的T1任务里有Thread.sleep或阻塞式IO会占用公共线程。高并发场景下其他不相关的异步任务都会被拖累。所以工程上我通常会传入自定义线程池ExecutorService bizExecutor Executors.newFixedThreadPool(4); CompletableFuture.runAsync(() - System.out.println(T1 执行), bizExecutor) .thenRunAsync(() - System.out.println(T2 执行), bizExecutor) .thenRunAsync(() - System.out.println(T3 执行), bizExecutor) .join();注意这里thenRun和thenRunAsync的区别前者默认在任务完成线程上继续执行后者会重新提交到指定线程池。如果链路里某个阶段需要切换线程用thenRunAsync更合理。6.4 虚拟线程时代顺序控制怎么办Java 21 推出了虚拟线程Virtual Threads很多人误以为有了虚拟线程同步代码就不再需要这些顺序控制了。虚拟线程确实把线程创建成本降到极低启动大量任务代价很小但它解决的只是线程够不够用的问题不是任务依赖顺序的问题。Thread.ofVirtual()启动后照样可以用join、CountDownLatch或CompletableFuture来控制先后。虚拟线程让阻塞变便宜但不会自动帮你完成编排。我在做Java 21项目时依然照常使用CompletableFuture做依赖链只是底层执行器换成了虚拟线程池。7. 别踩这些坑Thread.sleep 排序、死等和异常吞噬7.1 Thread.sleep 排序为什么必挂这是我开篇就想声讨的写法。很多人为了图省事写了类似t1.start(); Thread.sleep(100); t2.start(); Thread.sleep(100); t3.start();。表面上日志顺序像是T1、T2、T3实际完全取决于T1能不能在100毫秒内跑完。一旦T1内部逻辑多了一步查询或者GC停顿发生T2就会抢先输出。这种代码在演示demo里运气好能过丢到生产环境是灾难。顺序控制一定不能依赖估算时间而要靠明确的通知/阻塞机制。7.2 异常吞噬顺序中断的最隐蔽原因不管是join也好、CountDownLatch也好只要前一个任务内部抛出未处理异常后一个任务就可能在不知情的情况下一直等待。尤其是用了ExecutorService.execute时异常被线程池吞掉日志里可能只飘一行堆栈主流程完全不知道。我建议在编排顺序任务时从入口就把异常通过Future、CompletableFuture或try/finally显式暴露出来并且给所有等待操作加上超时。哪怕只是await(5, TimeUnit.SECONDS)也能防止一个线程卡死拖垮全链路。7.3 最终选型建议按场景挑面对不同需求方案选择可以参考下表主线程一次性串行启动任务少Thread.join需要线程复用、任务多且排队执行单线程线程池需要线程池多线程执行但仍要顺序submitFuture.get三个线程已经并发启动需要同步信号两个CountDownLatch或Semaphore多轮循环交替执行任务间有状态依赖LockCondition状态机异步链路编排、代码可读性优先CompletableFuture没有哪个方案是银弹。join最简单但不利于复用CountDownLatch清晰但只能一次性用CompletableFuture优雅但要注意默认线程池。真的回答面试题时我会先抛出需要确认是串行提交还是并发约束这个点再按场景给对应方案最后提一句各自底层是wait/notify还是 AQS这样基本能说服面试官你是真懂而不是背答案。7.4 我个人在项目里的默认选择现在我写业务代码遇到顺序依赖第一选择通常是CompletableFuture。因为它把依赖关系表达得最直白看得懂的同事也最多。真要处理那种已经存在的线程才会用CountDownLatch。至于LockCondition我会把它留到复杂的多阶段流水线里毕竟状态机一旦引入维护成本就上来了。最后分享一个写代码的小习惯所有阻塞等待我都会带超时参数并明确记录日志。线程顺序执行这件事最怕的不是控制不住而是控制不住后还不自知。给等待加上期限让问题在第一时间暴露比什么都重要。