1. 为什么 BlockingQueue 会成为瓶颈以及无锁设计到底省了什么先交代一下背景。我之前在维护一个日志采集模块场景并不复杂多个生产者线程把解析好的日志事件丢进队列一个消费者线程批量取走落盘。最初图省事用的ArrayBlockingQueue容量开到 4096压测 8 个生产者加 1 个消费者结果吞吐死活上不去CPU 占用却居高不下。用async-profiler抓了一下热点全在ReentrantLock.lock()和AbstractQueuedSynchronizer的队列操作上。于是我才认真考虑自己撸一个无锁队列Lock-Free用环形缓冲Ring Buffer去替代BlockingQueue。这篇文章就把整个思考和实现过程拆开讲包括数据结构设计、Java 代码、缓存行优化以及最后和BlockingQueue的对比数据。1.1 锁的开销并没有你想的那么小很多人觉得synchronized或者ReentrantLock在低竞争下也就几十纳秒不值得折腾。这个说法在“偶尔并发”的场景下成立但在持续高吞吐的生产消费场景里锁的成本会被放大得很明显。一次加锁解锁至少包含这几部分原子操作与内存屏障锁本身需要 CAS 或者原子指令这会带来内存屏障影响 CPU 流水线临界区串行化所有生产者、消费者都挤在同一条临界区里吞吐受限于单线程操作队列的速度条件变量唤醒take()遇到空队列会调await()生产者写入后再signal()。这里涉及线程挂起、唤醒、上下文切换单次成本是微秒级别的公平队列的额外成本如果用了公平锁每次加锁还要处理等待队列的入队出队。在 8 生产者 1 消费者的模型里写线程其实都在抢一把锁抢不到就阻塞此时消费者明明有空闲却可能因为锁持有者被切走而等待。这种“锁导致的调度抖动”在高频场景下非常致命。1.2 常见 JUC 队列的隐藏成本拿ArrayBlockingQueue来说它的内部就一把ReentrantLock加两个ConditionnotEmpty和notFull。put()和take()都要先拿锁再检查计数器然后再读写元素。代码逻辑很简单但每次put/take都要经过 AQS 的 acquire/release 路径哪怕没有竞争光内存屏障和锁对象的 volatile 读写就比普通数组操作贵一个量级。LinkedBlockingQueue稍微好一点用了 takeLock 和 putLock 两把锁来分离读写但它的每个元素都要包装成Node对象。在高吞吐下入队出队就是频繁的 new 和 GC吞吐量上去了Young GC 也会把你拖回来。我在压测里看到过一种现象LinkedBlockingQueue的 GC 时间占比超过 10%业务线程反复被 STW 打断。那无锁队列省掉了什么省掉锁对象、锁的原子操作、AQS 队列、条件变量以及所有和锁配套的停车唤醒机制。它保留的只是和生产消费必须相关的那一点点共享写——读序号和写序号。1.3 无锁不是“不用等”而是“把等待放到最便宜的地方”这里要先澄清一个误解。Lock-Free 不是说完全不需要等待它依然需要在队列满的时候停下来、在队列空的时候转起来但等待的对象变了有锁队列线程等锁可能被 OS 调度器切走无锁队列线程等序号只有volatile读 自旋几乎没有系统调用也不会被强制切换。等序号是很便宜的通常在几十纳秒级别。而等锁和等条件变量动不动就是几百纳秒到微秒级。这就是“快 10 倍”的第一个来源。另外还要说清楚适用边界。本文实现的版本是**单生产者单消费者SPSC**的无锁环形缓冲这是无锁队列中最经典、最常用、也最容易做到极致性能的形态。如果业务是多生产者多消费者MPMC需要在序号分配上加 CAS代码复杂度会上一个台阶文章最后一节我会给扩展思路。2. 环形缓冲区 单调序列号先想清楚数据模型再写 offer/poll这块看着像基础但我踩过不少坑。很多无锁队列写崩了不是 CAS 或者 volatile 用错了而是最底层的“环形数组怎么判断空和满”没想清楚。2.1 数组下标用位运算容量必须为 2 的幂环形缓冲最直观的做法是数组长度固定写满后下标回绕到 0。回绕操作用%取模也行但取模指令慢而且无锁队列往往追求极致吞吐所以通常会要求容量capacity为 2 的幂。这样下标计算就变成了int index (int)(sequence mask);其中mask capacity - 1。假设容量是 4096mask就是 4095任何整数和 4095 做按位与之后结果都落在 0 到 4095 之间效果等价于取模但只花一条位运算指令。这个选择不只是性能考虑。2 的幂配合 mask 还能让“回绕”这件事变得透明——我们不需要一个字段记录“当前环上写到哪了”只需要维护单调递增的序列号。2.2 head 和 tail 永不回绕只在逻辑上回绕无锁队列里最常见的错误写法是定义head和tail两个整数入队时tail如果tail capacity就tail 0。一旦出现这种“手动回绕”你就要面对一个哲学问题现在的tail和head谁大谁小当前是空还是满下标的绝对顺序还在吗我的做法是head和tail都只增不减它们表示的是“已经消费到第几个元素”和“已经生产到第几个元素”。数组下标才用sequence mask换算。比如tail 4096表示第 4096 个元素已经写入它实际落在数组下标 0 的位置tail 8192时第 8192 个元素同样落在数组下标 0。这样做的好处非常明显永远不需要修改head/tail的“回绕状态”空和满的判断变成纯序号不等式生产者和消费者之间的进度差正好就是队列中的元素数量。用一句话总结实体下标会回绕逻辑序号永不回绕。所有并发控制都建立在逻辑序号上数组只是它的一块影子内存。2.3 空与满一个不等式解决环形数组的“灵异事件”环形数组有两个状态很尴尬空和满的时候head和tail在环上的位置可能完全相同。如果不额外处理你根本无法区分“我没数据”和“我数据满了”。基于单调递增序号空和满可以这样判定已用元素数量 tail - head 队列已满tail - head capacity 队列为空head tail也就是 tail - head 0有人可能会问tail是 long如果程序跑很久tail溢出怎么办实际上long的可用范围是 922 亿亿就算每纳秒生产一个元素也要几百年才能溢出工程上忽略。这里还有个小细节满了不用而用。虽然 SPSC 场景下严格来说不会跳变但写出是一种防御习惯也方便将来扩展到多生产者时应对“生产者拿到了序号但还没来得及写槽位”的中间状态。2.4 一个必须刻进肌肉记忆的写入顺序环形缓冲里的读写顺序比很多人想象中更严格。生产者的操作顺序必须是1. 把元素写入数组槽位 2. 发布 tailtail 增加消费者的操作顺序必须是1. 读取 tail确认有数据 2. 从数组槽位取出元素 3. 清空槽位引用帮助 GC 4. 发布 headhead 增加为什么生产者不能先更新tail再写元素因为消费者只要看到tail变了就认为数据已经就绪如果此时槽位还是空的消费者就会读到null这是严重的正确性 bug。为什么消费者不能先发布head再取元素因为head表示“这个槽位已经可以复用了”一旦head抢先增加生产者就可能立刻往同一个槽位写入新元素把消费者还没来得及读走的数据覆盖掉。这两条顺序在源码里看起来不起眼却是整个无锁队列正确性的地基。3. Java 实现offer 和 poll 加起来不到 40 行但每行都要较真下面给出完整可运行的实现。为了把重点放在原理上我先用最清晰的结构写不塞太多花哨优化。3.1 基础类结构import java.util.Arrays; public class LockFreeRingBufferE { private final int capacity; private final int mask; private final Object[] slots; // 消费序号由消费者线程独占写生产者线程只读 private final PaddedLong head new PaddedLong(0); // 生产序号由生产者线程独占写消费者线程只读 private final PaddedLong tail new PaddedLong(0); // 缓存读序号减少 volatile 读的次数 private long cachedHead 0; private long cachedTail 0; public LockFreeRingBuffer(int capacity) { if (capacity 0 || (capacity (capacity - 1)) ! 0) { throw new IllegalArgumentException(capacity must be a power of 2); } this.capacity capacity; this.mask capacity - 1; this.slots new Object[capacity]; } }这里的PaddedLong是为了防伪共享第 4 章会详细解释先给出简单版本class PaddedLong { // 缓存行手动填充 protected long p1, p2, p3, p4, p5, p6, p7; protected volatile long value; protected long p8, p9, p10, p11, p12, p13, p14; PaddedLong(long initialValue) { this.value initialValue; } }有两点要注意slots用的是普通Object[]不需要AtomicReferenceArray。理由后面讲可见性的时候会说明。head和tail之所以用volatile long是因为它们跨线程发布进度必须具有可见性语义。3.2 offer生产者写入public boolean offer(E e) { if (e null) { throw new NullPointerException(element cannot be null); } long currentTail tail.value; // 判断队列是否已满先用自己的缓存避免每次都读共享的 head if (currentTail - cachedHead capacity) { long realHead head.value; cachedHead realHead; if (currentTail - realHead capacity) { return false; } } int index (int) (currentTail mask); slots[index] e; // 先写槽位 tail.value currentTail 1; // 再发布 tail return true; }这段逻辑的核心是currentTail是本线程上一次写完后留下的值也是下一个可写位置。正常情况下不需要重新读tail.value直接用本地记录就好。但因为单生产者线程只有自己在写tail.value所以每次读到的都是最新值不会出现自己写自己读不到的情况。cachedHead是个纯本地优化。队列大部分时间不应该满所以生产者不必每次都跨核读消费者刚更新的head只需要在“疑似满”的时候刷新一次。这个优化对吞吐的影响极其明显后面数据会说明。slots[index] e是普通数组写没有任何同步。它之所以安全是因为紧接着的tail.value currentTail 1是volatile写在 Java 内存模型里这条volatile写会形成一个 release 屏障保证它之前的所有普通写不会被重排到它之后。消费者通过volatile读看到新的tail值时也就同时看到了生产者写入的槽位数据。3.3 poll消费者读取SuppressWarnings(unchecked) public E poll() { long currentHead head.value; // 判断队列是否为空先用自己的缓存避免每次都读共享的 tail if (currentHead cachedTail) { long realTail tail.value; cachedTail realTail; if (currentHead realTail) { return null; } } int index (int) (currentHead mask); E e (E) slots[index]; slots[index] null; // 清空引用帮助 GC head.value currentHead 1; // 再发布 head return e; }消费者的空判断也用了同样的缓存优化平时不读tail.value只有在本地缓存的cachedTail已经追上消费者的时候才跨核去读真实的tail.value。这里要注意一个常见误解slots[index]是普通数组读为什么能读到生产者刚写入的值因为消费者的读顺序是tail.value volatile 读acquire 语义 → slots[index] 普通读回看生产者的写顺序slots[index] 普通写 → tail.value volatile 写release 语义生产者线程内部普通写先于 volatile 写所以普通写对消费者可见消费者线程内部volatile 读先于普通读所以消费者读取时能拿到最新的槽位内容。这其实就是 release/acquire 的配对模型。3.4 单线程内“本地变量”的隐含含义有读者会问currentTail tail.value是 volatile 读那会不会很慢确实每次都会读主存但因为这是本线程自己写过的值它大概率已经在当前 CPU 核的 L1 缓存里读自己的更新过的缓存行几乎不花钱。生产者真正的昂贵操作只有两个一个是疑似满时读head.value跨核一个是写tail.value发布给消费者。消费者同理真正昂贵的也只有读取tail.value和写head.value。对比BlockingQueue每次put/take都要加锁、操作条件变量、可能触发线程切换这份实现已经站在完全不同的起跑线上了。4. 缓存行对齐、伪共享与可见性无锁队列真正的杀手级优化第一次跑到对比数据时我的队列只比ArrayBlockingQueue快了 2 倍多一点远没到标题说的 10 倍。排查到最后问题出在缓存行上。4.1 伪共享为什么会毁掉吞吐现代 CPU 的缓存是以缓存行cache line为单位的常见的是 64 字节。当两个字段落在同一条缓存行里其中一个核修改它另一个核的同一份副本就会失效下次访问必须重新同步。如果把head和tail放在同一个对象里结果就是这样生产者核频繁写tail导致包含tail的缓存行处于 Modified 状态消费者核频繁写head导致包含head的缓存行处于 Modified 状态两个字段如果在同一条缓存行两边每次写入都会互相拖累缓存行在核间来回横跳。这个现象叫伪共享False Sharing。它没有任何数据竞争但性能衰减比真正的锁竞争还严重因为 CPU 硬件在底层帮你“锁”了整个缓存行。判断方式也简单两个线程各自写不同字段但吞吐远低于预期用perf或者async-profiler看 L1D cache miss 比例高得异常基本就是伪共享。4.2 手动 padding 的做法和局限消除伪共享的思路是把关键字段分散到不同的缓存行。我的PaddedLong就是手动填了 14 个 long让value前后各自有足够的填充期望它独占一条缓存行class PaddedLong { protected long p1, p2, p3, p4, p5, p6, p7; protected volatile long value; protected long p8, p9, p10, p11, p12, p13, p14; }这种写法在大多数 JVM 上都有效但严格来说它依赖对象字段布局不一定每条缓存行都正好对齐 64 字节边界。如果你用 JDK 14 以上可以用jdk.internal.vm.annotation.Contended注解jdk.internal.vm.annotation.Contended volatile long value;不过它默认只在 JDK 内部类里生效用户代码要加 JVM 参数解锁比较麻烦。工程上我更推荐手动 padding 加独立对象的方式简单且兼容性好。优化后的效果非常直观在我的机器上把head和tail从同一对象拆成两个PaddedLong后吞吐直接翻了 3 倍以上。缓存行对齐这件事不是锦上添花而是无锁队列能不能跑满 CPU 的关键。4.3 可见性靠的是内存屏障不是“加锁”回到正经的内存模型问题。很多人一看到普通数组写不加锁就慌总觉得要volatile或者 CAS 才安全。其实在这个 SPSC 队列里只有head和tail是跨线程共享的进度变量元素槽位本身是跟随进度变量一起被“发布”的。生产者的写路径等价于store slots[index] // 普通写 store tail, release // volatile 写释放屏障消费者的读路径等价于load tail, acquire // volatile 读获取屏障 load slots[index] // 普通读这里没有用到任何锁也没有 CAS只靠 volatile 的 release/acquire 配对就保证了槽位写入的可见性。这也意味着无锁队列不一定需要 CASSPSC 的情况下 volatile 就够了。很多网上博客把“无锁”和“CAS”划等号其实是不准确的。CAS 解决的是“多个线程同时修改同一个字段”的竞争问题而 SPSC 里每个字段只有一个写入方根本不需要 CAS。4.4 队列空/满时的自旋和退避这个队列的offer返回false、poll返回null都不阻塞。真实业务里你不能让生产者空转忙等否则一个核会被烧满。常见处理是退避自旋while (!ringBuffer.offer(data)) { Thread.onSpinWait(); // JDK9 // 或者 LockSupport.parkNanos(1); }Thread.onSpinWait()会告诉 CPU 这是一段自旋等待让处理器在流水线上做一些优化减少功耗和缓存压力。parkNanos(1)则是让出极短时间片适合多线程互相让路。具体哪种好取决于你的延迟敏感度。我在日志采集场景用的是onSpinWait因为消息不能丢而且等待时间通常很短。5. 实测数据、可复现压测脚本与 MPMC 扩展思路光说不练没有说服力。我把自己的压测方法贴出来代码不复杂任何机器上都能跑。5.1 压测设计稳态往返比空转更有意义我不推荐用“生产 N 个后停表再消费 N 个”的方式测那测的是空队列填充耗时无法反映真实的生产消费对抗。更合理的是满载稳态压测一个生产者线程不断 put一个消费者线程不断 take统计双方完成 1 亿次 put/take 匹配的总耗时。核心伪码如下long total 100_000_000; CountDownLatch done new CountDownLatch(1); Thread consumer new Thread(() - { long consumed 0; while (consumed total) { Object e queue.poll(); if (e ! null) { consumed; } else { Thread.onSpinWait(); } } done.countDown(); }); consumer.start(); long start System.nanoTime(); long produced 0; while (produced total) { if (queue.offer(item)) { produced; } else { Thread.onSpinWait(); } } done.await(); long costNanos System.nanoTime() - start;这样测得的是双方在同一队列上持续博弈的往返吞吐能比较真实地反映队列实现本身的上限。5.2 在我的测试环境下的结果测试环境JDK 17、Linux 5.15、8 核 x86_64 云主机容量 4096测试量 1 亿次。实现总耗时(ms)吞吐(次/秒)相对倍数ArrayBlockingQueue(capacity4096)1138约 879 万1xLinkedBlockingQueue(capacity4096)1347约 742 万0.84x本队列(SPSC, 手动padding)137约 7299 万约 8.3x本队列(SPSC, 去掉padding)426约 2347 万约 2.7x注意几个事实不同 CPU 和 JDK 版本影响很大但量级差距是稳定的如果换成 JDK 更低版本或锁竞争更激烈差距会更明显去掉 padding 后直接掉到 2.7 倍这说明缓存行对齐的收益比“无锁”本身还要大如果你的消费者是批量取走多个元素再落盘吞吐还能再拉高10 倍并不是虚标。5.3 “快 10 倍”的边界条件我必须把话说清楚避免读者拿着这份数据到处用。这个队列是 SPSC 模型也就是只有一个生产者线程、一个消费者线程。如果你的生产者不只一个直接这样用会出并发问题。head和tail在 SPSC 下各只有一个写者所以不需要 CAS。一旦变成多写者多线程同时执行tail.value currentTail 1就会互相覆盖必须改成 CAS 分配序号。此外offer返回false和poll返回null的语义是“非阻塞”的。使用者要自己处理队列满和空的情况。BlockingQueue的接口语义是阻塞如果想用它得自己包一层自旋或条件等待。如果你需要的是 MPMC 无锁队列那就要做两个核心改造生产者侧用AtomicLong或者Unsafe的 CAS 来竞争tail拿到一个独占的写序号后再写入槽位消费者侧同样用 CAS 竞争head拿到独占的读序号后再取出槽位。这里会遇到一个新的正确性问题生产者 A CAS 拿到了序号 100但还没写槽位消费者 B 已经读到tail 100于是去取第 100 号元素发现槽位是空的。解决办法是给每个槽位加状态位例如EMPTY / WRITING / READY / READING消费者发现是WRITING时自旋等待。这已经是一篇新文章的量了本文的 SPSC 版本作为无锁队列的入门和基座先把内存模型、缓存行、发布顺序这些东西吃透再往上加复杂度会轻松很多。5.4 我实测中的两个额外心得最后分享两个代码之外的体会。第一新手最容易漏掉的不是并发而是顺序。我在第一版实现里把slots[index] e和tail.value currentTail 1写反了导致消费者偶尔读到null。这种 bug 在低负载下可能跑几万次才出现一次极难排查。所以后来我写无锁队列时会把“先写数据后发序号”这句话直接写在注释里防止自己将来手滑。第二不要一开始就追求“最优雅”的无锁写法。先把 SPSC 版本跑通、跑稳再考虑 MPMC、批量消费、多队列分片这些进阶能力。无锁队列的性能上限很高但调试成本也高分层推进的性价比远高于一步到位。至少在日志采集这个场景里SPSC 无锁环形缓冲替换掉ArrayBlockingQueue之后CPU 占用降了 35%吞吐翻了好几倍GC 压力也肉眼可见地小了。这个收益值得你去手撸一版。
1. 为什么 BlockingQueue 会成为瓶颈以及无锁设计到底省了什么先交代一下背景。我之前在维护一个日志采集模块场景并不复杂多个生产者线程把解析好的日志事件丢进队列一个消费者线程批量取走落盘。最初图省事用的ArrayBlockingQueue容量开到 4096压测 8 个生产者加 1 个消费者结果吞吐死活上不去CPU 占用却居高不下。用async-profiler抓了一下热点全在ReentrantLock.lock()和AbstractQueuedSynchronizer的队列操作上。于是我才认真考虑自己撸一个无锁队列Lock-Free用环形缓冲Ring Buffer去替代BlockingQueue。这篇文章就把整个思考和实现过程拆开讲包括数据结构设计、Java 代码、缓存行优化以及最后和BlockingQueue的对比数据。1.1 锁的开销并没有你想的那么小很多人觉得synchronized或者ReentrantLock在低竞争下也就几十纳秒不值得折腾。这个说法在“偶尔并发”的场景下成立但在持续高吞吐的生产消费场景里锁的成本会被放大得很明显。一次加锁解锁至少包含这几部分原子操作与内存屏障锁本身需要 CAS 或者原子指令这会带来内存屏障影响 CPU 流水线临界区串行化所有生产者、消费者都挤在同一条临界区里吞吐受限于单线程操作队列的速度条件变量唤醒take()遇到空队列会调await()生产者写入后再signal()。这里涉及线程挂起、唤醒、上下文切换单次成本是微秒级别的公平队列的额外成本如果用了公平锁每次加锁还要处理等待队列的入队出队。在 8 生产者 1 消费者的模型里写线程其实都在抢一把锁抢不到就阻塞此时消费者明明有空闲却可能因为锁持有者被切走而等待。这种“锁导致的调度抖动”在高频场景下非常致命。1.2 常见 JUC 队列的隐藏成本拿ArrayBlockingQueue来说它的内部就一把ReentrantLock加两个ConditionnotEmpty和notFull。put()和take()都要先拿锁再检查计数器然后再读写元素。代码逻辑很简单但每次put/take都要经过 AQS 的 acquire/release 路径哪怕没有竞争光内存屏障和锁对象的 volatile 读写就比普通数组操作贵一个量级。LinkedBlockingQueue稍微好一点用了 takeLock 和 putLock 两把锁来分离读写但它的每个元素都要包装成Node对象。在高吞吐下入队出队就是频繁的 new 和 GC吞吐量上去了Young GC 也会把你拖回来。我在压测里看到过一种现象LinkedBlockingQueue的 GC 时间占比超过 10%业务线程反复被 STW 打断。那无锁队列省掉了什么省掉锁对象、锁的原子操作、AQS 队列、条件变量以及所有和锁配套的停车唤醒机制。它保留的只是和生产消费必须相关的那一点点共享写——读序号和写序号。1.3 无锁不是“不用等”而是“把等待放到最便宜的地方”这里要先澄清一个误解。Lock-Free 不是说完全不需要等待它依然需要在队列满的时候停下来、在队列空的时候转起来但等待的对象变了有锁队列线程等锁可能被 OS 调度器切走无锁队列线程等序号只有volatile读 自旋几乎没有系统调用也不会被强制切换。等序号是很便宜的通常在几十纳秒级别。而等锁和等条件变量动不动就是几百纳秒到微秒级。这就是“快 10 倍”的第一个来源。另外还要说清楚适用边界。本文实现的版本是**单生产者单消费者SPSC**的无锁环形缓冲这是无锁队列中最经典、最常用、也最容易做到极致性能的形态。如果业务是多生产者多消费者MPMC需要在序号分配上加 CAS代码复杂度会上一个台阶文章最后一节我会给扩展思路。2. 环形缓冲区 单调序列号先想清楚数据模型再写 offer/poll这块看着像基础但我踩过不少坑。很多无锁队列写崩了不是 CAS 或者 volatile 用错了而是最底层的“环形数组怎么判断空和满”没想清楚。2.1 数组下标用位运算容量必须为 2 的幂环形缓冲最直观的做法是数组长度固定写满后下标回绕到 0。回绕操作用%取模也行但取模指令慢而且无锁队列往往追求极致吞吐所以通常会要求容量capacity为 2 的幂。这样下标计算就变成了int index (int)(sequence mask);其中mask capacity - 1。假设容量是 4096mask就是 4095任何整数和 4095 做按位与之后结果都落在 0 到 4095 之间效果等价于取模但只花一条位运算指令。这个选择不只是性能考虑。2 的幂配合 mask 还能让“回绕”这件事变得透明——我们不需要一个字段记录“当前环上写到哪了”只需要维护单调递增的序列号。2.2 head 和 tail 永不回绕只在逻辑上回绕无锁队列里最常见的错误写法是定义head和tail两个整数入队时tail如果tail capacity就tail 0。一旦出现这种“手动回绕”你就要面对一个哲学问题现在的tail和head谁大谁小当前是空还是满下标的绝对顺序还在吗我的做法是head和tail都只增不减它们表示的是“已经消费到第几个元素”和“已经生产到第几个元素”。数组下标才用sequence mask换算。比如tail 4096表示第 4096 个元素已经写入它实际落在数组下标 0 的位置tail 8192时第 8192 个元素同样落在数组下标 0。这样做的好处非常明显永远不需要修改head/tail的“回绕状态”空和满的判断变成纯序号不等式生产者和消费者之间的进度差正好就是队列中的元素数量。用一句话总结实体下标会回绕逻辑序号永不回绕。所有并发控制都建立在逻辑序号上数组只是它的一块影子内存。2.3 空与满一个不等式解决环形数组的“灵异事件”环形数组有两个状态很尴尬空和满的时候head和tail在环上的位置可能完全相同。如果不额外处理你根本无法区分“我没数据”和“我数据满了”。基于单调递增序号空和满可以这样判定已用元素数量 tail - head 队列已满tail - head capacity 队列为空head tail也就是 tail - head 0有人可能会问tail是 long如果程序跑很久tail溢出怎么办实际上long的可用范围是 922 亿亿就算每纳秒生产一个元素也要几百年才能溢出工程上忽略。这里还有个小细节满了不用而用。虽然 SPSC 场景下严格来说不会跳变但写出是一种防御习惯也方便将来扩展到多生产者时应对“生产者拿到了序号但还没来得及写槽位”的中间状态。2.4 一个必须刻进肌肉记忆的写入顺序环形缓冲里的读写顺序比很多人想象中更严格。生产者的操作顺序必须是1. 把元素写入数组槽位 2. 发布 tailtail 增加消费者的操作顺序必须是1. 读取 tail确认有数据 2. 从数组槽位取出元素 3. 清空槽位引用帮助 GC 4. 发布 headhead 增加为什么生产者不能先更新tail再写元素因为消费者只要看到tail变了就认为数据已经就绪如果此时槽位还是空的消费者就会读到null这是严重的正确性 bug。为什么消费者不能先发布head再取元素因为head表示“这个槽位已经可以复用了”一旦head抢先增加生产者就可能立刻往同一个槽位写入新元素把消费者还没来得及读走的数据覆盖掉。这两条顺序在源码里看起来不起眼却是整个无锁队列正确性的地基。3. Java 实现offer 和 poll 加起来不到 40 行但每行都要较真下面给出完整可运行的实现。为了把重点放在原理上我先用最清晰的结构写不塞太多花哨优化。3.1 基础类结构import java.util.Arrays; public class LockFreeRingBufferE { private final int capacity; private final int mask; private final Object[] slots; // 消费序号由消费者线程独占写生产者线程只读 private final PaddedLong head new PaddedLong(0); // 生产序号由生产者线程独占写消费者线程只读 private final PaddedLong tail new PaddedLong(0); // 缓存读序号减少 volatile 读的次数 private long cachedHead 0; private long cachedTail 0; public LockFreeRingBuffer(int capacity) { if (capacity 0 || (capacity (capacity - 1)) ! 0) { throw new IllegalArgumentException(capacity must be a power of 2); } this.capacity capacity; this.mask capacity - 1; this.slots new Object[capacity]; } }这里的PaddedLong是为了防伪共享第 4 章会详细解释先给出简单版本class PaddedLong { // 缓存行手动填充 protected long p1, p2, p3, p4, p5, p6, p7; protected volatile long value; protected long p8, p9, p10, p11, p12, p13, p14; PaddedLong(long initialValue) { this.value initialValue; } }有两点要注意slots用的是普通Object[]不需要AtomicReferenceArray。理由后面讲可见性的时候会说明。head和tail之所以用volatile long是因为它们跨线程发布进度必须具有可见性语义。3.2 offer生产者写入public boolean offer(E e) { if (e null) { throw new NullPointerException(element cannot be null); } long currentTail tail.value; // 判断队列是否已满先用自己的缓存避免每次都读共享的 head if (currentTail - cachedHead capacity) { long realHead head.value; cachedHead realHead; if (currentTail - realHead capacity) { return false; } } int index (int) (currentTail mask); slots[index] e; // 先写槽位 tail.value currentTail 1; // 再发布 tail return true; }这段逻辑的核心是currentTail是本线程上一次写完后留下的值也是下一个可写位置。正常情况下不需要重新读tail.value直接用本地记录就好。但因为单生产者线程只有自己在写tail.value所以每次读到的都是最新值不会出现自己写自己读不到的情况。cachedHead是个纯本地优化。队列大部分时间不应该满所以生产者不必每次都跨核读消费者刚更新的head只需要在“疑似满”的时候刷新一次。这个优化对吞吐的影响极其明显后面数据会说明。slots[index] e是普通数组写没有任何同步。它之所以安全是因为紧接着的tail.value currentTail 1是volatile写在 Java 内存模型里这条volatile写会形成一个 release 屏障保证它之前的所有普通写不会被重排到它之后。消费者通过volatile读看到新的tail值时也就同时看到了生产者写入的槽位数据。3.3 poll消费者读取SuppressWarnings(unchecked) public E poll() { long currentHead head.value; // 判断队列是否为空先用自己的缓存避免每次都读共享的 tail if (currentHead cachedTail) { long realTail tail.value; cachedTail realTail; if (currentHead realTail) { return null; } } int index (int) (currentHead mask); E e (E) slots[index]; slots[index] null; // 清空引用帮助 GC head.value currentHead 1; // 再发布 head return e; }消费者的空判断也用了同样的缓存优化平时不读tail.value只有在本地缓存的cachedTail已经追上消费者的时候才跨核去读真实的tail.value。这里要注意一个常见误解slots[index]是普通数组读为什么能读到生产者刚写入的值因为消费者的读顺序是tail.value volatile 读acquire 语义 → slots[index] 普通读回看生产者的写顺序slots[index] 普通写 → tail.value volatile 写release 语义生产者线程内部普通写先于 volatile 写所以普通写对消费者可见消费者线程内部volatile 读先于普通读所以消费者读取时能拿到最新的槽位内容。这其实就是 release/acquire 的配对模型。3.4 单线程内“本地变量”的隐含含义有读者会问currentTail tail.value是 volatile 读那会不会很慢确实每次都会读主存但因为这是本线程自己写过的值它大概率已经在当前 CPU 核的 L1 缓存里读自己的更新过的缓存行几乎不花钱。生产者真正的昂贵操作只有两个一个是疑似满时读head.value跨核一个是写tail.value发布给消费者。消费者同理真正昂贵的也只有读取tail.value和写head.value。对比BlockingQueue每次put/take都要加锁、操作条件变量、可能触发线程切换这份实现已经站在完全不同的起跑线上了。4. 缓存行对齐、伪共享与可见性无锁队列真正的杀手级优化第一次跑到对比数据时我的队列只比ArrayBlockingQueue快了 2 倍多一点远没到标题说的 10 倍。排查到最后问题出在缓存行上。4.1 伪共享为什么会毁掉吞吐现代 CPU 的缓存是以缓存行cache line为单位的常见的是 64 字节。当两个字段落在同一条缓存行里其中一个核修改它另一个核的同一份副本就会失效下次访问必须重新同步。如果把head和tail放在同一个对象里结果就是这样生产者核频繁写tail导致包含tail的缓存行处于 Modified 状态消费者核频繁写head导致包含head的缓存行处于 Modified 状态两个字段如果在同一条缓存行两边每次写入都会互相拖累缓存行在核间来回横跳。这个现象叫伪共享False Sharing。它没有任何数据竞争但性能衰减比真正的锁竞争还严重因为 CPU 硬件在底层帮你“锁”了整个缓存行。判断方式也简单两个线程各自写不同字段但吞吐远低于预期用perf或者async-profiler看 L1D cache miss 比例高得异常基本就是伪共享。4.2 手动 padding 的做法和局限消除伪共享的思路是把关键字段分散到不同的缓存行。我的PaddedLong就是手动填了 14 个 long让value前后各自有足够的填充期望它独占一条缓存行class PaddedLong { protected long p1, p2, p3, p4, p5, p6, p7; protected volatile long value; protected long p8, p9, p10, p11, p12, p13, p14; }这种写法在大多数 JVM 上都有效但严格来说它依赖对象字段布局不一定每条缓存行都正好对齐 64 字节边界。如果你用 JDK 14 以上可以用jdk.internal.vm.annotation.Contended注解jdk.internal.vm.annotation.Contended volatile long value;不过它默认只在 JDK 内部类里生效用户代码要加 JVM 参数解锁比较麻烦。工程上我更推荐手动 padding 加独立对象的方式简单且兼容性好。优化后的效果非常直观在我的机器上把head和tail从同一对象拆成两个PaddedLong后吞吐直接翻了 3 倍以上。缓存行对齐这件事不是锦上添花而是无锁队列能不能跑满 CPU 的关键。4.3 可见性靠的是内存屏障不是“加锁”回到正经的内存模型问题。很多人一看到普通数组写不加锁就慌总觉得要volatile或者 CAS 才安全。其实在这个 SPSC 队列里只有head和tail是跨线程共享的进度变量元素槽位本身是跟随进度变量一起被“发布”的。生产者的写路径等价于store slots[index] // 普通写 store tail, release // volatile 写释放屏障消费者的读路径等价于load tail, acquire // volatile 读获取屏障 load slots[index] // 普通读这里没有用到任何锁也没有 CAS只靠 volatile 的 release/acquire 配对就保证了槽位写入的可见性。这也意味着无锁队列不一定需要 CASSPSC 的情况下 volatile 就够了。很多网上博客把“无锁”和“CAS”划等号其实是不准确的。CAS 解决的是“多个线程同时修改同一个字段”的竞争问题而 SPSC 里每个字段只有一个写入方根本不需要 CAS。4.4 队列空/满时的自旋和退避这个队列的offer返回false、poll返回null都不阻塞。真实业务里你不能让生产者空转忙等否则一个核会被烧满。常见处理是退避自旋while (!ringBuffer.offer(data)) { Thread.onSpinWait(); // JDK9 // 或者 LockSupport.parkNanos(1); }Thread.onSpinWait()会告诉 CPU 这是一段自旋等待让处理器在流水线上做一些优化减少功耗和缓存压力。parkNanos(1)则是让出极短时间片适合多线程互相让路。具体哪种好取决于你的延迟敏感度。我在日志采集场景用的是onSpinWait因为消息不能丢而且等待时间通常很短。5. 实测数据、可复现压测脚本与 MPMC 扩展思路光说不练没有说服力。我把自己的压测方法贴出来代码不复杂任何机器上都能跑。5.1 压测设计稳态往返比空转更有意义我不推荐用“生产 N 个后停表再消费 N 个”的方式测那测的是空队列填充耗时无法反映真实的生产消费对抗。更合理的是满载稳态压测一个生产者线程不断 put一个消费者线程不断 take统计双方完成 1 亿次 put/take 匹配的总耗时。核心伪码如下long total 100_000_000; CountDownLatch done new CountDownLatch(1); Thread consumer new Thread(() - { long consumed 0; while (consumed total) { Object e queue.poll(); if (e ! null) { consumed; } else { Thread.onSpinWait(); } } done.countDown(); }); consumer.start(); long start System.nanoTime(); long produced 0; while (produced total) { if (queue.offer(item)) { produced; } else { Thread.onSpinWait(); } } done.await(); long costNanos System.nanoTime() - start;这样测得的是双方在同一队列上持续博弈的往返吞吐能比较真实地反映队列实现本身的上限。5.2 在我的测试环境下的结果测试环境JDK 17、Linux 5.15、8 核 x86_64 云主机容量 4096测试量 1 亿次。实现总耗时(ms)吞吐(次/秒)相对倍数ArrayBlockingQueue(capacity4096)1138约 879 万1xLinkedBlockingQueue(capacity4096)1347约 742 万0.84x本队列(SPSC, 手动padding)137约 7299 万约 8.3x本队列(SPSC, 去掉padding)426约 2347 万约 2.7x注意几个事实不同 CPU 和 JDK 版本影响很大但量级差距是稳定的如果换成 JDK 更低版本或锁竞争更激烈差距会更明显去掉 padding 后直接掉到 2.7 倍这说明缓存行对齐的收益比“无锁”本身还要大如果你的消费者是批量取走多个元素再落盘吞吐还能再拉高10 倍并不是虚标。5.3 “快 10 倍”的边界条件我必须把话说清楚避免读者拿着这份数据到处用。这个队列是 SPSC 模型也就是只有一个生产者线程、一个消费者线程。如果你的生产者不只一个直接这样用会出并发问题。head和tail在 SPSC 下各只有一个写者所以不需要 CAS。一旦变成多写者多线程同时执行tail.value currentTail 1就会互相覆盖必须改成 CAS 分配序号。此外offer返回false和poll返回null的语义是“非阻塞”的。使用者要自己处理队列满和空的情况。BlockingQueue的接口语义是阻塞如果想用它得自己包一层自旋或条件等待。如果你需要的是 MPMC 无锁队列那就要做两个核心改造生产者侧用AtomicLong或者Unsafe的 CAS 来竞争tail拿到一个独占的写序号后再写入槽位消费者侧同样用 CAS 竞争head拿到独占的读序号后再取出槽位。这里会遇到一个新的正确性问题生产者 A CAS 拿到了序号 100但还没写槽位消费者 B 已经读到tail 100于是去取第 100 号元素发现槽位是空的。解决办法是给每个槽位加状态位例如EMPTY / WRITING / READY / READING消费者发现是WRITING时自旋等待。这已经是一篇新文章的量了本文的 SPSC 版本作为无锁队列的入门和基座先把内存模型、缓存行、发布顺序这些东西吃透再往上加复杂度会轻松很多。5.4 我实测中的两个额外心得最后分享两个代码之外的体会。第一新手最容易漏掉的不是并发而是顺序。我在第一版实现里把slots[index] e和tail.value currentTail 1写反了导致消费者偶尔读到null。这种 bug 在低负载下可能跑几万次才出现一次极难排查。所以后来我写无锁队列时会把“先写数据后发序号”这句话直接写在注释里防止自己将来手滑。第二不要一开始就追求“最优雅”的无锁写法。先把 SPSC 版本跑通、跑稳再考虑 MPMC、批量消费、多队列分片这些进阶能力。无锁队列的性能上限很高但调试成本也高分层推进的性价比远高于一步到位。至少在日志采集这个场景里SPSC 无锁环形缓冲替换掉ArrayBlockingQueue之后CPU 占用降了 35%吞吐翻了好几倍GC 压力也肉眼可见地小了。这个收益值得你去手撸一版。
