原文链接 作者：Doug Lea 译者：欧振聪 校对：丁一

4 用法

AQS类将上述的功能结合到一起，并且作为一种基于“模版方法模式”^[6]的基类提供给同步器。子类只需定义状态的检查与更新相关的方法，这些方法控制着acquire和 release操作。然而，将AQS的子类作为同步器ADT并不适合，因为这个类必须提供方法在内部控制acquire和release的规则，这些都不应该被用户所看到。所有java.util.concurrent包中的同步器类都声明了一个私有的继承了AbstractQueuedSynchronizer的内部类，并且把所有同步方法都委托给这个内部类。这样各个同步器类的公开方法就可以使用适合自己的名称。 阅读全文

原文：http://blog.codeaholics.org/2011/the-disruptor-lock-free-publishing/

译者：罗立树

假如你生活在另外一个星球，我们最近开源了一套高性能的基于消息传递的开源框架。

下面我给大家介绍一下如何将消息通过Ring buffer在无锁的情况下进行处理。

在深入介绍之前，可以先快速阅读一下Trish发表的文章，该文章介绍了ring buffer和其工作原理。

阅读全文

原文地址：http://blog.trifork.nl/2011/07/20/processing-1m-tps-with-axon-framework-and-the-disruptor/

作者： Allard Buijze  译者：程晓明

LMAX，一家在英国的金融公司，最近开源了其（新型零售金融交易平台的）核心组件之一：Disruptor。这个组件通过删除必须的锁来降低执行开销，且任然保证正确的处理订单。如果你问我，我会说这是一个优美精巧的工程。我尝试把Disruptor应用到Axon控制总线中，就是想看看它到底有多大的潜力。结果相当惊人。

阅读全文

原文地址：http://mechanical-sympathy.blogspot.com/2013/02/cpu-cache-flushing-fallacy.html （因有墙移动到墙内）

作者：Mechanical Sympathy

Even from highly experienced technologists I often hear talk about how certain operations cause a CPU cache to “flush”.  This seems to be illustrating a very common fallacy about how CPU caches work, and how the cache sub-system interacts with the execution cores.  In this article I will attempt to explain the function CPU caches fulfil, and how the cores, which execute our programs of instructions, interact with them.  For a concrete example I will dive into one of the latest Intel x86 server CPUs.  Other CPUs use similar techniques to achieve the same ends. 阅读全文

Martin Fowler在自己网站上写了一篇LMAX架构的文章，在文章中他介绍了LMAX是一种新型零售金融交易平台，它能够以很低的延迟产生大量交易。这个系统是建立在JVM平台上，其核心是一个业务逻辑处理器，它能够在一个线程里每秒处理6百万订单。业务逻辑处理器完全是运行在内存中，使用事件源驱动方式。业务逻辑处理器的核心是Disruptor。

Disruptor它是一个开源的并发框架，并获得2011 Duke’s 程序框架创新奖，能够在无锁的情况下实现网络的Queue并发操作。本文是Disruptor官网中发布的文章的译文（现在被移到了GitHub）。

剖析Disruptor:为什么会这么快

1. 剖析Disruptor:为什么会这么快？(一)锁的缺点
2. 剖析Disruptor:为什么会这么快？(二)神奇的缓存行填充
3. 剖析Disruptor:为什么会这么快？(三)伪共享
4. 剖析Disruptor:为什么会这么快？(四)揭秘内存屏障

Disruptor如何工作和使用

1. 如何使用Disruptor（一）Ringbuffer的特别之处
2. 如何使用Disruptor（二）如何从Ringbuffer读取
3. 如何使用Disruptor（三）写入Ringbuffer
4. 解析Disruptor关系组装
5. Disruptor(无锁并发框架)-发布
6. LMAX Disruptor——一个高性能、低延迟且简单的框架
7. Disruptor Wizard已死，Disruptor Wizard永存！
8. Disruptor 2.0更新摘要
9. 线程间共享数据不需要竞争

Disruptor的应用

1. LMAX的架构
2. 通过Axon和Disruptor处理1M tps

