二、并发框架disruptor-性能分析之锁的问题

1、说明

第一篇主要介绍了什么是disruptor，以及和AQS的性能对比，这一篇主要分析下系统性能，影响性能的瓶颈，以及disruptor是如何处理的。

2、性能延迟的原因

我们经常说的队列，指的是系统内部的内存队列。而我们常用的线程安全的Java的内置队列如下表所示

队列的底层一般分成三种：数组、链表和堆。其中，堆一般情况下是为了实现带有优先级特性的队列，暂且不考虑。

我们就从数组和链表两种数据结构来看，基于数组线程安全的队列，比较典型的是ArrayBlockingQueue，它主要通过加锁的方式来保证线程安全；基于链表的线程安全队列分成LinkedBlockingQueue和ConcurrentLinkedQueue两大类，前者也通过锁的方式来实现线程安全，而后者以及上面表格中的LinkedTransferQueue都是通过原子变量compare and swap（以下简称“CAS”）这种不加锁的方式来实现的。

通过不加锁的方式实现的队列都是无界的（无法保证队列的长度在确定的范围内）；而加锁的方式，可以实现有界队列。在稳定性要求特别高的系统中，为了防止生产者速度过快，导致内存溢出，只能选择有界队列；同时，为了减少Java的垃圾回收对系统性能的影响，会尽量选择array/heap格式的数据结构。这样筛选下来，符合条件的队列就只有ArrayBlockingQueue。

ArrayBlockingQueue在实际使用过程中，会因为加锁和伪共享等出现严重的性能问题，我们下面来分析一下。

3.锁的问题

并发 01
想象有两个线程尝试修改同一个变量value：

- 情况一：线程１先到达
变量value的值变为”b”。
然后当线程２到达时，变量value的值变为”c”。

- 情况二：线程２先到达
变量value的值变为”c”。
然后当线程１到达时，值变为”b”。

- 情况三：线程１与线程２交互
线程２得到值＂a＂然后赋给本地变量myValue。
线程１改变value的值为”b”。
然后线程２进来并把变量value的值改为”c”

情况三显然是唯一一个是错误的，除非除非你认为wiki编辑的幼稚做法是正确的（Google Code Wiki，我一直在关注你）。其他两种情况主要是看你的意图和想要达到的效果。线程２可能不会关心变量value的值是什么，主要的意图就是在更改变量而不管它原来的值是什么，在这种前提下，情况一和情况二都是正确的。

但是如果线程２只是想把＂a＂改为”c”，那么情况二和三都不正确。假定线程２想把值设为”c”,有几种办法可以解决这个问题：

• 办法一：悲观锁
  
  悲观锁和乐观锁这两个词通常在我们谈论数据库读写时经常会用到，但原理可以应用到在获得一个对象的锁的情况。

只要线程２一获得Entry 的互斥锁，它就会阻击其它线程去改变它，然后它就可以随意做它要做的事情，设置值，然后做其它事情。

你可以想象这里非常耗性能的，因为其它线程在系统各处徘徊着准备要获得锁然后又阻塞。线程越多，系统的响应性就会越慢．

• 办法二：乐观锁

在这种情况，当线程２需要去写Entry时才会去锁定它．它需要检查Entry自从上次读过后是否已经被改过了。如果线程１在线程２读完后到达并把值改为”b”,线程２读到了这个新值，线程２不会把＂c＂写到Entry里并把线程１所写的数据覆盖．线程２会重试（重新读新的值，与旧值比较，如果相等则直接更改c）,这里在线程２不会关心新的值是什么的情况．或者线程２会抛出一个异常，或者会返回一个某些字段已更新的标志，这是在期望把”a”改为”c”的情况．举一个第二种情况的例子，如果你和另外一个用户同时更新一个Ｗiki的页面，你会告诉另外一个用户的线程 Thread 2，它们需要重新加载从Thread1来新的变化，然后再提交它们的内容。

• 潜在的问题：死锁
  
  锁定会带来各种各样的问题，比如死锁，想象有２个线程需要访问两个资源
  如果你滥用锁技术，两个锁都在获得锁的情况下尝试去获得另外一个锁，那就是你应该重启你的电脑的时候了。（校注：作者还挺幽默）
  很明确的一个问题：锁技术是慢的．．
  关于锁就是它们需要操作系统去做裁定。线程就像两姐妹在为一个玩具在争吵，然后操作系统就是能决定他们谁能拿到玩具的父母，就像当你跑向你父亲告诉他你的姐姐在你玩着的时候抢走了你的变形金刚－他还有比你们争吵更大的事情去担心，他或许在解决你们争吵之前要启动洗碗机并把它摆在洗衣房里。如果你把你的注意力放在锁上，不仅要花时间来让操作系统来裁定。Disruptor论文中讲述了我们所做的一个实验。这个测试程序调用了一个函数，该函数会对一个64位的计数器循环自增5亿次。当单线程无锁时，程序耗时300ms。如果增加一个锁（仍是单线程、没有竞争、仅仅增加锁），程序需要耗时10000ms，慢了两个数量级。更令人吃惊的是，如果增加一个线程（简单从逻辑上想，应该比单线程加锁快一倍），耗时224000ms。使用两个线程对计数器自增5亿次比使用无锁单线程慢1000倍。并发很难而锁的性能糟糕。我仅仅是揭示了问题的表面，而且，这个例子很简单。但重点是，如果代码在多线程环境中执行，作为开发者将会遇到更多的困难：
• 代码没有按设想的顺序执行。上面的场景3表明，如果没有注意到多线程访问和写入相同的数据，事情可能会很糟糕。
• 减慢系统的速度。场景3中，使用锁保护代码可能导致诸如死锁或者效率问题。

distruptor是如何处理这种并发产生的锁呢？
大部分的操作为确保是线程安全的（特别是，在多生产者的环境下，更新下一个可用的***）地方，我们使用CAS（Compare And Swap/Set）操作。这是一个CPU级别的指令，它的工作方式有点像乐观锁——CPU去更新一个值，但如果想改的值不再是原来的值，操作就失败，因为很明显，有其它操作先改变了这个值。
CAS操作比锁消耗资源少的多，因为它们不牵涉操作系统，它们直接在CPU上操作。但它们并非没有代价——在上面的试验中，单线程无锁耗时300ms，单线程有锁耗时10000ms，单线程使用CAS耗时5700ms。所以它比使用锁耗时少，但比不需要考虑竞争的单线程耗时多。
对于distruptor如果只有一个生产者，那么系统中的每一个***只会由一个线程写入。这意味着没有竞争、不需要锁、甚至不需要CAS。如果存在多个生产者，唯一会被多线程竞争写入的序号就是 ClaimStrategy 对象里的那个。这也是为什么Entry中的每一个变量都只能被一个消费者写。它确保了没有写竞争，因此不需要锁或者CAS。
总之disruptor相对于传统方式的优点：

• 没有竞争=没有锁=非常快。
• 所有访问者都记录自己的序号的实现方式，允许多个生产者与多个消费者共享相同的数据结构。
• 在每个对象中都能跟踪***（ring buffer，claim Strategy，生产者和消费者），加上神奇的cache line padding，就意味着没有为伪共享和非预期的竞争。