别看唐探了，Q(ueue)的真相在这里（二）

2. 无锁
只选好 ringbuffer 是不够的，在高并发下，多个生产者/消费者极有可能争用 ringbuffer 的 同一个 index，如下图示：

 
为了避免这种情况，最容易想到的是加锁，但显然加锁会存在严重的性能问题：

1. 线程如果争用不到锁失败，会阻塞（由用户态进入内核态），唤醒时又会从内核态进入用户态，我们知道这种不断地在用户态和内核态间进行切换的操作是非常昂贵的
2. 线程 cache miss 的开销，一开始线程可能被分配在 cpu core 1 上，但经过阻塞，唤醒后又被调度到了 cpu core 2 上，导致原来在 core 1 上加载的缓存无用武之地， 线程在 core 2 又得重新从内存加载数据
   综上所述使用锁是不行的，一种有效的方式是使用 CAS 自旋不断尝试获取对应的 index，这种方式也就是我们所说的无锁

 
也许有人担心 CAS 性能比较低，我们可以用 JDK 8 之后对 atomic 类引入的 unsafe 的 getAndAddInt 方法来替换，如下:

public final int incrementAndGet() {
   return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}

它使用的是 CPU 的 fetch-and-add 指令，性能上比 CAS 要强很多（实测是 6 倍于 CAS 的性能，见文末参考链接），skywalking 的队列就是用的 getAndInt 来代替 CAS，达到了很高的性能。

 
不愧是通过了我们简历筛选的男人，那么 JDK 里的内置队列能否符合这样的条件呢
 
不能，我们先来看看 JDK 内置队列有哪些，以及它们有哪些特点

可以看到，最接近高性能队列「有界环形数组」和「无锁」这两个特性的只有 ArrayBlockingQueue 这一个队列，但很可惜它虽然用的 ringbuffer，但是是有锁的，而且它的生产者和消费者共用同一把锁（可重入锁 Reentrantlock），这意味着生产与消费无法同时进行，显然无法满足我们的要求。我们可以对 ArrayBlockingQueue 进行改造，把此锁干掉，用无锁比如 CAS 的方式来实现，这样不就解决了吗，高性能队列 disruptor就是这么干的
 
小伙子果然不错，居然用过 disruptor，看得出来你对 disruptor 还挺了解的，说得头头是道,那我考你两个问题，这两个问题如果答得不错，直接发 offer

1. disruptor 确实满足了你说的「使用了大小为 2^n 的 ringbuffer 数组」和「无锁」两个特性，除此之外它还利用了哪些优化的点，在我看来你的这两个点确实重要，但最关键也是我最在意的一个点还没有提到
2. disruptor 是阻塞的吗，也就是说如果 ringbuffer 满了会不会阻塞向 ringbuffer 投递事件的业务线程
    
   第一题，disruptor 在初始化的时候为数组填充了所有事件类对象，这些对象不会消亡，也就避免了 GC，不同的事件只是值不一样而已，所以新增的事件会复用数组中的对象，只是将其属性值修改而已，另外这么做还有一个好处：避免 在高并发时 CPU 分配大量的对象造成 CPU 使用使用率及内存飙升

第二题，是阻塞的，所以如果要把 disruptor 应用到我们开头的设计架构中，可能 cobar 执行线程会有阻塞风险，想要不阻塞可以使用 skywalking 的队列，它是非阻塞的，性能也很给力（正常 cobar 压测5.5w/s，而用 skywalking 的队列只损失 1.8%，可以接受）
 
第一题你的回答是没问题的，但不是我想要的答案，我给你提示一下，在 ArrayBlockingQueue 中，连续定义了这三个变量

/** items index for next take, poll, peek or remove */
int takeIndex;

/** items index for next put, offer, or add */
int putIndex;

/** Number of elements in the queue */
int count;

在多线程的情况下会存在什么瓶颈？

第二题回答完全错误，实际上 disruptor 是有非阻塞方法的，你用它的话性能几乎没有损失 (disruptor 最大特点是高性能，其 LMAX 架构可以获得每秒6百万订单，用1微秒的延迟获得吞吐量为 100K+)
 
你看看，明明可以用更好的 disruptor，却要用 skywalking 的损失了性能 1.8% 的次优队列，虽然思路也不错，但从中可以看出你的你没有仔细看透 disruptor，很遗憾，这次面试就到此为止吧，不过鉴于你之前的表现不错，也让我转身了，我不妨指点你一下，log4j2 也用了 disruptor，你想想 log4j2 是如此常见的组件，是各大公司的标配，如果日志生产的 ringbuffer 队列满了，按你的说法岂不是会影响业务线程？建议回去好好研读下 log4j2 还有 disruptor 的源码，半年后再见
 
少扯这些没用的，好好回去修炼内功吧，慢走不送

小伙子，又见面了，上次临走时问的两个问题思考的如何了
 
第一个问题，按大佬的提示我查阅了一些资料，其实大佬想听的是伪共享和缓存行填充吧
 
确实如此，那你给我解释下什么是伪共享，又是如何用缓存行填充来解决伪共享的呢
 
在前文中我们已经知道了 cacheline 的原理，内存的最小读取和写入单元是 64 字节的 cacheline，而 ArrayBlockingQueue 的如下三个属性是连接定义的，

int takeIndex;
int putIndex;
int count;