原文地址：http://ifeve.com/dissecting-the-disruptor-writing-to-the-ring-buffer/

作者：Trisha   译者：廖涵  校对：方腾飞

这是 Disruptor 全方位解析（end-to-end view）中缺少的一章。当心，本文非常长。但是为了让你能联系上下文阅读，我还是决定把它们写进一篇博客里。

本文的 重点 是：不要让 Ring 重叠；如何通知消费者；生产者一端的批处理；以及多个生产者如何协同工作。 阅读全文

本文是作者原创，原文发表于InfoQ架构师（二月刊）推荐编辑栏目：http://www.infoq.com/cn/minibooks/architect-feb-10-2013

记得第一次向InfoQ投稿已经是1年前的事情了，当时花了几个星期的时间写了一篇文章“深入分析volatile的实现原理”，准备在自己的博客中发表时，在同事金建法的建议下，怀着试一试的心态投向了InfoQ，庆幸的是半小时后得到InfoQ编辑郑柯采纳的回复，高兴之情无以言表。这也是我第一次在专业媒体上发表文章，而后在InfoQ编辑张龙的不断鼓励和支持下，我陆续在InfoQ发表了几篇并发编程相关的文章，于是便形成了“聊聊并发”专栏，在这个专栏的写作过程中，我得到非常多的成长和帮助，在此非常感谢InfoQ的编辑们。接下来我想分享下我的写作历程和我对写作的看法。

通过写作来学习。不知何时便爱上了写作，翻开自己的博客，从06年到现在已经写了164篇博文。为什么会写博客？因为我的学习方法是每个输入都尽量有所输出，无论是读书，看文章，参加技术讲座，还是看电影，我都会或多或少的总结输出出来，输出形式要么是一篇博客，要么是一篇微博，要么是一篇笔记。我总是在想如果这篇文章我看完了，但是我却说不出他讲的是什么，那我岂不是在浪费时间。自己完全掌握的知识应该是自己能表达出来的知识。 阅读全文

原文地址：The Disruptor Wizard is Dead, Long Live the Disruptor Wizard! 译者：杨帆 校对：丁一

Disruptor Wizard（上一篇中提到的DSL组件）目前已经正式并入Disruptor的代码树当中。既然.net移植版包含了Wizard风格的语法很久了，并且看起来还挺受欢迎，所以为什么还要让人们非得搞两个jar而不是一个？

我跟随Disruptor在术语命名上的变动做出了相应的更新。以前的Customer（消费者），现在叫EventProcessor（事件处理器）和EventHandler（事件句柄）。这样的命名更好的说明了实际上的情况：消费者事实上可以向事件添加附加值。另外，ProducerBarrier（生产者屏障）被合并到Ring Buffer一起，并且Ring Buffer Entry（条目）被改名为Event（事件）。新的命名更贴切了，因为实际上围绕Disruptor的编程模型大部分时候都是基于事件的。

阅读全文

原文：Disruptor 2.0 – All Change Please 译者：杨帆

马丁最近发布了Disruptor的2.0版本，从我们开始将其开源以来发生了很多变化，现在是个时候推出一个正式的里程碑了。马丁的博客上涵盖了这次更新的所有内容，这篇文章的目的是尝试把我以前的博文以新框架的架构转述给大家，因为将它们都重写一遍要耗费很多时间。现在我看到手工绘图的缺点了。

阅读全文

本文属于作者原创，原文发表于InfoQ：http://www.infoq.com/cn/articles/java-memory-model-4

volatile的特性

当我们声明共享变量为volatile后，对这个变量的读/写将会很特别。理解volatile特性的一个好方法是：把对volatile变量的单个读/写，看成是使用同一个锁对这些单个读/写操作做了同步。下面我们通过具体的示例来说明，请看下面的示例代码：

class VolatileFeaturesExample {
    //使用volatile声明64位的long型变量
    volatile long vl = 0L;

    public void set(long l) {
        vl = l;   //单个volatile变量的写
    }

