第一次被 Disruptor 惊到是在压测订单处理链路的时候。当时系统里用 LinkedBlockingQueue 做管道跑了不到半小时P99 延迟就开始一路走高锁竞争、GC、线程切换像连环爆炸。换成 Disruptor 后同一台机器、同样的事件量压测曲线平稳得不像同一个系统。这个“高性能环形队列”的底层设计非常值得拆开看一个预分配的环形数组一串单调递增的 Sequence配合缓存行填充和内存屏障把传统队列里最贵的并发动作全部绕开了。我准备从教材里的循环队列 rear length 写法讲起一路拆到 RingBuffer、Sequencer、SequenceBarrier再给一个能直接跑的 Demo 和压测思路。适合正在做高并发调优、读 Disruptor 源码卡壳以及想搞明白无锁队列为什么能这么快的人。1. 先搞懂环形队列的“祖传”实现1.1 rear length 版本循环队列最经典的表示法在数据结构教材里用数组实现循环队列时最常见的写法是 q[m] 配合 rear 和 length 两个变量。这里的 rear 不是队首指针而是“下一个可写位置”length 表示当前元素个数。队首位置不需要额外变量直接用(rear - length m) % m推出来。我以 m 5 为例手动走一遍初始状态rear 0length 0队列为空入队 A往 q[0] 写 Arear 变成 1length 变成 1。此时队首是 (1 - 1 5) % 5 0取出来就是 A入队 B往 q[1] 写 Brear 变成 2length 变成 2。队首还是 0出队一次从队首下标 0 取 Alength 变成 1。下一次队首通过公式 (2 - 1 5) % 5 1正好指向 B。建议别死记公式把它理解成“从队尾往回数 length 个位置就是队首”。遍历和判空判满都很直观length 0为空length m为满。rear 越过末尾后取模回到数组起点整个数组空间就像一个环。单线程场景下这套实现完全够用。但一旦进入高并发问题立刻暴露front/rear/length 是共享状态入队出队必须加锁否则两个线程同时改 length数据就丢了。判满和判空依赖 length 的可见读在 Java 里如果不加 volatile 或锁消费者看到的 length 可能长期是旧值。另一个经常被忽略的是对象生命周期如果 q[m] 里存的是对象引用生产者和消费者每一轮交互都在创建、丢弃对象GC 就成了隐藏瓶颈。Disruptor 在架构层面要解决的就是这些问题。1.2 从加锁队列到无锁环形Disruptor 的解决思路第一次读 Disruptor 源码时我梳理了它与传统循环队列的对应关系本质是“同一套环形思想换了一套并发模型”问题传统循环队列Disruptor 的做法空/满判断用 length 判空判满共享变量需要锁用单调递增的 Sequence生产序号永远走在消费序号前面并发保护对整段入队/出队代码加锁只在多生产者申请序号时做一次 CAS数组下标% m 取模 (bufferSize - 1) 位运算要求容量为 2 的幂对象分配每次入队塞新引用旧对象等 GC环形槽位预分配同一对象反复复用缓存竞争相邻线程修改相近字段时互相拖慢缓存行填充把高频更新字段隔离到独立缓存行从表格能看出Disruptor 没有发明“环”这个概念它解决的问题是在环上并用大量并发读写时怎么把每次操作的代价压到最低。下面逐个拆开这些机制。2. 环形缓冲区为什么能这么高效先看硬件2.1 数组连续空间CPU 缓存和内存分配的隐形红利Disruptor 的 RingBuffer 本质是一个预分配数组事件对象在启动时创建好之后一直躺在数组里只被覆写不被释放。传统队列的思维是“入队一个对象出队拿走一个对象”Disruptor 反过来“槽位是固定的流动的是序号。”数组带来的第一个红利是连续内存。CPU 从内存加载数据到 L1/L2 缓存时按 64 字节的缓存行加载访问数组第 i 个元素时大概率连第 i1、i2 个元素也一起进了缓存。如果队列里放的是链表节点节点对象散落在堆各处缓存命中率会差很多。第二个红利是零 GC事件对象不被销毁也就没有垃圾产生。第三个红利是读写区域天然隔离。生产者只写“下一个槽位”消费者只读“当前可读位置”只要序号管理严谨就不需要把整段操作锁起来。用个类比传统队列像仓库里的快递收一件、发一件包装拆掉就扔Disruptor 像工厂流水线上的固定工位工人永远在同一个位置装配不同批次零件位置不换零件号变。2.2 缓存行填充为什么只有 8 字节的 Long 要占 64 字节Disruptor 源码里有个经典细节带填充的 Sequence。它在真正的 value 前后各放了 7 个 long 字段把对象整体撑到 64 字节以上。这不是炫技是伪共享False Sharing问题。解释一下场景Thread A 和 Thread B 在不同 CPU 核上运行各自需要频繁修改两个对象的不同字段。如果这两个对象的内存恰好落在同一个 64 字节缓存行里A 的写会让 B 所在核的缓存行失效B 只能重新从内存加载B 的写又会反过来让 A 失效。两边其实各改各的数据却被迫不断跨核同步性能开销可能放大几十倍。Disruptor 对高频变化的 Sequence 做填充后每个 Sequence 独占缓存行其他线程修改别的东西不再牵连它。自己实现环形队列时如果发现 CPU 占用高但锁很少、耗时分布也不集中可以考虑给最热的几个字段补 padding。JDK 的Contended注解也能达到类似效果不过要留意虚拟机参数限制。2.3 内存屏障无锁的关键不是“没有锁”而是“有序发布”很多初学者以为 Disruptor 无锁就是完全不做同步这是误解。它不做锁但依赖 Java volatile 和 CAS 自带的“屏障”语义。生产者的发布顺序是这样的先往环形数组槽位写事件字段普通写再更新发布序列 Sequencevolatile 写。按 Java 内存模型的规则普通写在 volatile 写之前且普通写不能越过 volatile 写被重排到其后。所以消费者一旦读到新的序号就能保证槽位数据已经完整写好了。反过来如果 Sequence 不是 volatile编译器或 CPU 可能把事件写入重排到序号更新之后消费者读到最新序号但槽位里还是旧数据整个无锁体系立即崩掉。消费者侧读 volatile Sequence 是获取语义保证后续读槽位数据不会越过这次序号读取被重排到前面。这就是内存屏障在 Disruptor 里的作用不排队但发布/消费的顺序是严格可控的。3. 拆开 Disruptor 的三件套Sequence、Sequencer 与 RingBuffer3.1 Sequence整个环形队列的“世界时钟”Disruptor 里的 Sequence 不只是数组下标。它本质是一个单调递增的 long记录“下一个要发布的位置”或“已经消费到的位置”。RingBuffer 的游标cursor是生产者侧核心消费者有各自的消费序列。实际取槽位时通过sequence (bufferSize - 1)得到数组下标。为什么一定要单调递增而不是像教材里那样循环用 0..m-1 的下标因为单调递增后比较“谁快谁慢”就变成两个自然数的大小比较不需要处理绕圈问题。消费者只需要知道 cursor 变成了几就知道可读事件的总进度生产者只需要看消费者最慢的序列就知道还有没有可写槽位。这比维护 front/rear/length 三个变量去判断空满干净得多。3.2 单生产者和多生产者CAS 只发生在申请序号时Disruptor 提供两套生产路径单生产者SingleProducerSequencer生产者线程把 cursor 加一就能拿到写槽位连 CAS 都可以省略这是最快路径多生产者MultiProducerSequencer多个线程同时申请序号用 CAS 竞争一个范围。多生产者的流程很像取号A 线程 CAS 申请到 100..109B 线程 CAS 申请到 110..119然后各自写自己的槽位互不干扰。CAS 只发生在“申请号码”这一小步写槽位本身完全并行。如果没有这层序号分配多个生产者可能同时写同一个槽位需要锁或原子操作保护那就回到传统队列的赛道了。如果你的业务只有一个写线程务必用ProducerType.SINGLE。我见过用默认多生产者跑单写线程的项目性能虽然也还行但对比测试后明显比 SINGLE 差一截。默认值不能替代对业务形态的判断。3.3 消费者侧BatchEventProcessor 与 SequenceBarrier 的配合消费者的标准循环可以拆成两步调用 SequenceBarrier.waitFor(next) 拿到当前最大可读序号从 next 到可用序号之间连续处理每一个事件。第二个步骤里有个容易被忽略的批处理能力waitFor 返回的不一定只比当前大 1而是最新的可用序列。消费者可以一次性处理一整段事件摊薄上下文切换和等待开销。这正是 Disruptor 暴力吞吐的又一个来源。SequenceBarrier 还负责依赖关系。比如广播场景里有 C1、C2、C3 三个消费者C2 依赖 C1 先处理完C2 的 barrier 就会同时盯着生产者 cursor 和 C1 的消费序列只有两者都满足才放行。这个设计让多级处理流水线可以无锁协作。3.4 等待策略延迟、CPU 与吞吐的三选一消费者等待“没有新事件”时行为由 WaitStrategy 决定。Disruptor 3.x 里常见几个BusySpinWaitStrategy自旋忙等不放弃 CPU延迟最低但空等时 CPU 占用很高YieldWaitStrategy自旋一段时间后让出 CPU 时间片兼顾延迟和 CPUSleepingWaitStrategy自旋、让出、睡眠多级退让更省 CPU延迟更高BlockingWaitStrategy用锁和条件变量阻塞唤醒CPU 最省但锁竞争会带来延迟抖动。选择没有绝对标准。低延迟交易场景可以上 BusySpin线上混合部署、CPU 核有限时我一般选 Yield 或 Blocking。强烈建议先用压测跑一遍真实负载再决定不要拍脑袋。4. 实操从零搭一个 Disruptor 环形队列 Demo4.1 依赖与事件定义只做最小演示用 Maven 引入依赖dependency groupIdcom.lmax/groupId artifactIddisruptor/artifactId version3.4.4/version /dependency定义事件对象 TradeEvent里面放两个字段方便观察生产者写入和消费者读取。public class TradeEvent { public long price; public long amount; }这个类不需要 getter/setter字段直接 public 也没问题Disruptor 文档经常这么写因为事件对象只是槽位里的数据容器不暴露给外部。4.2 消费者、生产者与事件翻译器搭建最小示例int bufferSize 1024; DisruptorTradeEvent disruptor new Disruptor( TradeEvent::new, bufferSize, runnable - new Thread(runnable, trade-worker), ProducerType.SINGLE, new YieldWaitStrategy() ); disruptor.handleEventsWith((event, sequence, endOfBatch) - { // 消费逻辑当前只有一个消费者线程打印价格 System.out.printf(seq%d, price%d%n, sequence, event.price); }); disruptor.start(); RingBufferTradeEvent ringBuffer disruptor.getRingBuffer(); for (long price 1; price 10; price) { long v price; ringBuffer.publishEvent((event, sequence) - event.price v); } // 结束前释放资源 disruptor.shutdown();这里有个容易踩的坑handleEventsWith传入的 lambda 是 EventHandlerpublishEvent的第一个参数是 EventTranslator两个 lambda 作用完全不同。前者处理槽位里现成对象后者决定怎么把外部参数写进槽位对象。如果搞混代码可以编译过但行为完全不对。另一个必须记住的约束消费者拿到 event 后不要长时间保存引用。环形队列的槽位会被后续生产者覆盖你持有的 event 对象下一个时刻可能就是另一笔数据。需要异步处理或传递时先拷贝字段到新对象或不可变 DTO。4.3 bufferSize 为什么必须是 2 的幂Disruptor 定位槽位用sequence (bufferSize - 1)为了用位运算替代取模bufferSize 必须是 2 的幂。比如 1024 对应的掩码是 1023二进制全是 1按位与的结果等价于取模如果 bufferSize 是 1000999 的二进制不是全 1 出来的结果就不会正确。容量怎么定容量太小生产者和消费者速度略有不均衡时立刻互相等待容量太大一次性预分配的槽位对象很多浪费内存。我习惯先按“每秒生产量 × 消费者最大容忍延迟”估算瞬时积压量再向上取整到最近的 2 的幂。比如每秒一万条、消费者最慢 50ms瞬时积压大约 500直接选 1024 更稳。4.4 对比压测怎么证明它真的快验证性能时最忌讳在循环里 println打印会吃掉大量时间测的是 stdout 而不是队列。我常用一个“回环累加”测试一个生产者线程循环发布 1000 万个长整数一个消费者线程只做 sum value不打印不上锁用System.nanoTime()记录总耗时再统计延迟分位数。同样的逻辑用 LinkedBlockingQueue 跑一遍差异会非常明显。LinkedBlockingQueue 在消费者等待时靠条件变量阻塞线程切换和 put/take 的路径更长Disruptor 则是一个持续自旋的线程配合 volatile 序号消费者拿到连续事件还能批量处理。压测时务必先热身几百万次等 JIT 编译热点后再进入正式统计否则结果会被解释执行拖垮。5. 实战中的坑与排查技巧5.1 事件积压先看 cursor 与消费 sequence 的差距积压量等于ringBuffer.getCursor() - 消费者序列.get()。如果这个差值长时间接近 bufferSize通常不是 Disruptor 的问题而是消费者处理太慢或生产者速率过高。排查顺序先确认消费逻辑耗时再确认是否多个消费者共享了同一个序列最后看下游是否真的消化了事件。我遇到过类似事故Disruptor 本身只有微秒级延迟但消费者把每条事件打到数据库连接池打满积压一路上涨。队列跑得再快也不能替下游解围。5.2 读越界异常SequenceException 的常见原因“Attempting to read from sequence x but last published is y” 这类异常本质是消费者看到了一个超过发布进度的序列。常见原因有消费者启动时就设置了一个不合理的起始序列比如直接从 cursor 100 开始把多生产者的 next 序号当成了单生产者下一个可读位置依赖多个 gating sequence 时某个 gating sequence 没有更新。排查时打印每个 Sequence 的当前值对比 cursor、消费者自己序列、上游依赖序列往往一眼能看出谁落后了。初始化消费者时建议将起始序列设为当前 cursor表示从下一条开始消费不要随意预跳。5.3 广播与 WorkerPool 选错重复消费或漏消费Disruptor 官方 DSL 里handleEventsWith是广播语义每个消费者独立都拿到所有事件handleEventsWithWorkerPool是分片语义每个事件只交给其中一个 worker。这个选择直接决定业务正确性。常见错误想让多个消费者分摊负载却用了handleEventsWith每个事件被重复处理想让多个消费者分别做不同环节却用了 WorkerPool事件被随机分配给某一个下游根本收不到全量数据。上线前先画一个事件流转图同一份数据有几个处理分支每条分支是否必须全部执行完毕。想清楚这个模式就不会选错。5.4 等待策略引发的 CPU 高占用BusySpinWaitStrategy 本质是死循环轮询没有事件时也会占满一个 CPU 核心。如果部署在云主机或共用开发机这个策略会非常惹眼。所以我只在延迟敏感的核心链路用 BusySpin其他场景用 Yield 或 Blocking。切到 BlockingWaitStrategy 后延迟变高也别急着否定它。条件变量在事件频率较低时会反复触发线程切换事件频率很高时阻塞成本反而被摊薄。哪种策略好真的要看负载不能只看结论。5.5 速查表常见症状对应的排查方向症状可能原因建议积压持续增长下游处理慢监控 cursor 与 gating sequence 差值优化下游CPU 飙高BusySpin 忙等 / 伪共享换 Yield 或 Blocking给热字段加 padding消费者收不到事件广播/池模式选错明确是否需要全量复制消费偶发读越界Sequence 初始化错误打印各 sequence核对起始值GC 频繁消费者中拷贝了过多临时对象避免把事件对象再次封装使用固定 DTO6. 影响范围环形队列模型能用在哪些场景6.1 已经被验证的高吞吐场景Log4j2 的异步日志客户端和异步追加器底层就用了 Disruptor这是异步日志模式能扛住高并发业务刷屏的原因之一。高频交易系统常把它作为撮合引擎内部的事件总线事件从行情接收、风控、订单匹配到回报分发全程走环形队列。游戏服务器也用它做消息路由尤其是在消息吞吐高、峰值波动大的玩法里。我也在一些微服务网关里用 Disruptor 做请求事件的分层处理把串行业务逻辑拆成并行事件流水线。这些场景有个共同点热点路径上的事件量非常大而且下游处理可以设计成多个相对独立的小步骤。如果业务本身就是一个大而重的事务型操作环形队列带来的收益会被下游耗时抵消。6.2 什么时候别硬上 Disruptor接入 Disruptor 是有成本的事件对象生命周期要管理、广播/池模式要选对、等待策略要调日志排障也要理解 Sequence。如果系统 QPS 只有几百或者消息链路上随便一个环节都是数据库写、远程调用把 LinkedBlockingQueue 换成 Disruptor 的用户感知几乎为零。先用压测数据做决定。另外Disruptor 不擅长做持久化消息或可靠投递它本质是内存中的有界环形队列没有持久化没有消息确认与重投。需要可靠性保证的场景应该用真正的消息中间件而不是拿它硬撑。6.3 无锁环形模型对日常编码的启发抛开 Disruptor 本身它给我最实在的启发有三条用“序号”代替“指针/长度”来描述队列进度尤其在并发场景单调递增的序号不容易出错把共享冲突压缩到最小的关键点比如只在申请序号时 CAS其余路径保持并行数据结构设计要考虑 CPU 缓存和内存屏障而不仅是算法复杂度。我后来做日志缓冲、做限流队列复刻这套思路收益都很明显。理解了它再回头看 Kafka 的日志分段、Netty 里的环形缓冲结构会有一通百通的感觉。如果只留一条经验我会说别急着换队列先画生产者和消费者的速度和积压曲线。Disruptor 再猛也只是把“排队”这一步的损耗压到极低下游不消化上游照样堵。我在一次调优里就吃过亏换 Disruptor 后队列瓶颈消失了但真实瓶颈其实是下游数据库连接池白折腾了半天。另外一个可以立刻用上的小技巧是回环测试满环。把消费者处理时间故意设到 10 毫秒生产端不停发布观察 cursor 与消费 sequence 的差值如何逼近 bufferSize。跑过这个实验你就真正理解有界环形队列的背压机制以后碰到日志组件报警、消息链路积压也能第一时间判断问题出在生产侧还是消费侧。要我再从头选型一次三个问题会提前想清楚谁会写、谁会读、读写是否对称。答案直接决定了 ProducerType、广播还是 WorkerPool、等待策略怎么配。