尧图网页设计 
❃博主首页 「程序员1970」同名公众号「程序员1970」☠博主专栏 mysql高手elasticsearch高手源码解读java核心面试攻关文章目录一、性能数据二、BlockingQueue的性能天花板在哪里三、Disruptor第一刀环形数组预分配实现零拷贝四、Disruptor第二刀Sequence机制彻底消灭锁五、Disruptor第三刀缓存行填充消灭伪共享5.1 什么是伪共享5.2 Disruptor的解决方案5.3 实测对比六、批处理最后一块拼图七、等待策略延迟与CPU的博弈八、多消费者依赖图Disruptor独有的能力九、何时该用Disruptor何时该用BlockingQueue十、总结一下一、性能数据LMAX交易所基于Disruptor构建的交易系统订单处理能力达到每秒600万TPS。而同样场景下使用传统BlockingQueue直接*。这不是量级的差距是维度的碾压。要理解这种差距从何而来必须拆解Disruptor底层三个核心设计环形数组零拷贝、伪共享消除、缓存行填充。每一项都直击传统队列的性能命脉。二、BlockingQueue的性能天花板在哪里BlockingQueue的实现无论ArrayBlockingQueue还是LinkedBlockingQueue本质上依赖两样东西锁和动态内存分配。// ArrayBlockingQueue内部核心逻辑简化finalReentrantLocklock;privatefinalObject[]items;// 动态扩容时需要Arrays.copyOfpublicvoidput(Ee)throwsInterruptedException{lock.lock();// 加锁线程阻塞try{// 满了就等待while(countitems.length)notFull.await();items[putIndex]e;// 写入}finally{lock.unlock();}}三个致命问题第一锁竞争带来线程上下文切换。 锁的本质是让线程进入内核态等待涉及用户态到内核态的切换开销。高并发下大量线程在锁上排队CPU时间片被白白消耗在调度而非计算上。第二链表/数组扩容带来GC压力。 LinkedBlockingQueue基于链表节点每个节点都是一个独立对象频繁创建和回收直接压迫垃圾回收器。ArrayBlockingQueue扩容时的Arrays.copyOf更是一次性搬运整块内存。第三数据搬移导致缓存失效。 链表节点在堆内存中离散分布CPU缓存无法有效预取每次访问都可能触发cache miss。三、Disruptor第一刀环形数组预分配实现零拷贝Disruptor的底层是一个固定大小的Object[]数组——RingBuffer。但它和普通数组不同做到了两件事预分配和永不回收。// RingBuffer初始化时一次性创建所有事件对象Object[]entriesnewObject[bufferSize];// bufferSize必须是2的幂for(inti0;ibufferSize;i){entries[i]eventFactory.newInstance();// 预填充}这意味着什么事件对象在系统启动时就全部创建完毕运行期间零new操作。 没有new就没有GC没有GC就没有Stop-The-World停顿。传统队列每一次入队都可能触发一次minor GC累积起来就是吞吐量的隐形杀手。更精妙的是指针无限递增、永不回收的设计。每个槽位用一个long类型的sequence标识通过位运算定位// 数组长度为2^n取模运算变成位运算intindex(int)(sequence(bufferSize-1));// 例如 bufferSize1024, sequence1025// 1025 1023 1直接定位到index1sequence是long类型几乎不可能溢出。槽位被反复覆写使用不存在旧对象被回收的过程——数据根本不搬移只是原地覆写。这就是Disruptor语境下零拷贝的真正含义不是数据在内存间零拷贝传输而是消除了对象生命周期中的拷贝和回收开销。对比BlockingQueue的Arrays.copyOf两者的内存操作量级完全不在一个层次。四、Disruptor第二刀Sequence机制彻底消灭锁传统队列用锁保护共享状态Disruptor用CASSequence替代。RingBuffer本身不维护头指针和尾指针的概念。它只有一个cursor生产者的Sequence。每个消费者也有自己的Sequence表示自己已消费到的位置。生产者cursor 5表示已发布到第5个槽位 消费者Asequence 3表示已处理到第3个槽位 消费者Bsequence 2表示已处理到第2个槽位单生产者模式下生产者直接nextSequence cursor 1无需CAS无竞争无锁。多生产者模式下多个生产者通过CAS竞争递增同一个nextSequence// 多生产者竞争下一个槽位longnextSequence;do{nextSequencecursor.get();}while(!cursor.compareAndSet(nextSequence,nextSequence1));// CAS成功拿到槽位写入数据消费者通过SequenceBarrier协调进度// SequenceBarrier的核心逻辑longavailableSequencemin(producerCursor,allDependentConsumerSequences);// 返回所有依赖消费者中最小的sequence值// 确保消费者不会超越其依赖者没有锁没有条件变量没有线程阻塞。 所有协调都通过原子操作和内存屏障完成。CPU不需要陷入内核态线程不需要被挂起再唤醒整个过程在用户态以纳秒级完成。五、Disruptor第三刀缓存行填充消灭伪共享这是Disruptor最隐蔽、也最致命的优化。5.1 什么是伪共享CPU的缓存行通常是64字节。CPU读取内存时不是按字节读而是一整箱64字节一起搬到L1/L2缓存。假设两个独立的long变量各8字节恰好落在同一个64字节缓存行内缓存行 [64字节] ┌──────────────────────────────────────┐ │ x (8B) │ padding │ y (8B) │ padding │ │ 线程A写x → 整个缓存行失效 → 线程B读y必须重新从主存加载 │ └──────────────────────────────────────┘线程A写x线程B读y逻辑上毫无关系。但因为它们共享同一个缓存行核心A修改x后核心B的缓存行被标记为无效。线程B下次读y时必须穿越整个内存总线去主存重新加载64字节。两个线程各干各的却被迫不断同步缓存——这就是伪共享。 它让多线程性能不升反降且极难通过常规手段发现。5.2 Disruptor的解决方案Disruptor在Sequence对象上做了缓存行填充确保每个核心变量独占一个完整缓存行publicclassSequence{// 核心数据privatevolatilelongvalue;// 8字节// 左侧填充7个long × 8字节 56字节privatelongp1,p2,p3,p4,p5,p6,p7;// 右侧填充7个long × 8字节 56字节privatelongp9,p10,p11,p12,p13,p14,p15;// 总计56 8 56 120字节超过一个缓存行(64B)// 实际实现中会精确填充到64字节边界}8字节的数据用120字节包裹。 看起来极度浪费内存但换来的是每个线程操作自己的Sequence时缓存行绝不会被其他线程的操作波及。Disruptor在RingBuffer、WaitStrategy、生产者、消费者等所有组件中都贯彻了这一原则。这不是一个点的优化是整个框架的设计哲学。5.3 实测对比不做缓存行填充的版本7个线程各操作一个独立计数器吞吐量可能只有填充版本的1/3到1/5。因为伪共享导致的缓存行失效风暴会让CPU大量时间花在总线传输上而非实际计算。六、批处理最后一块拼图Disruptor支持批量消费消费者一次可以处理一批事件而非逐个处理// EventHandler的批量处理入口publicvoidonEvent(Tevent,longsequence,booleanendOfBatch){if(endOfBatch){// 一批处理完毕统一提交batchCommit();}}批量处理将多次函数调用、多次内存屏障合并为一次。假设一次处理10个事件逐个处理10次方法调用 10次内存屏障批量处理1次方法调用 1次内存屏障固定开销被均摊吞吐量线性提升。七、等待策略延迟与CPU的博弈Disruptor提供四种等待策略本质是消费者等新数据时的行为选择策略机制延迟CPU消耗适用场景BlockingWaitStrategy锁条件变量最高最低异步日志、对延迟不敏感SleepingWaitStrategy自旋yieldparkNanos中等低异步日志、通用场景YieldingWaitStrategy自旋100次yield低中低延迟、线程数CPU核数BusySpinWaitStrategy纯自旋最低极高绑定核心、线程数物理核数对于要求极致低延迟的金融场景YieldingWaitStrategy或BusySpinWaitStrategy是标配。但要注意BusySpin会疯狂占满一个CPU核心只有在线程绑定核心且核心数富余时才能使用。八、多消费者依赖图Disruptor独有的能力BlockingQueue只能做到一对一或广播Disruptor可以构建消费者之间的依赖关系// C1、C2、C3并行执行C4必须等C1、C2、C3全部完成disruptor.handleEventsWith(c1,c2,c3).then(c4);这在业务上意义巨大。比如一个订单事件需要同时做风控校验C1、库存扣减C2、日志记录C3三者并行完成后才能触发发货通知C4。用BlockingQueue实现这个逻辑需要额外的CountDownLatch或CompletableFuture协调复杂度和性能开销都远高于Disruptor原生支持。九、何时该用Disruptor何时该用BlockingQueueDisruptor的适用边界非常清晰适合Disruptor的场景超高并发万级以上TPS对延迟极度敏感微秒级生产者和消费者模式固定、事件类型单一可以接受预分配内存的固定容量适合BlockingQueue的场景并发量中等千级以下需要动态扩容的无界队列业务逻辑复杂、需要多种队列语义优先级、延迟等团队对Disruptor不熟悉维护成本高Disruptor的学习曲线陡峭RingBuffer大小必须是2的幂、必须预定义事件类型、消费者必须提前注册。一旦业务需求频繁变化重构成本远高于换一个BlockingQueue实现。十、总结一下Disruptor比BlockingQueue快不是某一个点的胜利是系统性的架构碾压环形数组预分配 → 消除动态内存分配和GC实现零拷贝语义SequenceCAS → 消灭锁所有协调在用户态原子操作完成缓存行填充 → 消灭伪共享每个线程的核心数据独占缓存行位运算索引 → 消除取模运算开销CPU友好批量处理 → 均摊固定开销吞吐量线性放大这五项设计环环相扣缺一不可。BlockingQueue的锁和动态内存分配是基因层面的限制而Disruptor从存储结构、并发模型到内存布局全部重新设计。它不是在传统队列上做优化而是从第一性原理出发重新定义了队列在高并发场景下应该长什么样。关注技术号获取更多技术干货 ! Disruptor环形队列为什么比BlockingQueue快？零拷贝+伪共享+缓存行填充
❃博主首页 「程序员1970」同名公众号「程序员1970」☠博主专栏 mysql高手elasticsearch高手源码解读java核心面试攻关文章目录一、性能数据二、BlockingQueue的性能天花板在哪里三、Disruptor第一刀环形数组预分配实现零拷贝四、Disruptor第二刀Sequence机制彻底消灭锁五、Disruptor第三刀缓存行填充消灭伪共享5.1 什么是伪共享5.2 Disruptor的解决方案5.3 实测对比六、批处理最后一块拼图七、等待策略延迟与CPU的博弈八、多消费者依赖图Disruptor独有的能力九、何时该用Disruptor何时该用BlockingQueue十、总结一下一、性能数据LMAX交易所基于Disruptor构建的交易系统订单处理能力达到每秒600万TPS。而同样场景下使用传统BlockingQueue直接*。这不是量级的差距是维度的碾压。要理解这种差距从何而来必须拆解Disruptor底层三个核心设计环形数组零拷贝、伪共享消除、缓存行填充。每一项都直击传统队列的性能命脉。二、BlockingQueue的性能天花板在哪里BlockingQueue的实现无论ArrayBlockingQueue还是LinkedBlockingQueue本质上依赖两样东西锁和动态内存分配。// ArrayBlockingQueue内部核心逻辑简化finalReentrantLocklock;privatefinalObject[]items;// 动态扩容时需要Arrays.copyOfpublicvoidput(Ee)throwsInterruptedException{lock.lock();// 加锁线程阻塞try{// 满了就等待while(countitems.length)notFull.await();items[putIndex]e;// 写入}finally{lock.unlock();}}三个致命问题第一锁竞争带来线程上下文切换。 锁的本质是让线程进入内核态等待涉及用户态到内核态的切换开销。高并发下大量线程在锁上排队CPU时间片被白白消耗在调度而非计算上。第二链表/数组扩容带来GC压力。 LinkedBlockingQueue基于链表节点每个节点都是一个独立对象频繁创建和回收直接压迫垃圾回收器。ArrayBlockingQueue扩容时的Arrays.copyOf更是一次性搬运整块内存。第三数据搬移导致缓存失效。 链表节点在堆内存中离散分布CPU缓存无法有效预取每次访问都可能触发cache miss。三、Disruptor第一刀环形数组预分配实现零拷贝Disruptor的底层是一个固定大小的Object[]数组——RingBuffer。但它和普通数组不同做到了两件事预分配和永不回收。// RingBuffer初始化时一次性创建所有事件对象Object[]entriesnewObject[bufferSize];// bufferSize必须是2的幂for(inti0;ibufferSize;i){entries[i]eventFactory.newInstance();// 预填充}这意味着什么事件对象在系统启动时就全部创建完毕运行期间零new操作。 没有new就没有GC没有GC就没有Stop-The-World停顿。传统队列每一次入队都可能触发一次minor GC累积起来就是吞吐量的隐形杀手。更精妙的是指针无限递增、永不回收的设计。每个槽位用一个long类型的sequence标识通过位运算定位// 数组长度为2^n取模运算变成位运算intindex(int)(sequence(bufferSize-1));// 例如 bufferSize1024, sequence1025// 1025 1023 1直接定位到index1sequence是long类型几乎不可能溢出。槽位被反复覆写使用不存在旧对象被回收的过程——数据根本不搬移只是原地覆写。这就是Disruptor语境下零拷贝的真正含义不是数据在内存间零拷贝传输而是消除了对象生命周期中的拷贝和回收开销。对比BlockingQueue的Arrays.copyOf两者的内存操作量级完全不在一个层次。四、Disruptor第二刀Sequence机制彻底消灭锁传统队列用锁保护共享状态Disruptor用CASSequence替代。RingBuffer本身不维护头指针和尾指针的概念。它只有一个cursor生产者的Sequence。每个消费者也有自己的Sequence表示自己已消费到的位置。生产者cursor 5表示已发布到第5个槽位 消费者Asequence 3表示已处理到第3个槽位 消费者Bsequence 2表示已处理到第2个槽位单生产者模式下生产者直接nextSequence cursor 1无需CAS无竞争无锁。多生产者模式下多个生产者通过CAS竞争递增同一个nextSequence// 多生产者竞争下一个槽位longnextSequence;do{nextSequencecursor.get();}while(!cursor.compareAndSet(nextSequence,nextSequence1));// CAS成功拿到槽位写入数据消费者通过SequenceBarrier协调进度// SequenceBarrier的核心逻辑longavailableSequencemin(producerCursor,allDependentConsumerSequences);// 返回所有依赖消费者中最小的sequence值// 确保消费者不会超越其依赖者没有锁没有条件变量没有线程阻塞。 所有协调都通过原子操作和内存屏障完成。CPU不需要陷入内核态线程不需要被挂起再唤醒整个过程在用户态以纳秒级完成。五、Disruptor第三刀缓存行填充消灭伪共享这是Disruptor最隐蔽、也最致命的优化。5.1 什么是伪共享CPU的缓存行通常是64字节。CPU读取内存时不是按字节读而是一整箱64字节一起搬到L1/L2缓存。假设两个独立的long变量各8字节恰好落在同一个64字节缓存行内缓存行 [64字节] ┌──────────────────────────────────────┐ │ x (8B) │ padding │ y (8B) │ padding │ │ 线程A写x → 整个缓存行失效 → 线程B读y必须重新从主存加载 │ └──────────────────────────────────────┘线程A写x线程B读y逻辑上毫无关系。但因为它们共享同一个缓存行核心A修改x后核心B的缓存行被标记为无效。线程B下次读y时必须穿越整个内存总线去主存重新加载64字节。两个线程各干各的却被迫不断同步缓存——这就是伪共享。 它让多线程性能不升反降且极难通过常规手段发现。5.2 Disruptor的解决方案Disruptor在Sequence对象上做了缓存行填充确保每个核心变量独占一个完整缓存行publicclassSequence{// 核心数据privatevolatilelongvalue;// 8字节// 左侧填充7个long × 8字节 56字节privatelongp1,p2,p3,p4,p5,p6,p7;// 右侧填充7个long × 8字节 56字节privatelongp9,p10,p11,p12,p13,p14,p15;// 总计56 8 56 120字节超过一个缓存行(64B)// 实际实现中会精确填充到64字节边界}8字节的数据用120字节包裹。 看起来极度浪费内存但换来的是每个线程操作自己的Sequence时缓存行绝不会被其他线程的操作波及。Disruptor在RingBuffer、WaitStrategy、生产者、消费者等所有组件中都贯彻了这一原则。这不是一个点的优化是整个框架的设计哲学。5.3 实测对比不做缓存行填充的版本7个线程各操作一个独立计数器吞吐量可能只有填充版本的1/3到1/5。因为伪共享导致的缓存行失效风暴会让CPU大量时间花在总线传输上而非实际计算。六、批处理最后一块拼图Disruptor支持批量消费消费者一次可以处理一批事件而非逐个处理// EventHandler的批量处理入口publicvoidonEvent(Tevent,longsequence,booleanendOfBatch){if(endOfBatch){// 一批处理完毕统一提交batchCommit();}}批量处理将多次函数调用、多次内存屏障合并为一次。假设一次处理10个事件逐个处理10次方法调用 10次内存屏障批量处理1次方法调用 1次内存屏障固定开销被均摊吞吐量线性提升。七、等待策略延迟与CPU的博弈Disruptor提供四种等待策略本质是消费者等新数据时的行为选择策略机制延迟CPU消耗适用场景BlockingWaitStrategy锁条件变量最高最低异步日志、对延迟不敏感SleepingWaitStrategy自旋yieldparkNanos中等低异步日志、通用场景YieldingWaitStrategy自旋100次yield低中低延迟、线程数CPU核数BusySpinWaitStrategy纯自旋最低极高绑定核心、线程数物理核数对于要求极致低延迟的金融场景YieldingWaitStrategy或BusySpinWaitStrategy是标配。但要注意BusySpin会疯狂占满一个CPU核心只有在线程绑定核心且核心数富余时才能使用。八、多消费者依赖图Disruptor独有的能力BlockingQueue只能做到一对一或广播Disruptor可以构建消费者之间的依赖关系// C1、C2、C3并行执行C4必须等C1、C2、C3全部完成disruptor.handleEventsWith(c1,c2,c3).then(c4);这在业务上意义巨大。比如一个订单事件需要同时做风控校验C1、库存扣减C2、日志记录C3三者并行完成后才能触发发货通知C4。用BlockingQueue实现这个逻辑需要额外的CountDownLatch或CompletableFuture协调复杂度和性能开销都远高于Disruptor原生支持。九、何时该用Disruptor何时该用BlockingQueueDisruptor的适用边界非常清晰适合Disruptor的场景超高并发万级以上TPS对延迟极度敏感微秒级生产者和消费者模式固定、事件类型单一可以接受预分配内存的固定容量适合BlockingQueue的场景并发量中等千级以下需要动态扩容的无界队列业务逻辑复杂、需要多种队列语义优先级、延迟等团队对Disruptor不熟悉维护成本高Disruptor的学习曲线陡峭RingBuffer大小必须是2的幂、必须预定义事件类型、消费者必须提前注册。一旦业务需求频繁变化重构成本远高于换一个BlockingQueue实现。十、总结一下Disruptor比BlockingQueue快不是某一个点的胜利是系统性的架构碾压环形数组预分配 → 消除动态内存分配和GC实现零拷贝语义SequenceCAS → 消灭锁所有协调在用户态原子操作完成缓存行填充 → 消灭伪共享每个线程的核心数据独占缓存行位运算索引 → 消除取模运算开销CPU友好批量处理 → 均摊固定开销吞吐量线性放大这五项设计环环相扣缺一不可。BlockingQueue的锁和动态内存分配是基因层面的限制而Disruptor从存储结构、并发模型到内存布局全部重新设计。它不是在传统队列上做优化而是从第一性原理出发重新定义了队列在高并发场景下应该长什么样。关注技术号获取更多技术干货 !