    public void getAndIncrement () {
        vl++;    //复合（多个）volatile变量的读/写
    }

    public long get() {
        return vl;   //单个volatile变量的读
    }
}

阅读全文

原文地址：LMAX Disruptor – High Performance, Low Latency and Simple Too 翻译：杨帆 校对：丁一

Disruptor是一个用于在线程间通信的高效低延时的消息组件，它像个增强的队列，并且它是让LMAX Exchange跑的如此之快的一个关键创新。关于什么是Disruptor、为何它很重要以及它的工作原理方面的信息都呈爆炸性增长 —— 这些文章很适合开始学习Disruptor，还可跟着LMAX BLOG深入学习。这里还有一份更详细的白皮书。

阅读全文

原文链接 作者：Doug Lea 译者：欧振聪 校对：丁一

3 设计与实现

同步器背后的基本思想非常简单。acquire操作如下：

[code lang=”java”]
while (synchronization state does not allow acquire) {
enqueue current thread if not already queued;
possibly block current thread;
}
dequeue current thread if it was queued;
[/code]

release操作如下：

[code lang=”java”]
update synchronization state;
if (state may permit a blocked thread to acquire)
unblock one or more queued threads;
[/code]

为了实现上述操作，需要下面三个基本组件的相互协作：

• 同步状态的原子性管理；
• 线程的阻塞与解除阻塞；
• 队列的管理；

创建一个框架分别实现这三个组件是有可能的。但是，这会让整个框架既难用又没效率。例如：存储在队列节点的信息必须与解除阻塞所需要的信息一致，而暴露出的方法的签名必须依赖于同步状态的特性。

同步器框架的核心决策是为这三个组件选择一个具体实现，同时在使用方式上又有大量选项可用。这里有意地限制了其适用范围，但是提供了足够的效率，使得实际上没有理由在合适的情况下不用这个框架而去重新建造一个。 阅读全文

作者：方腾飞  整理：水羽哲

去年参加了QCon杭州2012大会，有一些收获和大家分享一下。

京东的分享

京东面临的问题

京东的分享嘉宾何斌提出京东之前面临的两个问题：第一个是促销时需要很多机器，但是平时不需要；第二个是当某一台客服中毒其他客服主机也会中毒。大家可以先思考下，觉得应该如何解决这两个问题呢？

京东的解决方案

第一个问题京东采用弹性架构的方式解决。当服务器的资源利用率超过一定阈值时动态扩展虚拟机。举一个例子：如在5分钟内资源使用率达到某个设定的阈值时，就会自动生成几个虚拟机，虚拟机里会自动部署好相关的应用程序，在自动发布前有一个TestServer来监测生成的虚拟机是否可以对外提供服务。云存储和云计算是分离的，云存储使用一个磁盘阵列来实现。

第二个问题京东采用桌面云的方式来解决。首先分配一批虚拟桌面池，然后客服通过权限登陆虚拟桌面，如果没有则再分配一批，虚拟桌面和人不是一一对应的，用完后就回到池子里别人可以继续申请使用，这样可以大大节约资源，当一台机器中病毒后只会影响到子网。

阅读全文

原文地址：http://ifeve.com/disruptor-memory-barriers/

译者：杜建雄     校对：欧振聪

最近我博客文章更新有点慢，因为我在忙着写一篇介绍内存屏障（Memory Barries）以及如何将其应用于Disruptor的文章。问题是，无论我翻阅了多少资料，向耐心的Martin和Mike请教了多少遍，以试图理清一些知识点，可我总是不能直观地抓到重点。大概是因为我不具备深厚的背景知识来帮助我透彻理解。

所以，与其像个傻瓜一样试图去解释一些自己都没完全弄懂的东西，还不如在抽象和大量简化的层次上，把我在该领域所掌握的知识分享给大家 。Martin已经写了一篇文章《going into memory barriers》介绍内存屏障的一些具体细节，所以我就略过不说了。

免责声明：文章中如有错误全由本人负责，与Disruptor的实现和LMAX里真正懂这些知识的大牛们无关。

阅读全文