初识Disruptor

背景

Disruptor是英国外汇交易公司LMAX开发的一个高性能队列，研发的初衷是解决内存队列的延迟问题（在性能测试中发现竟然与I/O操作处于同样的数量级）。基于Disruptor开发的系统单线程能支撑每秒600万订单，2010年在QCon演讲后，获得了业界关注。2011年，企业应用软件专家Martin Fowler专门撰写长文介绍。同年它还获得了Oracle官方的Duke大奖。

目前，包括Apache Storm、Camel、Log4j 2在内的很多知名项目都应用了Disruptor以获取高性能。

• 并发编程（多线程）
  1. 并发编程的3个重要概念三个概念

1.1.1、 原子性

原子性：即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。

1.1.2、可见性

可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

1．1.3、有序性

有序性：即程序执行的顺序按照代码的先后顺序执行

1.2、多线程的优缺点

1.2.1、 优点

1. 充分利用硬件资源。由于线程是cpu的基本调度单位，所以如果是单线程，那么最多只能同时在一个处理器上运行，意味着其他的CPU资源都将被浪费。而多线程可以同时在多个处理器上运行，只要各个线程间的通信设计正确，那么多线程将能充分利用处理器的资源。

2. 结构优雅。多线程程序能将代码量巨大，复杂的程序分成一个个简单的功能模块，每块实现复杂程序的一部分单一功能，这将会使得程序的建模，测试更加方便，结构更加清晰，更加优雅。

3. 简化异步处理。为了避免阻塞，单线程应用程序必须使用非阻塞I/O,这样的I/O复杂性远远高于同步I/O，并且容易出错。

1.2.2、 缺点

1. 线程安全：由于统一进程下的多个线程是共享同样的地址空间和数据的，又由于线程执行顺序的不可预知性，一个线程可能会修改其他线程正在使用的变量，这一方面是给数据共享带来了便利；另一方面，如果处理不当，会产生脏读，幻读等问题，好在Java提供了一系列的同步机制来帮助解决这一问题，例如内置锁。

2. 活跃性问题。可能会发生长时间的等待锁，甚至是死锁。

3. 性能问题。 线程的频繁调度切换会浪费资源，同步机制会导致内存缓冲区的数据无效，以及增加同步流量。

 

1.3、如何保证线程安全

1.3.1、使用锁

图1.1锁示意图

https://blog.csdn.net/zqz_zqz/article/details/70233767/（各种锁的介绍）

 

1.3.2、使用原子变量CAS (Compare and Swap)

图1.2 通过原子变量CAS实现线程安全

https://www.cnblogs.com/qjjazry/p/6581568.html

https://www.cnblogs.com/xckxue/p/8682059.html（CAS介绍）

1.4、disruptor是怎么做的

disruptor在需要保证线程安全的地方，用到了CAS操作

二、伪共享

2.1、什么是共享

下图是计算的基本结构。L1、L2、L3分别表示一级缓存、二级缓存、三级缓存，越靠近CPU的缓存，速度越快，容量也越小。所以L1缓存很小但很快，并且紧靠着在使用它的CPU内核；L2大一些，也慢一些，并且仍然只能被一个单独的CPU核使用；L3更大、更慢，并且被单个插槽上的所有CPU核共享；最后是主存，由全部插槽上的所有CPU核共享。

图2.1 计算机CPU与缓存示意图

 

当CPU执行运算的时候，它先去L1查找所需的数据、再去L2、然后是L3，如果最后这些缓存中都没有，所需的数据就要去主内存拿。走得越远，运算耗费的时间就越长。所以如果你在做一些很频繁的事，你要尽量确保数据在L1缓存中。

另外，线程之间共享一份数据的时候，需要一个线程把数据写回主存，而另一个线程访问主存中相应的数据。

 

下面是从CPU访问不同层级数据的时间概念:

从CPU到	大约需要的CPU周期	大约需要的时间
主存		约60-80ns
QPI 总线传输(between sockets, not drawn)		约20ns
L3 cache	约40-45 cycles	约15ns
L2 cache	约10 cycles	约3ns
L1 cache	约3-4 cycles	约1ns
寄存器	1 cycle

可见CPU读取主存中的数据会比从L1中读取慢了近2个数量级。

2.2、缓存行

Cache是由很多个cache line组成的。每个cache line通常是64字节，并且它有效地引用主内存中的一块儿地址。一个Java的long类型变量是8字节，因此在一个缓存行中可以存8个long类型的变量。

CPU每次从主存中拉取数据时，会把相邻的数据也存入同一个cache line。

在访问一个long数组的时候，如果数组中的一个值被加载到缓存中，它会自动加载另外7个。因此你能非常快的遍历这个数组。事实上，你可以非常快速的遍历在连续内存块中分配的任意数据结构。

图2.2缓存行示意图

2.3、什么是伪共享

缓存系统中是以缓存行（cache line）为单位存储的。缓存行是2的整数幂个连续字节，一般为32-256个字节。最常见的缓存行大小是64个字节。当多线程修改互相独立的变量时，如果这些变量共享同一个缓存行，就会无意中影响彼此的性能，这就是伪共享。缓存行上的写竞争是运行在SMP系统中并行线程实现可伸缩性最重要的限制因素。有人将伪共享描述成无声的性能杀手，因为从代码中很难看清楚是否会出现伪共享。

为了让可伸缩性与线程数呈线性关系，就必须确保不会有两个线程往同一个变量或缓存行中写。两个线程写同一个变量可以在代码中发现。为了确定互相独立的变量是否共享了同一个缓存行，就需要了解内存布局，或找个工具告诉我们。Intel VTune就是这样一个分析工具。本文中我将解释Java对象的内存布局以及我们该如何填充缓存行以避免伪共享。

图2.3伪示意图

图2.3说明了伪共享的问题。在核心1上运行的线程想更新变量X，同时核心2上的线程想要更新变量Y。不幸的是，这两个变量在同一个缓存行中。每个线程都要去竞争缓存行的所有权来更新变量。如果核心1获得了所有权，缓存子系统将会使核心2中对应的缓存行失效。当核心2获得了所有权然后执行更新操作，核心1就要使自己对应的缓存行失效。这会来来回回的经过L3缓存，大大影响了性能。如果互相竞争的核心位于不同的插槽，就要额外横跨插槽连接，问题可能更加严重。

2.4、disruptor解决方案－神奇的缓存行填充（填充策略）

Disruptor避开了Cache line伪共享这个问题，至少对于缓存行大小是64字节或更少的处理器架构来说是这样的（译注：有可能处理器的缓存行是128字节，那么使用64字节填充还是会存在伪共享问题），通过增加补全来确保ring buffer的序列号不会和其他东西同时存在于一个缓存行中。

因此没有伪共享，就没有和其它任何变量的意外冲突，没有不必要的缓存未命中。

https://blog.csdn.net/qq_27680317/article/details/78486220?locationNum=5&fps=1（一篇对伪共享、缓存行填充和cpu缓存讲解的文章）