表现在内存中就是连续分配的空间，这样的话它们极有可能一起作为一个 cacheline 加载到 cache 中

 
假设线程 A 执行入队操作，就会修改 putIndex，根据 CPU 的缓存一致性协议（如 MESI 协议），修改 putIndex 会导致其所在的 cacheline 都失效，此时假设线程 B 执行出出队操作，需要读取 takeIndex，但由于其所在的 cacheline 已经失效，所以 CPU-2 必须重新去内存中读取 takeIndex 所在的 cacheline，而我们知道 CPU 中的三级缓存与内存效率相差几十上百倍，这样的话在多线程环境下由于 cacheline 频繁失效毫无疑问会造成严重的性能问题，这就是我们所说的伪共享。
 
恩，解释得不错，那怎么解决呢
 
解决方式就要按大佬所说的缓存行填充来解决，在 takeIndex, 前后添加 7 个 long 类型的属性变量，就可以保证 takeIndex 和 putIndex 不在同一个 cacheline 上了，这样针对 takeIndex 和 putIndex 的修改就不会互相影响对方了

 3
 
不错，能否举例一下 disruptor 中对缓存行填充以避免伪共享的问题，在 disruptor 用到很多这样的例子

 
我们先来看下 ringbuffer 的定义

abstract class RingBufferPad
{

 protected long p1, p2, p3, p4, p5, p6, p7;

}
abstract class RingBufferFields<E> extends RingBufferPad
{

private final long indexMask;

private final Object[] entries;

protected final int bufferSize;

protected final Sequencer sequencer;

}

public final class RingBuffer<E> extends RingBufferFields<E> implements Cursored, EventSequencer<E>, EventSink<E>

{

 protected long p1, p2, p3, p4, p5, p6, p7;

}

可以看到在 RingBufferFields 前后分别填充了 7 个 long 类型的变量，这 14 个变量没有任何实际用途，只是用来做缓存行填充之用。

 
可以看到填充之后无论怎么加载缓存行，缓存行都没有要更新的数据，另外注意到 RingBufferFields 里面定义的变量都是 final 的，意味着第一次写入之后就不会再被修改，也就意味着一旦加载入 CPU Cache 中，就不会被换出 Cache 了，也就是说这些值的读取都一直会是 CPU Cache 的访问速度，而不是内存的访问速度
 
第一个问题过关了，接下来说说第二个问题吧， disruptor 的队列满了之后会阻塞业务线程吗
 
disruptor 的 ringbuffer 提供了两个方法，一个是 publishEvent，这个方法如果在 ringbuffer 满了之后继续往里添加事件是会阻塞的，而另一个 tryPublishEvent 方法则不会，队列满了之后会返回 false，业务线程还是可以继续执行滴，log4j2 就是用了这个方法这样根据其返回值为 false 即可判断 ringbuffer 满了，我们就可以做相当的处理了（比如丢弃 log 事件）
 
看得出来小伙子确实用心读了源码，过去半年表现进步明显哦，恭喜你顺利进入二面
 
总结
disruptor 是 LMAX 公司开源的一款高性能队列，每秒支持 600w 的吞吐量，相当于用 1 微秒的延迟就获取了 100K+ 的吞吐量，性能极高，简单总结一下它主要用到了以下五个手段：

1. 环形数组：ringBuffer，由于数组在内存空间中是连续分配的，而内存换入换出的最小单元是 64kb 的 cacheline,所以一次性会把数组的多个元素写入 CPU Cache 中以提高效率，另外对数组的大小是有要求的，为了支持位运算取模以提高效率，必须将数组大小设置为2^n。
2. 数组对象预填充，在 disruptor 初始化时为就为数组的每个坑位都初始化填充了事件对象，这些对象不会消失也就避免了频繁 GC，之后生产者要新增事件对象，也会复用相应坑位的事件对象，只是修改其对象属性而已，通过预分配对象的方式，避免了高并发下频繁分配对象导致的 CPU 和内存飙升。
3. 缓存行填充避免伪共享，这也是 diruptor 最大的亮点，在 disruptor 中你可以看到很多这样的例子，利用缓存行填充可以保证不会造成 cacheline 失效从而造成频繁从内存读取导致的性能瓶颈
4. 使用 CAS 自旋而不是 Reentrantlock 这样重量级锁来获取生产者/消费者的 index，避免了锁的开销，提升并发能力。
5. 使用 volatile 而不是锁来修改同一个变量，在 disruptor 中生产者会竞争数组的 index 坑位（用的 Sequence类的 value 值），disruptor 使用了 volatile 而不是锁来保证了变量的可见性
   另外 disruptor 提供了阻塞（publishEvent） 和非阻塞（tryPublishEvent）两种方法，针对我们文章开头 cobar 的使用场景，建议使用 tryPublishEvent 这种非阻塞的方式来向 ringbuffer 投递事件，不然一旦阻塞会导致线上 cobar 执行线程停顿的重大故障！

另外 disruptor 到底有多强悍，可能看听数据大家没有感觉，那我们来看一张针对 log4j2 的压测图

 
log4j2 总共有三种工作机制，全局异步（Loggers all async），Appender 异步( Async Appender)以及同步（Sync），可以看到全局异步最快，几乎是 Appender 异步的 10 倍以上，为什么同样是异步，性能相差这么大，因为全局异步用的是 disruptor ，而 Appender 异步用的是 ArrayBlockingQueue，可以看到 disruptor 被称为高性能队列之王的名头可不是盖的。

另外除了 disruptor，大家也可以看看 skywaking 的队列，它的性能虽然没有 disruptor 这么强，但对一般的业务场景也是足够的（在我司 cobar 压测 5.5w/s，使用了 skywalking 后仅损失了 1.8%，也是很强悍的），它也是阻塞的，另外它在队列满的时候可以选择「阻塞」,「覆盖」,「忽略」三种策略，我们选择了覆盖。

··············  END  ··············

文章转自公众号：码海