1. 先想清楚Java线程到底难在哪聊到Java线程很多人第一反应是“不就是new Thread().start()吗”确实能用起来不难但要说真正吃透尤其是在高并发场景下不翻车你一定得跨过三个坎。第一个坎是线程安全。这不是语法问题而是内存模型问题。多个线程同时访问一个变量为什么有时候结果是错的为什么加了volatile还是会有问题为什么synchronized能解决问题但性能又让人纠结第二个坎是协作机制。线程之间怎么有序配合wait/notify怎么用才不踩坑CompletableFuture的编排能力怎么释放出来第三个坎是资源管控。线程不是廉价资源谁创建、谁关闭、谁负责兜底线程池的核心参数到底怎么配这些决定了你的系统在流量峰值时是优雅降级还是直接宕机。这篇文章没有教科书式的开头也没有大而全的目录我是以一个在实际项目里踩过不少线程的坑、一步步把并发性能抠出来的开发者视角把Java线程进阶路上最值得琢磨的机制、最实用的代码模式、最抓狂的问题排查经验一次讲透。这里不会重复讲“进程和线程的区别是什么”“怎么继承Thread类”这种入门一百遍的内容。默认你已经写过多线程程序能跑过synchronized见过ConcurrentHashMap。我们聊的是在这之后的那些事内存语义、无锁并发、线程池参数背后真正的决策逻辑、线上问题怎么定位。适合谁看想从“会用线程”往“会设计并发”迈一步的开发正在刷面试题想搞清楚底层原理的求职者以及在线上被诡异并发Bug折磨过的人。看完之后带走的不是零散的知识点而是一套完整的并发编程方法论。2. 线程安全的三层防线从内存模型到锁机制2.1 可见性、原子性、有序性——并发Bug的三座大山并发问题千奇百怪但归根结底就是三个底层问题可见性、原子性、有序性。这三个问题都源于现代CPU的多级缓存架构和处理器的乱序执行优化。可见性的意思是一个线程修改了变量另一个线程什么时候能看到在多核CPU上每个核心都有自己的缓存。线程A在核心1上修改了变量x的值数据可能还停留在核心1的缓存里核心2上的线程B读到的仍然是旧值。这就是可见性问题。我用一个生活化的场景来解释你和室友约好谁先回家就把冰箱里的西瓜切了。你在楼下买完菜回家切了西瓜但你室友一直在客厅看电视他不知道你回来过因为你们没有“沟通机制”——他看到的还是“西瓜没切”这个旧状态。线程之间的沟通机制叫内存屏障锁和volatile底层都依赖它。原子性的意思是一组操作要么全部执行要么全部不执行中间不能被插入。比如经典的i操作看起来是一行代码但底层是三条指令读i的值、计算i1、写回i。两个线程同时执行i就可能出现都读到旧值、都加1、最终只增加1的结果。这就是原子性问题。有序性的意思是编译器为了提高性能会对指令进行重排序。在单线程环境下重排序不影响最终结果因为处理器会保证单线程程序的执行结果和顺序执行一致这叫as-if-serial语义。但多线程环境下一个线程的写操作被重排序到后面另一个线程就可能读到“不该看到”的中间状态。这三个问题不是孤立存在的一个并发Bug往往是它们的组合。比如经典的DCL单例模式需要volatile修饰instance就是因为new对象这个操作在多线程下既存在可见性问题又存在有序性问题——new一个对象在底层是多个步骤分配内存、初始化对象、将引用指向内存。如果发生指令重排序可能出现“引用已经指向了一块未初始化的内存”这种中间状态。理解了这三个层面的问题再去学习解决方案就清晰了。synchronized同时解决三个问题重量级但万无一失volatile只解决可见性和有序性不解决原子性Lock则是一把精确可控的锁支持超时、可中断等高级能力。2.2 volatile的底层到底做了什么volatile可能是Java并发中最被低估也最容易被误用的关键字。很多人知道volatile能保证可见性但不知道为什么能保证知道它不能保证原子性但不知道什么时候能用它。来看volatile的底层实现。在JVM层面volatile变量的读写操作会被翻译成带内存屏障的指令。具体来说写volatile变量时JVM会在写操作前后插入StoreStore屏障和StoreLoad屏障强制将写缓冲区的数据刷新到主内存读volatile变量时会插入LoadLoad屏障和LoadStore屏障强制从主内存重新读取数据。实际上这些屏障做的事情就是禁止屏障两侧的指令重排序同时保证写完后立即对其他线程可见。这就是volatile能保证可见性和有序性的原理。那volatile适用什么场景呢最典型的就是状态标记位public class Worker { private volatile boolean running true; public void stop() { running false; } public void run() { while (running) { // 处理业务 } } }这个场景非常经典。一个线程负责执行业务循环另一个线程需要停止它。如果不加volatile主线程把running改成false工作线程可能永远看不到因为它在自己的CPU缓存里读到的是旧值。加了volatile每次循环都会强制从主内存重新读取running停止操作立竿见影。还有一个场景是双重检查锁定的单例模式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(); // volatile是关键 } } } return instance; } }这里的volatile核心作用是禁止new Singleton()这个操作被重排序。如果你去掉volatile可能发生这样的情况线程A进入同步块执行new Singleton()在“分配内存”和“对象引用指向内存”两步完成之后、“对象初始化”完成之前由于重排序引用已经非空了。此时线程B进来第一次检查发现instance非空直接返回了一个还没初始化完成的对象使用时就会出问题。使用volatile最关键的一条经验当你不知道该不该用volatile时大概率不该用。这个事的判断标准是这个变量的状态是否完全取决于最近一次写入是否不存在“读-修改-写”这种复合操作如果是volatile就可以用如果存在复合操作比如累加、比较再交换你需要的其实是原子类或者锁。2.3 synchronized的进阶用法别在用错了synchronized是线程安全的兜底手段。但进阶开发者的区别在于知道synchronized的锁升级过程并能利用它写出更高效、更安全的代码。JDK 6之后synchronized锁有四个状态无锁、偏向锁、轻量级锁、重量级锁。锁只能升级不能降级。这个设计背后是一个真实观察大多数锁竞争并不激烈甚至很多锁只有一个线程在获取。锁升级的大致流程是偏向锁当一个线程第一次获取锁时JVM会在对象头里记录这个线程的ID。之后这个线程再次获取锁就不需要做同步操作了直接进入。这叫“如果锁大概率只有一个线程在用那就偏向它”。轻量级锁当另一个线程尝试获取偏向锁时偏向锁会撤销并升级为轻量级锁。轻量级锁通过CAS自旋来获取锁如果自旋几次能拿到锁就不需要进入内核态。重量级锁如果自旋失败锁会升级为重量级锁此时线程会进入阻塞状态等待操作系统的调度。这个升级过程对开发者的启示是锁的竞争越少synchronized的性能越好。因此尽一切可能缩小临界区范围让锁里的代码尽量短、尽量快。这比换用Lock甚至换成无锁代码的收益都更大。还有一个进阶技巧是锁粒度分离。比如一个类同时有读操作和写操作如果用同一把锁保护所有方法读操作之间都会互相阻塞。更聪明的做法是读写锁分离ReentrantReadWriteLock或者对数据进行分段锁。Java 8的ConcurrentHashMap就是分段锁思想的极致体现——它把Map分成多个桶每个桶有自己的锁实际上是CAS和synchronized的组合不同线程操作不同桶就不至于互相阻塞。synchronized有一个容易被忽视的细节锁对象的选择。锁一个class对象和锁一个实例对象的范围完全不同。静态方法上的synchronized锁的是Class对象实例方法上的synchronized锁的是this对象。如果方法之间锁的对象不一致就会存在“锁了个寂寞”的问题——两个线程表面上都用了synchronized实际上各锁各的完全没互斥。给一个实际建议优先考虑用锁对象而不是this或Class。明确新建一个Object对象专门作锁public class Counter { private final Object lock new Object(); private int count; public void increment() { synchronized (lock) { count; } } }这样做的最大好处是锁定意图清晰而且避免类被继承时锁对象错乱的问题。很多人写代码类被继承了、方法被重写了synchronized的锁对象压根对不上排查起来极其痛苦。2.4 从wait/notify到CompletableFuture线程协作的正确姿势线程协作最古老的姿势是wait/notify这也是面试爱考的。但实际上我在业务代码里已经很少直接写wait/notify了——它有一大堆潜规则用错了会在线上出各种诡异的卡死问题。先说说wait/notify的核心规则这部分面试必问你也必须理解清楚wait和notify必须在synchronized代码块内调用否则抛IllegalMonitorStateException。wait会释放锁并让出CPU进入等待状态notify会随机唤醒一个等待线程notifyAll会唤醒所有等待线程。wait可以带超时时间超时后自动醒来。这里有个常见的坑wait必须放在while循环里而不是if条件里。因为wait被唤醒后不能保证唤醒它的线程所在的业务条件真的满足了可能是被其他线程“顺便”唤醒的。如果用的是if唤醒后会继续往下走这时候业务条件可能根本不满足就会出错。用while的好处是醒来后重新检查条件不满足就继续等待。这就是所谓的“虚假唤醒”问题。synchronized (queue) { while (queue.isEmpty()) { queue.wait(); } // 取出元素 }不过在真实业务中我更推荐用JUC包中更现代的协作工具来取代wait/notify。自Java 5开始JUC包提供了三种信号协作机制CountDownLatch主线程等待N个子线程完成。它的适用场景是“bang所有人都准备好了一起开始”或“等着所有人都结束后再汇总”。CountDownLatch latch new CountDownLatch(3); // 三个子线程各完成一个任务 for (int i 0; i 3; i) { new Thread(() - { // 执行业务 latch.countDown(); }).start(); } // 主线程等待3个子任务完成 latch.await(5, TimeUnit.SECONDS); // 继续后续Semaphore限流信号量。它的适用场景是“控制一批资源只能同时被N个线程使用”比如数据库连接池、文件句柄池的访问控制。Semaphore semaphore new Semaphore(5); for (int i 0; i 100; i) { semaphore.acquire(); try { // 最多5个线程同时进入 } finally { semaphore.release(); } }CyclicBarrierN个线程互相等待等所有人到达后一起继续然后栅栏重置。它和CountDownLatch的区别在于CountDownLatch是一次性的CyclicBarrier是可循环使用的。比这些传统工具更能解放生产力的是Java 8引入的CompletableFuture。它的设计目标是解决复杂异步编排的问题让“等一个结果后再计算另一个结果”这种流程从手工创建线程、加锁、传递结果的痛苦模式中解脱出来。举个例子我有三个服务需要并行调用然后汇总三个结果CompletableFutureString f1 CompletableFuture.supplyAsync(() - service1.call()); CompletableFutureString f2 CompletableFuture.supplyAsync(() - service2.call()); CompletableFutureString f3 CompletableFuture.supplyAsync(() - service3.call()); String result CompletableFuture.allOf(f1, f2, f3) .thenApply(v - f1.join() f2.join() f3.join()) .get(5, TimeUnit.SECONDS);这种编排方式传统写法需要你手动管理三个线程、三个FutureTask、一组waitNotifying写出来至少三倍长的代码。CompletableFuture的另一大优势是链式异常处理exceptionally、handle这些方法可以把异常处理直接嵌入到异步链路里不用在多个线程里分别捕获再手动传递异常。实操中的一条经验CompletableFuture要指定自定义线程池不要用默认的ForkJoinPool.commonPool()。默认线程池的线程数等于CPU核数减一在高IO密集型业务中是严重不足的。用完全局共用的默认线程池轻则线程池耗尽重则把系统中其他用到了commonPool的地方也拖下水。ExecutorService executor new ThreadPoolExecutor( 8, 16, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(200), new NamedThreadFactory(async-task), new ThreadPoolExecutor.CallerRunsPolicy() ); CompletableFuture.supplyAsync(() - service.call(), executor);3. 线程池从会用参数到真正懂得设计3.1 七大参数的底层逻辑线程池是新晋开发者最需要花时间吃透的东西。面试经常问“线程池有哪些参数”但真正重要的不是背出七个参数的名字而是理解参数之间如何互相影响以及在什么业务场景下该怎么配。线程池的七个参数是核心线程数、最大线程数、空闲线程存活时间、时间单位、任务队列、线程工厂、拒绝策略。我一直把线程池的运作类比成一家餐厅核心线程数长期聘用的稳定员工。只要餐厅开门这些员工就在岗。任务队列门口等待的叫号排队区。连着客人多时先让客人在排队区等着。最大线程数餐厅最多能临时雇多少员工。排队区满了还不能消化客流时就得临时招人。空闲线程存活时间临时工多久没活干就会被辞退。核心员工不会被辞临时工会。拒绝策略排队区满了、临时工也招满了再来客人怎么办——是拒单、让顾客自己找别的店还是店长自己出来做服务这个类比能帮你理解一个很关键的设计原则任务队列和最大线程数是如何配合的决定了系统的行为模式。处理流程是这样的新任务来了先看核心线程有没有空余有空直接执行没空就丢进任务队列队列满了再看线程数有没有达到最大线程数没达到就创建额外线程处理达到最大了还收不下就触发拒绝策略。这里有一个非常反直觉的细节不是先扩线程再排队而是先排队再扩线程。这个设计的意图是宁愿让任务在队列里等一下也不轻易创建额外的线程。因为线程的创建和销毁是有代价的操作系统维护线程的上下文切换也有代价。大多数系统里任务的到达率是有波动的如果一超出核心线程数就疯狂新建线程很快系统就会因为线程过多导致上下文切换开销巨大、内存吃紧从而性能急剧下降。3.2 三种任务队列和四种拒绝策略任务队列的选型决定了线程池的排队行为。最常用的有三种ArrayBlockingQueue有界数组队列FIFO。你给它一个容量满了就必须走“扩线程”之路。这是最常用的队列类型因为它有界——意味着系统行为是确定的不会无限积累任务导致OOM。LinkedBlockingQueue链表队列默认无限容量。如果不加容量上限队列永远不会满那么最大线程数这个参数就失效了——永远用不到额外线程任务全堵在队列里。这在任务量突然暴增时非常危险因为无限增长的任务最终会耗尽内存。SynchronousQueue不存任务直接交给线程执行的队列。它不是真正意义上的队列里面永远最多一个元素。任务提交进来必须有空闲线程立刻接住接不住就直接触发扩线程。相当于把排队区去掉了。选型原则很简单如果你的核心业务是搜索、计算这种耗时可控的任务用有界ArrayBlockingQueue配合合理的容量如果是典型的生产者-消费者模型偏IO任务用有界LinkedBlockingQueue也行如果不希望任务有任何排队延迟用SynchronousQueue但那需要把最大线程数配得足够大。拒绝策略有四种不同的策略对应线上不同的行为策略行为适用场景AbortPolicy直接抛异常RejectedExecutionException默认策略任务丢失要快速抛错提醒CallerRunsPolicy让提交任务的线程自己跑这个任务不希望任务丢失且允许调用方降速DiscardPolicy静默丢弃任务不抛任何异常可以接受任务丢失的场合不推荐DiscardOldestPolicy丢弃队列中最旧的任务然后重试提交追求“新任务优先于旧任务”的场景我的选择习惯是业务系统里优先用CallerRunsPolicy。因为它的语义是“任务不能丢但可以慢一点”——提交任务的线程自己不提交了改为执行任务相当于一个反向压力阀。流量暴增时系统会天然变慢但不会因为线程池拒绝而丢数据。代价是如果主线程本来要等这个异步结果的极端情况下主线程会被拖住。所以也要评估提交线程的性质。3.3 核心线程数和最大线程数到底怎么配这是线程池最核心的问题也是骚操作最多的地方。网上的说法总是“CPU密集型的线程数 CPU核数 1IO密集型 CPU核数 * 2”。但这句话在实际场景中太粗了甚至经常是错的。更合理的计算思路是基于CPU密集度和阻塞率的动态公式。理论公式是线程数 CPU核数 / (1 - 阻塞系数)其中阻塞系数是指线程在等待IO完成的时间比例。纯CPU计算任务阻塞系数趋近于0线程数接近CPU核数阻塞系数0.5一半时间在等待线程数就是核数×2阻塞系数0.8线程数就是核数×5。为什么IO密集型需要更多线程因为线程在等IO响应时是不占CPU的这段时间CPU是空闲的。多出来的线程正好利用这些空闲时间去执行其他任务。但如果阻塞系数很高又配了极多线程线程间的上下文切换成本又会吃掉多余的收益。所以这是一个需要动态权衡的过程。实际配置时我一般按以下步骤先明确场景这个线程池服务的任务是CPU计算多、IO等待多、还是纯粹的业务编排IO等待包括网络调用、磁盘读写、数据库查询找到核心瓶颈如果是压测看CPU使用率和线程等待时长分布。如果CPU使用率已经90%以上说明线程数差不多到头了如果CPU闲置但线程等待过长说明可以加线程。设置合理队列队列容量按“高峰时期最多积压多少任务”来估算。比如你预期高峰时每秒来100个任务每个任务处理耗时200ms那你至少需要一个能装下20个任务的队列才能支撑1秒内的积压还得乘上冗余系数。测试再校正任何公式都只是起点。最好的办法是建立一个带压测的测试环境用QPS、响应时间、线程池任务的排队延迟这些真实指标来反向微调参数。给一个我常用的初始模板场景异步处理消息IO密集型ThreadPoolExecutor executor new ThreadPoolExecutor( 8, // 核心线程数CPU核数 × 2 32, // 最大线程数核心 × 4允许峰值 60L, TimeUnit.SECONDS, // 非核心线程空闲回收时间 new ArrayBlockingQueue(200), // 有界队列 Executors.defaultThreadFactory(), new ThreadPoolExecutor.CallerRunsPolicy() );注意我强烈不建议用Executors类提供的几个快捷方法。newFixedThreadPool用的是无界LinkedBlockingQueue——队列无限大撑到OOM。newCachedThreadPool用的是SynchronousQueue最大线程数是Integer.MAX_VALUE——理论上可以创建无限多个线程迟早把内存打爆。newScheduledThreadPool同样是无界队列。这些快捷方法写起来省事但线上生产环境禁用它已经是Java开发社区的基本共识。3.4 一个消息批处理线程池的完整配置案例纸上谈兵结束给一个我实际项目里面的案例。业务场景是系统里会不断产生一批待处理消息每个消息需要外部调用一个接口做风控校验IO密集然后把结果落库。接口的响应时间是平均150ms峰值可能到500ms。系统每秒新增消息量平稳时50条活动期间峰值能到300条。我当时的线程池配置是private ThreadPoolExecutor buildRiskCheckExecutor() { int corePoolSize Runtime.getRuntime().availableProcessors() * 2; // 假设8核则16 int maxPoolSize corePoolSize * 2; // 32 long keepAliveTime 60L; BlockingQueueRunnable queue new ArrayBlockingQueue(500); ThreadFactory threadFactory new ThreadFactoryBuilder() .setNameFormat(risk-check-pool-%d) .build(); ThreadPoolExecutor executor new ThreadPoolExecutor( corePoolSize, maxPoolSize, keepAliveTime, TimeUnit.SECONDS, queue, threadFactory, new ThreadPoolExecutor.CallerRunsPolicy()); executor.allowCoreThreadTimeOut(true); return executor; }几个关键决策的解释核心线程数设为核数×2因为这是IO密集型场景阻塞系数大约0.7-0.8线程数应该大约等于核数/(1-0.75)≈4倍核数。但核心线程不需要一开始就撑这么大否则大量时间线程都在空转。所以核心线程设成核数×2峰值靠最大线程数去扛。队列500这个数字的考虑是峰值QPS是300每批任务平均响应150ms因此在最坏情况下1秒钟会积压300×(10.33)个任务 ≈ 400。500刚好能遮住峰值波动且不会积压过久。allowCoreThreadTimeOut(true)让核心线程也能在空闲时回收。这个配置意味着系统低峰期不需要维持16个空转线程线程数可以降到0。这是个很实用的配置但有一个前提你会接受“任务到来时临时创建线程有初始化延迟”这件事。CallerRunsPolicy风控校验不能丢丢了消息就漏风控了。宁可让提交线程自己跑拖慢主流程也不能放弃检测。配完之后我对这个线程池做了压测。用并发100个线程持续提交任务观察三个指标P99响应时间、线程池活跃线程数、队列积压数。经过三组参数调整后P99从最初的780ms降到了410ms接近单次接口调用的P99说明线程池已经不再是瓶颈。这就是调优要追求的目标——把线程池引起的额外延迟压缩到足够小。4. 实操从零搭建一个订单超时自动关闭系统这一节我带着你实现一个完整的并发案例订单超时自动关闭。这个需求很常见用户下单但没付款需要系统在超过一定时间比如30分钟后自动把订单关掉。这类需求看起来简单但实现方式里藏了很多并发水平的考察点。4.1 方案演进从定时扫描到延迟队列实现订单超时关闭最朴素的方案是定时全表扫描每30秒扫描一次订单表把超过30分钟未付款的订单关闭。这个方案的缺点是扫描的数据量大、高频执行成本高、时间精确度低。订单可能已经超时了29秒才被扫描到也可能刚好被漏掉极端情况体验不好。进阶方案是使用延迟队列的思想每个订单提交时设定它“什么时候到期”然后由一个调度机制在到期时执行关闭操作。在Java生态里实现延迟队列有三种主流方案ScheduledExecutorService的schedule()提交一个延时任务线程池到时自动执行。简单、内建。DelayQueue一个无界的延迟阻塞队列元素要实现了Delayed接口。多个消费者线程可以同时从队列里取到期元素。消息中间件延时消息比如RabbitMQ延迟队列或者基于时间轮的组件适合分布式场景。单机场景下优先级最高的是DelayQueue或者ScheduledExecutorService。特别是DelayQueue它的数据结构就是一个基于优先队列的延时队列底层由PriorityQueue实现堆顶是最早到期的元素每次take()会阻塞直到堆顶元素到期。4.2 结合WatchDog与DelayQueue的完整实现我直接给出一个结合DelayQueue和监控线程池的完整设计方案。核心思路是每个订单封装成一个Delayed元素delay时间设为30分钟。一个专门的消费者线程循环从DelayQueue里取到期订单取到就执行关闭逻辑。关闭逻辑必须幂等查询订单状态只有“待支付”状态的订单才能被关闭防并发重复操作。用一个带名字的、单独的线程池来处理关闭逻辑避免消费者线程被慢任务拖死。配套一个周期性的扫描兜底任务防止DelayQueue丢失任务。关键代码简化版public class OrderDelayedTask implements Delayed { private final Long orderId; private final long expireTime; // 到期时间点绝对时间的毫秒值 public OrderDelayedTask(Long orderId, long delayMillis) { this.orderId orderId; this.expireTime System.currentTimeMillis() delayMillis; } Override public long getDelay(TimeUnit unit) { long diff expireTime - System.currentTimeMillis(); return unit.convert(diff, TimeUnit.MILLISECONDS); } Override public int compareTo(Delayed other) { if (other this) return 0; long diff this.getDelay(TimeUnit.MILLISECONDS) - other.getDelay(TimeUnit.MILLISECONDS); return diff 0 ? 0 : (diff 0 ? -1 : 1); } }然后建一个专门的延迟队列和消费者DelayQueueOrderDelayedTask delayQueue new DelayQueue(); ExecutorService closePool new ThreadPoolExecutor( 4, 8, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(100), new ThreadFactoryBuilder().setNameFormat(order-close-%d).build() ); // 消费者线程持续取到期订单 Thread consumer new Thread(() - { while (!Thread.currentThread().isInterrupted()) { try { OrderDelayedTask task delayQueue.take(); // 阻塞直到有任务到期 closePool.execute(() - closeOrder(task.getOrderId())); } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } }, order-delay-consumer); consumer.start();closeOrder方法一定要设计成幂等的这是最容易踩的坑。因为网络异常、任务重试、消费者重启都可能导致同一个订单的关闭操作被执行两次。所以关闭一定要有状态检查public void closeOrder(Long orderId) { Order order orderService.getById(orderId); if (order ! null PENDING_PAY.equals(order.getStatus())) { orderService.updateStatus(orderId, CLOSED); // 可加发送消息通知用户 } }这个方案有几个优点不需要高频轮询数据库到期订单的取出是精确定时的消费者线程数是可控可调的关闭逻辑和业务代码解耦。但也有一个明显的隐患——JVM重启后DelayQueue内存中的数据全部丢失。怎么解决4.3 兜底方案启动补偿扫描、防止任务丢失DelayQueue是纯内存的数据结构订单信息一旦丢了用户不下单又没主动发现就永远没人给他关单了。这是一个线上必须处理的问题。我的兜底方案是系统启动时做一次全量补偿扫描。在应用启动完成后扫描订单表中所有“待支付”状态且“创建时间超过30分钟”的订单将其重新入队或直接关闭。Component public class OrderCompensateTask implements ApplicationRunner { Override public void run(ApplicationArguments args) { // 启动后5秒执行防止阻塞主流程 ScheduleExecutorService executor Executors.newSingleThreadScheduledExecutor(); executor.schedule(() - { ListOrder expiredOrders orderMapper.selectExpiredOrders(30); expiredOrders.forEach(order - closeOrder(order.getId())); }, 5, TimeUnit.SECONDS); executor.shutdown(); } }这个方案的成本很低只在启动时执行一次全量扫描但能有效防止重启导致的任务丢失。还有一种做法是每次订单创建时同时把任务信息落库比如存一个delay_queue表然后由后台任务从表里读任务放入内存队列。但那样引入了数据库轮询复杂度上去了不少。单机场景下我通常选择“内存队列启动补偿扫描”的组合简单且可靠。还有一个运营层面的细节关闭时间怎么算。“30分钟未付款”的计时应该是从下单时间开始算而不是从任务创建时间开始算。这个看起来像废话但很多人实现时用的是“new一个任务后的30分钟”在下单到成功创建任务之间如果隔了网络延迟、服务重启计时起点就不对了。我习惯在业务里直接记下订单的期望关闭时间点下单时间30分钟任务到期时用当前时间和期望关闭时间做对比如果还没到就重新计算剩余延迟再次入队如果已经超了直接关闭。这种“懒处理”方式能天然容忍任务被延迟执行的情况。最后说一句线程安全的细节DelayQueue本身是线程安全的可以放心让多个线程同时take。但如果订单状态被并发修改比如用户刚好在超时那一刻点了支付closeOrder和支付操作同时发生时一定要在数据库层面做状态条件更新而不是先查后改——先查后改这种“读-改-写”的操作天然会产生竞态。正确做法是SQL里带条件UPDATE order SET status CLOSED WHERE id #{id} AND status PENDING_PAY受影响行数为1表示更新成功0表示订单状态已经被别人改了直接忽略即可。这种条件更新是并发编程中最省力又最可靠的一招。5. 常见问题与排查技巧实录5.1 CPU飙高线程池配置不当的典型表现线上服务的CPU突然飙到接近100%这是并发系统最常见的告警之一。很多人第一反应是看业务代码有没有死循环但线程池配置不当同样会导致这个问题。最常见的场景线程池的核心线程数设得太大而且系统长期处于高水位以下一点点。假如系统QPS只需要40就能处理完整但你配了64个线程每个任务本身很快线程却在反复上下文切换中把CPU打满了。另一个经典场景是最大线程数设得很大任务队列也不够用导致大量线程疯狂自旋、切换CPU空转严重。排查步骤可以这样第一步top -Hp pid找CPU最高的线程ID把它转成十六进制printf 0x%x\n threadId。第二步jstack pid | grep -A 20 0x线程id看这个线程在干什么。如果发现大量线程都在执行AQS的acquireQueued方法LockSupport.park或者都在某个队列的take()上阻塞但CPU又很高往往说明线程数已经超过了系统能有效处理的数量线程在反复地park和unpark之间切换。第三步用jstat -gcutil pid 1000看GC是否频繁。如果Full GC频繁会导致所有线程短暂停顿后继续跑也会表现为CPU高。但GC问题多数时候和并发设计关系不大更多是内存使用策略问题。实操中我还遇到过一种真实案例某跨平台系统使用了无界的LinkedBlockingQueue消息生产速度大于消费速度任务越堆越多消费线程被迫处理大量积压任务CPU一点点被打满。这种情况需要做的不是压线程数而是引入有界队列加兜底丢弃靠“背压”机制让生产者降低速度。这也是我把Executors快捷方法称为“生产禁用”的原因。5.2 死锁用jstack一次定位死锁问题我通称为“并发系统最隐蔽的杀手”。两个线程各自持有一把锁还想要对方的锁结果互相等待谁也不让。这类问题不像CPU问题会有明显的性能下降它是让业务整体卡住表现是日志不更新、接口响应超时。死锁有一个好工具jstack可以直接打印出死锁信息。在死锁发生时执行jstack pid输出末尾会有一段专门的死锁检测Found one Java-level deadlock: pool-1-thread-1: waiting to lock monitor 0x... (object at 0x..., a com.example.Account) which is held by pool-1-thread-2 pool-1-thread-2: waiting to lock monitor 0x... (object at 0x..., a com.example.Account) which is held by pool-1-thread-1这个输出信息非常明确。但现实中的死锁往往不是这种一对一的简单互锁而是多个线程、多个资源交织成的环。有一次线上卡死打印出来的死锁信息涉及三个线程、三个锁代码里每个锁对应的业务场景看起来毫无关联折腾了很久才找到原来是某个共用组件在两个方法里按不同的顺序加了同一把锁。避免死锁的经验很直白锁的顺序全局一致。如果业务涉及多个锁必须定义加锁顺序比如约定先锁资源A再锁资源B。违反这个约定就有死锁风险。加锁尽量单把。能用一把锁管理的数据就不要拆两把。用tryLock带超时替代lock。ReentrantLock的tryLock(3, TimeUnit.SECONDS)会在超时后放弃等待而不是无限死等。这不会杜绝死锁但至少不会让线程永久卡死超时后可以走降级逻辑。5.3 ThreadLocal内存泄漏并发代码的隐形雷ThreadLocal是线程隔离的利器但它的内存泄漏问题在并发系统中非常常见。它的核心是每个Thread内部有一个ThreadLocalMapkey是ThreadLocal对象value是你要隔离的变量。ThreadLocalMap的Entry继承了WeakReferencekey是弱引用。这意味着如果外部对ThreadLocal对象没有强引用GC时这个ThreadLocal就会被回收但value还留在ThreadLocalMap里。如果这个线程是线程池里的线程——长期存活——那么value永远没有机会被回收内存就一点点涨上去。排查方法用jmap -dump:formatb,fileheap.hprof pid导出一份堆快照然后用分析工具看线程对象内部ThreadLocalMap里有哪些Entry的值是大对象。如果发现有大量同类的业务对象堆积在线程里基本就锁定是ThreadLocal泄漏了。解决思路有两条第一条每次用完显示调用remove()清理。这是常识中的常识但操作时要想清楚时机——必须在finally里remove因为异常发生时也要确保清理。第二条如果ThreadLocal只用于一次调用链的上下文传递优先考虑改成方法参数透传。但这个方法在某些场景下代码会很丑所以也是取舍问题。给一个健壮写法private static final ThreadLocalContext CONTEXT new ThreadLocal(); try { CONTEXT.set(buildContext(traceId, userId)); // 业务逻辑... } finally { CONTEXT.remove(); }这条规则适用于所有业务线程池中的ThreadLocal使用。我在带团队时定的规矩是ThreadLocal出现在代码评审里必须同时看到try/finally的remove否则不允许合入主干。5.4 一个问题速查表直接对着排查把上面这些经验整理成一张表方便你在实际情况中快速对照现象可能原因优先排查动作CPU高但业务QPS正常核心线程数偏大/上下文切换过多查线程数、降低核心线程数后压测CPU高且队列积压增长消费能力不足查明线程数是否够、瓶颈是否在IO等待接口超时但线程不死死锁或锁等待过长jstack看锁等待、检查加锁顺序接口整体卡住无响应死锁jstack的死锁检测段内存缓慢增长最终OOMThreadLocal泄漏/无界队列堆转储分析ThreadLocalMap和队列对象偶发变量值错误可见性或原子性问题排查是否缺少volatile/使用原子类偶发重复执行幂等设计缺失检查状态条件更新SQL这张表不是标准答案而是很多类似问题背后的共性规律。实际排查中我总是优先建议做一件事先jstack看一眼线程状态在哪里。线程快照能告诉你线程是在执行代码、阻塞在锁上、还是在等待队列这能缩小很大范围。第二个建议是如果问题间歇性出现不要手动干预先保留现场dump 堆、dump 线程再根据线索分析不要急着重启服务或者杀进程——现场一没排查难度直接翻倍。6. 进阶路上的几点心得学线程这件事我看很多人走了弯路。一个弯路是死记硬背并发相关的结论比如“volatile保证可见性不保证原子性”“线程池核心线程数怎么配”这些知识点背得滚瓜烂熟但写代码时还是不知道怎么用。我的体会是并发是计算机世界里少有的、靠直觉写几乎必然出问题的领域必须真正了解内存模型和操作系统的线程调度机制才能写出正确的并发代码。建议的方法是去读一遍JVM规范里的内存模型部分不要求背下所有happens-before规则但至少要知道为什么会有这些规则。第二个弯路是一遇到性能问题就上多线程。事实上很多业务场景单线程加上合理的批量处理已经是非常好的方案。引入多线程本质上是在用复杂性和不可预测性换取吞吐量和响应速度这是一笔交易。我在评审代码时经常提醒一个原则如果加线程不能带来明显的延迟下降或者吞吐提升就不要加因为线程的增加让系统的行为更难预测、更难排查。第三个弯路是低估了并发代码的测试成本。并发Bug有一个共同特点极难稳定复现。同一个代码片段线上偶发出问题测试环境跑一万次都不出。对付这种问题唯一的办法就是靠规范写代码——不用可疑的可见性依赖、不用可疑的顺序假设、所有共享变量的修改都通过明确的同步手段。宁可“保守”一点也不写那种靠“运气”才能正常的并发代码。我一直觉得好的并发代码长得很朴素锁用得少锁的范围清楚共享变量最少化异步编排的链路上没有隐性的竞态条件。所以如果你问我这个进阶之路下一步往哪走我的建议有两条线。一条线是向底层走去看看JMM的原始论文、AQS的内部实现、ConcurrentHashMap的扩容细节这些能让你理解框架作者为什么要这么设计。另一条线是向工程走多在真实业务里设计并发方案、做压测、总结问题排查套路。二者结合才能建立真正可靠的并发直觉。线程这个东西掌握了是工具箱里最好用的武器之一掌握不牢就是线上最头痛的谜题。希望你读完之后不是在背答案而是能设计出自己的答案。