JUC并发编程系列越写越过瘾。上一篇把并发工具的用法过了一遍很多人反馈说看API不算会想知道底层到底怎么转的。这篇“手撕JUC并发编程2”就专门干这事直接对着源码拆把AQS队列模型、ConcurrentHashMap的并发扩容、线程池的状态流转这些硬骨头一个个啃下来最后再给出一套排查线上并发问题的实战手段。这篇写的东西适合正在用Java做后端开发、读源码读到一半卡住的人也适合准备高并发面试、想搞明白“为什么这么设计”的人。你不需要把每行源码都背下来但跟着我的思路走一遍以后再看到锁、并发容器、线程池脑子里会有一条清晰的线。这篇不聊理论空话每一节都有源码片段、关键设计解读和可以直接用起来的经验。1. 先拆AQSJUC的地基JUC里一半以上的同步工具Lock、Semaphore、CountDownLatch、ReentrantLock底层都站在同一个抽象类上AbstractQueuedSynchronizer简称AQS。这个东西是并发编程绕不开的基石把它搞明白其他工具基本就是套壳。1.1 一个state字段凭什么撑起整个JUCAQS的核心设计极其精简就是三样东西一个volatile int类型的state、一个双向链表构成的等待队列、以及基于CAS的状态更新操作。所有同步逻辑都围绕这三个东西展开。state这个字段是同步状态的总开关。它表示什么含义完全由子类自己定义。ReentrantLock里state表示锁被重入的次数0代表没人持有锁1代表持有一次n代表重入了n次。Semaphore里state代表剩余许可数。CountDownLatch里state代表还没倒数完的计数。一个字段多种解释这就是AQS留给子类的设计空间。等待队列是一个CLH锁队列的变体实现每个节点是一个Node对象里面装着线程引用、等待状态waitStatus以及前驱和后继指针。它的作用很容易理解当线程拿不到锁时不会傻乎乎地自旋空转而是把自己封装成Node挂到队列尾部然后通过LockSupport.park把自己挂起。等到锁被释放时队列头部节点对应的线程再被唤醒重新参与竞争。这里有个很关键的细节AQS并不保证公平性。新来的线程可以直接和队列头部的线程一起CAS抢锁这就是非公平锁的实现基础。非公平锁的性能通常更好因为减少了一次线程挂起唤醒的开销但代价是等待队列中的线程可能被“插队”。ReentrantLock默认就是非公平模式想开启公平模式可以在构造时传入true但实际生产环境基本用不到公平锁性能差距明显。CAS操作是这一切的原子性保证。AQS里所有的状态修改比如尝试抢锁、释放锁、入队、出队都依赖Unsafe类的compareAndSet系列方法。这个机制可以简单理解成先把期望值拿出来和目标内存位置的当前值比对如果相同就写入新值整个操作在CPU指令层面是原子的。JUC并发容器的所有乐观更新靠的都是这一招。1.2 从源码角度扒ReentrantLock加锁/解锁拿ReentrantLock的非公平实现作为入口走一遍完整的lock和unlock流程这是理解AQS最直接的方式。lock的入口在ReentrantLock内部类NonfairSync里final void lock() { if (compareAndSetState(0, 1)) setExclusiveOwnerThread(Thread.currentThread()); else acquire(1); }第一次加锁时如果state刚好是0说明锁空闲CAS直接把它改成1同时把当前线程设置为独占锁的持有者。这一步成功的话整个加锁过程连队列都不用碰这也是非公平锁“快”的主要原因。如果CAS失败说明锁已经被别人持有则进入acquire流程。acquire方法在AQS里是模板方法public final void acquire(int arg) { if (!tryAcquire(arg) acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); }tryAcquire是子类实现的钩子方法。ReentrantLock的nonfairTryAcquire会再尝试一次CAS如果还是失败再看一下当前线程是不是已经持有锁的线程。如果是state累加这就是可重入功能的来源。如果既抢不到锁、也不是重入那就执行addWaiter把当前线程包装成Node通过CAS放到等待队列尾部然后进入acquireQueued自旋。acquireQueued是整个等待机制的核心。线程进入队列后会先检查自己的前驱节点是不是head。如果是就再尝试一次抢锁。抢到了就把自己设置为新的head。抢不到就检查是否需要挂起需要的话调用LockSupport.park阻塞自己。整个循环直到拿到锁才退出。注意这个逻辑每个线程被唤醒后不会直接拿锁而是必须先经历一次“前驱是head tryAcquire”的校验这样才能保证锁状态的正确转移。unlock就简单多了public final boolean release(int arg) { if (tryRelease(arg)) { Node h head; if (h ! null h.waitStatus ! 0) unparkSuccessor(h); return true; } return false; }tryRelease在ReentrantLock里会把state减1减到0表示锁完全释放同时清空独占线程。然后从head节点开始唤醒下一个等待线程。这里有个值得注意的细节head节点本身不一定是被唤醒的线程它只是一个哨兵真正的唤醒动作是找head.next如果没有或者状态异常就从头遍历到尾找第一个还能唤醒的节点。1.3 手写一个mini版AQS把逻辑串起来看完源码自己动手实现一个简化版“ReentrantLock”比看十遍源码都管用。把你的锁类定义成AQS的子类然后只实现两个方法就够tryAcquire和tryRelease。public class MiniLock { private final Sync sync new Sync(); private static class Sync extends AbstractQueuedSynchronizer { Override protected boolean tryAcquire(int arg) { int current getState(); if (compareAndSetState(0, arg)) { setExclusiveOwnerThread(Thread.currentThread()); return true; } return false; } Override protected boolean tryRelease(int arg) { int current getState(); if (current 0) { throw new IllegalMonitorStateException(); } setExclusiveOwnerThread(null); setState(current - arg); return true; } } public void lock() { sync.acquire(1); } public void unlock() { sync.release(1); } }这段代码去掉可重入逻辑只保留最核心的独占语义。执行lock时acquire会调用我们覆盖的tryAcquire拿不到锁时AQS自动帮我们完成入队、挂起、唤醒。我们自己写出来的只有两行CAS逻辑剩下排队调度全部复用AQS的骨架。把AbstractQueuedSynchronizer继承下来你会发现真正要写的代码量比想象中少得多。这正是AQS设计的精髓把同步状态的管理、线程的阻塞唤醒、队列的维护全部收敛到父类业务方只需要告诉它“什么时候算拿到锁”“什么时候算释放锁”。以后再看CountDownLatch、Semaphore的源码你会发现换汤不换药只是tryAcquire变成了tryAcquireSharedstate的含义变了而已。1.4 Condition条件队列await/signal的真面目Condition是AQS里另一个强大的内部机制很多人用ReentrantLock的newCondition创建条件变量却不太清楚await和signal背后发生了什么。每个Condition对象内部维护着一个独立的单向等待队列。线程调用await时会从AQS的同步队列中移出加入Condition自己的等待队列同时释放持有的锁然后挂起。这个设计特别像你去银行办事拿号等待是同步队列到了窗口办到一半发现少个材料你离开窗口去补材料就是await释放锁等你重新办完回来继续排队就是signal把线程从条件队列重新放回同步队列。signal方法不会直接唤醒线程它只是把Condition等待队列里的第一个节点重新放回AQS的同步队列。真正让线程醒过来继续执行的是队列里前驱节点释放锁后的unpark。所以await和signal之间隔着一次锁的释放再竞争。这些细节在平时写代码时不一定用得那么深但排查奇怪的线程挂起问题时非常有用。比如业务上出现了“signal明明调用了业务线程就是不醒”的问题排查思路立刻就有了先确认线程是否还停留在Condition等待队列中再确认同步队列中是否存在一个线程始终没释放锁导致等待线程无法获得锁。前者可能是指错了Condition对象后者往往是锁范围太大导致的饥饿。2. ConcurrentHashMap并发容器的天花板ConcurrentHashMap是面试和实战都绕不开的类。它要解决的难题一句话就能说明白既要保证线程安全又要保证高并发下的性能不能让所有操作都堵在同一把锁上。JUC给出的答案是CAS加锁分段。2.1 演进从HashTable到CAS加synchronized先看历史演进才能理解当前版本的设计有多精妙。HashTable的做法最简单粗暴所有方法都用synchronized修饰也就是全局一把锁。读和写互相排斥并发再高也只能串行执行数据量一大性能直接崩。JDK 7时代的ConcurrentHashMap做了改进把数据分成16个Segment每个Segment是一把独立的锁不同Segment上的操作可以并行。这样并发度上限就是16理论上比HashTable强了16倍但仍然存在几个问题并发度固定、扩容时需要锁住整个Segment、空间浪费比较多。JDK 8彻底推翻重做了核心思路变成了CAS加synchronized。不再有Segment的概念而是直接对每个哈希桶数组的槽位进行操作。插入时如果桶为空用CAS直接放入新节点这个过程不加锁如果桶不为空再synchronized锁住这个桶的头节点然后执行链表插入或者红黑树插入。锁粒度从Segment细化到了单个桶不同哈希桶的写入可以完全并行。即使某个桶冲突严重也只影响那一个桶其他桶依然能飞速运行。这个设计还可以看出一个趋势并发编程里的锁粒度越细并发性能越好但锁的管理成本会上升。CAS负责的是“无竞争时用最快的路径”synchronized负责的是“有竞争时用可控的方式阻塞”两者结合就把性能和安全性都抓住了。2.2 put流程hash、bin、树化、扩容全链路我把putVal的完整执行路径拆分出来每一步对应代码里的哪个判断这样你以后看源码不会迷路。第一步是校验key和value不能为空。这一步很多人忘记为什么ConcurrentHashMap不允许null key和null value是为了避免并发下的语义歧义。HashMap允许null key是因为单线程环境下可以用containsKey判断但并发环境下“不存在”和“值为空”没法用一条原子操作区分开干脆直接禁掉。第二步是计算哈希。通过spread方法把key的hashCode做一次扰动让高位信息也参与取模运算这样能够有效降低哈希碰撞。取桶下标的公式是tabAt(tab, i (n - 1) hash)n是桶数组长度n-1的二进制全是1按位与操作等价于取模速度更快。第三步是循环处理三种情况。第一种是桶为空直接CAS写入写成功就结束。第二种是桶的头节点hash等于MOVED说明当前这个桶正在被迁移当前线程会调用helpTransfer协助扩容。这里有个很少人注意的设计迁移不是由一个线程单独完成的而是所有发现扩容状态的线程都会搭把手线程越多迁移越快。多线程一起做迁移还有个好处本来要被阻塞的写线程不需要干等而是去帮忙搬砖既解决了扩容阻塞问题又充分利用了CPU。第三种情况是桶里已经有节点就synchronized锁住头节点然后遍历链表。如果链表节点数达到TREEIFY_THRESHOLD即8会尝试转红黑树。但转树之前有个前置判断如果桶数组长度小于64不会转树而是先扩容数组让元素更分散。树化的目的是把链表查找复杂度从O(n)降为O(log n)但树节点占用空间更大所以只在冲突非常严重时才启用。扩容过程中最关键的一个变量是sizeCtl。它是个状态标志位负值表示扩容正在进行正数表示下一次扩容的阈值。每一次扩容把数组扩大一倍然后通过一个stride步长把桶数组分成多个区间每个线程领取一段区间把里面的节点重新哈希到新数组的对应位置。节点搬家时原位置的头节点会变成ForwardingNode其他线程一看到这个标志就知道这个桶已经搬完了不用再动。2.3 size()怎么算baseCount与CounterCell并发场景下统计元素个数也是一个很考验设计的点。ConcurrentHashMap没有选择在每次put、remove时都加锁去更新一个size字段那样并发瓶颈太明显了。它用的策略是一个baseCount变量加上一个CounterCell数组。每次元素数量变化时先尝试CAS更新baseCount。如果CAS失败说明多线程同时更新竞争激烈就顺着ThreadLocalRandom为当前线程分配一个CounterCell把数量累加到那个CounterCell上。每个线程各写各的格子互相不干扰。最后计算size时只需要把baseCount和所有CounterCell的值累加一遍即可。这有点像一个公司发工资baseCount是主账户CounterCell是每个部门的小金库。平时大家先把钱放到自己部门的小金库里月底财务把所有小金库汇总得到总人数。好处是避免了所有人抢同一个账户的锁坏处是size()返回的是一个近似值。如果正在并发写入可能刚统计完下一秒数值又变了。好在绝大多数业务不需要精确实时的size能接受这种弱一致性。在实际项目中如果确实需要精确的size快照建议在读操作前后自己再锁一次或者维护独立的计数器不要依赖ConcurrentHashMap的size做严格对账这一点踩过坑的同学应该深有体会。3. 线程池七参数背后的一台精密机器线程池可以说是JUC里最实用的组件也是线上问题的高发区。很多人的认知停留在“核心线程数、最大线程数、队列容量”这三个参数的配置上但线程池内部的状态管理、任务提交决策、拒绝策略值得再往深挖一层。3.1 ctl用一个整数装下状态与线程数ThreadPoolExecutor用一个AtomicInteger类型的ctl字段同时保存了两份信息高3位保存线程池运行状态低29位保存工作线程数量。这样设计最大的好处是对状态的修改和对线程数的修改可以合并成一个CAS操作要么同时成功要么同时失败不需要引入额外的锁来保证一致性。运行状态一共五种RUNNING、SHUTDOWN、STOP、TIDYING、TERMINATED。RUNNING能接受新任务也能处理队列中的任务SHUTDOWN不再接受新任务但会处理完队列里剩余的任务STOP不接受新任务也不处理旧任务还会中断正在执行的任务TIDYING是过渡状态任务都结束后进入TERMINATED是最终态terminated方法被调用。这五种状态的数值是精心排列过的因为高3位的数值大小天然形成了状态流转的顺序。比如RUNNING是最小的负数SHUTDOWN和STOP依次增大TERMINATED最大。最终判断是否允许提交任务只要看当前状态是否小于SHUTDOWN即可。这类位运算的设计在Java并发源码里随处可见理解了位排列线程池状态机的流转关系也就清楚了一半。3.2 execute流程走向阻塞队列还是直接开新线程execute方法控制任务提交后的走向逻辑比很多人想象的要复杂一点。完整的分支判断是这样的第一步如果工作线程数小于核心线程数调用addWorker直接创建一个新线程去执行任务。这里要特别注意addWorker不是简单的new Thread它里面有一个双层循环外层循环负责CAS递增workerCount内层循环负责检查线程池状态和队列状态。核心逻辑是必须保证在当前状态下允许新增线程而且CAS成功后线程数不会超过允许的上限。第二步如果线程数已经达到核心线程数尝试把任务加入阻塞队列。offer方法不会阻塞如果队列满了会立即返回false。入队成功后还会再检查一次线程池状态如果已经被SHUTDOWN刚刚入队的任务需要回滚删除同时尝试终止线程池。这一步很容易被忽略却是避免任务丢失的关键。第三步如果入队失败说明队列也满了再尝试创建非核心线程。如果非核心线程数也达到上限就执行拒绝策略。addWorker里有个细节值得关注真正创建线程时工作线程Worker本身继承自AQS具备独占锁的能力。这意味着每个Worker在运行任务前会先通过AQS的lock来标记自己“正在干活”。主线程在shutdown或shutdownNow时就是靠遍历所有Worker并尝试加锁来判断哪些线程正在运行任务进而决定是否发送中断信号。这个机制把“线程池管理”和“线程中断控制”整合到了一套标准组件上设计非常巧妙。3.3 拒绝、动态调参与线上维护拒绝策略是线程池的最后一道防线内置了四种。AbortPolicy直接抛RejectedExecutionException这是默认策略CallerRunsPolicy让提交任务的线程自己执行这个任务起到天然限流的作用DiscardPolicy和DiscardOldestPolicy则直接丢弃前者丢新任务后者丢队列头部最老的任务。我之前踩过的坑是这样的某个接口的并发量突增线程池被填满后触发了AbortPolicy一堆请求直接抛异常客户端看到的全是服务端错误。后来改成CallerRunsPolicy接口虽然响应变慢但至少请求不会丢失系统整体还能维持可用。用CallerRunsPolicy要留意一个风险如果提交任务的线程是Tomcat的工作线程让这些线程执行任务会占用Tomcat线程池可能造成请求线程堆积。所以这个策略适合用在内部异步处理而非直接面对用户请求的场景。动态调参也是一个实战刚需。ThreadPoolExecutor提供了setCorePoolSize、setMaximumPoolSize、setKeepAliveTime这些方法不用重启就能改线程池参数。但官方文档没有明说的一点是动态调小核心线程数时线程池并不会立即杀掉多余线程而是等这些线程空闲后自然超时退出。我一般会配合JMX或者内部监控接口先观察队列积压量和线程利用率再决定调整方向线上改参前最好能做一次小流量验证。线程池生产环境还建议加一套监控指标当前线程数、活跃线程数、队列积压量、任务执行耗时分布、拒绝次数。有了这些基础数据才能判断线程池配置是否合理。否则参数调来调去都是盲人摸象。4. 并发工具类与异步编排CountDownLatch、CyclicBarrier、Semaphore这三个工具类全部基于AQS的共享模式实现。共享模式与独占模式的区别在于独占锁同时只允许一个线程持有而共享锁允许多个线程同时持有state的增减逻辑也跟着不同。4.1 CountDownLatch、CyclicBarrier、Semaphore一次看透CountDownLatch的原理极其简洁。构造时把state设成count每次countDown调用一次releaseShared(1)也就是把state减1。当state减到0时所有在await上等待的线程同时被唤醒然后往下执行。它是一次性的用完了不能重置适合“等待一批任务全部完成”的场景。比如启动时等待多个服务预加载完成、压测时等待多个线程同时就绪后统一施压。CyclicBarrier和CountDownLatch经常被弄混这里说一个最简单的区分标准CountDownLatch是某个线程等其他人干完活CyclicBarrier是一群线程互相等齐了再一起往下走。CyclicBarrier底层使用的是ReentrantLock加Condition并不依赖AQS共享锁它的特点是可循环使用屏障放行后自动重置。具体业务比如多线程分块计算每个线程算完自己的那块数据后等在屏障处等所有线程都到了再进入下一轮汇总计算。Semaphore是信号量机制state表示可用许可证数量。acquire时尝试把state减1减到0就必须等待release时把state加1同时唤醒等待线程。它天然适合做限流。比如某个外部接口的QPS上限是500可以设置一个500的Semaphore请求进来先acquire返回时release超出的请求排队或快速失败。但Semaphore作为限流方案有一个短板它只能限制并发线程数不能限制每秒请求总数。如果请求处理很快即使同一时间只有100个线程并发一秒内也能处理上万个请求。想限制QPS还是得上令牌桶或滑动窗口算法Semaphore的定位更接近“并发信号灯”而不是“流量漏斗”。4.2 CompletableFuture串行、并行、异常恢复CompletableFuture是Java 8引入的异步编排利器它把“回调地狱”里碎成一地的逻辑重新织成了一张清晰的任务网。你可以把它想象成一条流水线上的多道工序每个工序的产出可以自动流入下一道工序任意节点出错可以单独捕获。最常用的场景是并行请求聚合。假设一个订单详情页需要同时查询用户信息、商品信息、库存状态三者之间没有依赖关系。用CompletableFuture可以这样组织三个supplyAsync并行执行再用allOf等待所有任务完成最后通过join获取结果拼装。相比串行执行这种方式能把总耗时压缩到最慢的那个请求的耗时。异常处理也是CompletableFuture里容易被忽略的一个点。exceptionally方法可以捕获前置任务的异常并返回一个默认值。handle方法则无论前面任务是正常还是异常都会被调用并且能根据Throwable是否为null来判断结果。使用whenComplete时尤其注意它虽然能感知异常却不会吞掉异常如果异常未被处理最终调用join或get时依然会被抛出可能影响整个调用链。使用默认的ForkJoinPool.commonPool时要注意线程数默认是CPU核心数减1。如果一个应用里大量使用CompletableFuture的默认异步池做IO密集型任务很容易出现线程饥饿。我见过一个真实案例服务里有几十个异步任务同时用commonPool执行外部HTTP调用每个调用耗时1到2秒结果把公共线程池全部占满其他依赖commonPool的日志上报、内部异步任务全部排队。解决方案很简单IO密集场景统一自定义线程池并设置合理的线程数不要图省事用默认池。4.3 工具类选型自查表平时选型时我建议拿下面这张表做对照能省不少纠结时间。工 具核心机制适用场景典型坑CountDownLatch共享锁计数递减等一批任务完成后再启动不能重用忘记countDown会永久等待CyclicBarrierReentrantLock Condition多线程分阶段同步汇总需要区分await超时与重置逻辑Semaphore共享锁许可证增减限并发量、保护下游资源只能限并发数不能限QPSCompletableFuture任务编排回调并行调用、异步流水线默认公共线程池容易耗尽ReentrantLock独占锁 条件队列需要灵活锁控制容易忘记unlock务必finally释放5. 调优方向与踩坑实录并发代码光看结构还不够线上环境才是终极考场。这一章把我在实际项目里攒下的调优经验和排查手段拿出来内容全部来自真实线上问题可复现性很强。5.1 锁粒度、锁分段与无锁化的取舍锁粒度控制是并发性能优化的核心命题。这里的“粒度”不只是指代码块的大小还包括锁的覆盖范围、锁的持有时间、锁的竞争频率三个维度。锁持有时间太长是最常见的问题。比如很多人在事务里调用远程接口、执行IO操作整个事务期间锁一直不释放。我的优化习惯是锁只保护共享资源的读改写这一小段逻辑事务边界和锁边界完全分离。能先查出数据、算好结果再在写回的那一刻加锁就不要从查询开始就锁住。锁分段是另一个常见思路。当多个线程访问不同对象时没必要共享同一把锁。比如缓存分片、分区ID取模加锁都是把一把大锁拆成多把小锁让竞争分散到多个锁上系统吞吐量立刻就有明显提升。无锁化是更高阶的手段。能用CAS解决的逻辑就不加锁能用ThreadLocal隔离的变量就不共享能用不可变对象代替可变对象就尽可能改成新的对象直接赋值。我评估一个共享变量是否值得无锁化通常会看三个条件读多写少、写操作逻辑简单、数据一致性要求可以接受弱一致或者最终一致。如果三个条件都满足CAS加volatile就能扛住绝大多数压力。5.2 排查线程问题的手段线程问题排查的第一步永远是抓现场。最直接的是jstack命令。执行jstack加上Java进程PID会输出所有线程的当前栈、锁状态和等待条件。看的时候重点关注三块线程状态是不是大量出现BLOCKED、WAITING、TIMED_WAITING栈桢里有没有卡在LockSupport.park、AbstractQueuedSynchronizer的acquireQueued这些方法上有没有出现同一个锁被多个线程同时持有的异常情况。Arthas是另一个提升排查效率的工具。它的thread命令可以直观展示线程状态和CPU占用dashboard可以看全局线程池活跃度watch可以动态观察方法入参和返回。有一次线上接口变慢我用Arthas的thread命令发现大量线程阻塞在数据库连接获取上进一步定位到连接池配置过小问题很快就解决了。Arthas这类工具的在线增强能力比反复加日志重启服务不知道高效多少倍。内存分析也不能忽视并发问题。有时候线程卡住并不一定是锁的问题而是因为内存分配导致GC频繁进而拖慢了所有线程的执行速度。可以先用jstat看GC频率再用jmap dump堆快照最后用MAT分析是否有大对象、大数组或内存泄漏。这个排查路径顺序千万不要乱先看线程栈再看GC日志最后才看堆转储。上来就dump堆大概率被海量数据淹没。5.3 问题速查与个人经验收尾把排查过程中积累的经验整理成速查表遇到问题直接按图索骥现象可能原因处理步骤线程大量BLOCKED锁竞争太激烈jstack确认锁对象缩小锁范围或改CAS线程大量WAITING等待条件未满足、队列阻塞检查Condition唤醒逻辑确认异步链路是否断裂线程池队列积压核心线程数偏低、拒绝策略不匹配监控队列长度动态调大线程数或分流CPU使用率异常高死循环、频繁自旋、GC压力Arthas thread看CPU占用最大的线程分析栈接口偶发超时ForkJoinPool耗尽、外部依赖变慢自定义线程池、设置超时时间、失败快速降级最后分享一点个人经验读JUC源码别按类从头到尾挨个读按场景来读效率最高。先定一个业务场景比如“实现一个带超时的分布式锁”再去看AQS里对应的方法带着问题去读源码记忆和理解都会深很多。维护并发系统也一样永远先想清楚“这个共享状态有多少线程在写、有多少线程在读、能不能接受弱一致”想明白了再来谈用什么工具。这套思路我在团队里反复验证过比任何现成的模板都管用。