原文地址：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

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

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

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

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

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

京东的分享

京东面临的问题

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

京东的解决方案

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

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

阅读全文

本文是《The Java Virtual Machine Specification （Java SE 7 Edition）》2011年6月版的运行时数据区的翻译

原文参见：http://download.oracle.com/javase/7/specs/jvms/JVMS-JavaSE7.pdf  译者：方腾飞

JVM定义了若干个程序执行期间使用的数据区域。这个区域里的一些数据在JVM启动的时候创建，在JVM退出的时候销毁。而其他的数据依赖于每一个线程，在线程创建时创建，在线程退出时销毁。

2.5.1  程序计数器（The pc Register）

JVM一次能支持很多线程执行。每一个JVM线程有它自己的程序计数器。在任何时候，一个JVM的线程都正在执行当前线程的方法代码。如果这个方法不是本地方法，程序计数器包含当前被执行的JVM地址。如果线程正在执行本地方法，程序计数器的值为未定义。JVM 程序计数器足以存储一个返回地址或一个本地指针。

阅读全文

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

作者：Trisha  译者：方腾飞 校对：丁一

我们经常提到一个短语Mechanical Sympathy，这个短语也是Martin博客的标题（译注：Martin Thompson），Mechanical Sympathy讲的是底层硬件是如何运作的，以及与其协作而非相悖的编程方式。

我在上一篇文章中提到RingBuffer后，我们收到一些关于RingBuffer中填充高速缓存行的评论和疑问。由于这个适合用漂亮的图片来说明，所以我想这是下一个我该解决的问题了。
（译注：Martin Thompson很喜欢用Mechanical Sympathy这个短语，这个短语源于赛车驾驶,它反映了驾驶员对于汽车有一种天生的感觉，所以他们对于如何最佳的驾御它非常有感觉。）

计算机入门

我喜欢在LMAX工作的原因之一是，在这里工作让我明白从大学和A Level Computing所学的东西实际上还是有意义的。做为一个开发者你可以逃避不去了解CPU，数据结构或者大O符号 —— 而我用了10年的职业生涯来忘记这些东西。但是现在看来，如果你知道这些知识并应用它，你能写出一些非常巧妙和非常快速的代码。

因此，对在学校学过的人是种复习，对未学过的人是个简单介绍。但是请注意，这篇文章包含了大量的过度简化。

CPU是你机器的心脏，最终由它来执行所有运算和程序。主内存（RAM）是你的数据（包括代码行）存放的地方。本文将忽略硬件驱动和网络之类的东西，因为Disruptor的目标是尽可能多的在内存中运行。

CPU和主内存之间有好几层缓存，因为即使直接访问主内存也是非常慢的。如果你正在多次对一块数据做相同的运算，那么在执行运算的时候把它加载到离CPU很近的地方就有意义了（比如一个循环计数－你不想每次循环都跑到主内存去取这个数据来增长它吧）。

阅读全文

原文地址：http://mechanical-sympathy.blogspot.com/2011/07/false-sharing.html（有墙移到墙内）

作者：Martin Thompson

Memory is stored within the cache system in units know as cache lines.  Cache lines are a power of 2 of contiguous bytes which are typically 32-256 in size.  The most common cache line size is 64 bytes.   False sharing is a term which applies when threads unwittingly impact the performance of each other while modifying independent variables sharing the same cache line.  Write contention on cache lines is the single most limiting factor on achieving scalability for parallel threads of execution in an SMP system.  I’ve heard false sharing described as the silent performance killer because it is far from obvious when looking at code.

To achieve linear scalability with number of threads, we must ensure no two threads write to the same variable or cache line.  Two threads writing to the same variable can be tracked down at a code level.   To be able to know if independent variables share the same cache line we need to know the memory layout, or we can get a tool to tell us.  Intel VTune is such a profiling tool.  In this article I’ll explain how memory is laid out for Java objects and how we can pad out our cache lines to avoid false sharing.

Figure 1.

阅读全文

我们都知道当一个线程试图访问同步代码块时，它首先必须得到锁，退出或抛出异常时必须释放锁。这些基础也许大家都知道，但是很多人还是搞不清哪个对象才是锁？如果你能正确回答以下问题，那么才算你彻底搞明白了哪个对象才是锁？

阅读全文

在javaeye有位朋友问了我一个非常好的问题。

问题

一个线程向volatile的数组中设置值，而另一个线程向volatile的数组中读取。
比如seg.setValue(2)，随后另一个线程调用seg.getValue(2)，前一个线程设置的值对读取的线程是可见的吗？

我看书上说volatile的数组只针对数组的引用具有volatile的语义，而不是它的元素。

ConcurrentHashMap中也有这样的代码，我很疑惑，希望得到你的解答，谢谢。

阅读全文

原文地址：http://mechanitis.blogspot.com/2011/06/dissecting-disruptor-how-do-i-read-from.html（因为有墙转载到墙内）

作者：Trisha

The next in the series of understanding the Disruptor pattern developed at LMAX.

After the last post we all understand ring buffers and how awesome they are.  Unfortunately for you, I have not said anything about how to actually populate them or read from them when you’re using the Disruptor.

ConsumerBarriers and Consumers
I’m going to approach this slightly backwards, because it’s probably easier to understand in the long run.  Assuming that some magic has populated it: how do you read something from the ring buffer?

(OK, I’m starting to regret using Paint/Gimp.  Although it’s an excellent excuse to purchase a graphics tablet if I do continue down this road.  Also UML gurus are probably cursing my name right now.)

阅读全文

原文地址：http://mechanitis.blogspot.com/2011/07/dissecting-disruptor-writing-to-ring.html（因被墙移到墙内）  作者：Trisha

This is the missing piece in the end-to-end view of the Disruptor.  Brace yourselves, it’s quite long.  But I decided to keep it in a single blog so you could have the context in one place.

The important areas are: not wrapping the ring; informing the consumers; batching for producers; and how multiple producers work. 阅读全文

原文地址：http://mechanitis.blogspot.com/2011/08/disruptor-20-all-change-please.html  （因被墙移到墙内）  作者：Trisha

Martin recently announced version 2.0 of the Disruptor – basically there have been so many changes since we first open-sourced it that it’s time to mark that officially.  His post goes over all the changes, the aim of this article is to attempt to translate my previous blog posts into new-world-speak, since it’s going to take a long time to re-write each of them all over again. Now I see the disadvantage of hand-drawing everything.

阅读全文

原文地址：http://mechanitis.blogspot.com/2011/06/dissecting-disruptor-whats-so-special.html（因被墙移到墙内） 作者：Trisha

Recently we open sourced the LMAX Disruptor, the key to what makes our exchange so fast.  Why did we open source it?  Well, we’ve realised that conventional wisdom around high performance programming is… a bit wrong. We’ve come up with a better, faster way to share data between threads, and it would be selfish not to share it with the world.  Plus it makes us look dead clever.

On the site you can download a technical article explaining what the Disruptor is and why it’s so clever and fast.  I even get a writing credit on it, which is gratifying when all I really did is insert commas and re-phrase sentences I didn’t understand.

However I find the whole thing a bit much to digest all at once, so I’m going to explain it in smaller pieces, as suits my NADD audience.

First up – the ring buffer.  Initially I was under the impression the Disruptor was just the ring buffer.  But I’ve come to realise that while this data structure is at the heart of the pattern, the clever bit about the Disruptor is controlling access to it.
阅读全文

原文地址：http://martinfowler.com/articles/lmax.html 作者：Martin Fowler

译文地址：http://www.jdon.com/42452 译者：banq

LMAX是一种新型零售金融交易平台，它能够以很低的延迟(latency)产生大量交易(吞吐量). 这个系统是建立在JVM平台上，核心是一个业务逻辑处理器，它能够在一个线程里每秒处理6百万订单. 业务逻辑处理器完全是运行在内存中(in-memory)，使用事件源驱动方式(event sourcing). 业务逻辑处理器的核心是Disruptors，这是一个并发组件，能够在无锁的情况下实现网络的Queue并发操作。他们的研究表明，现在的所谓高性能研究方向似乎和现代CPU设计是相左的。

目录

1. 整体架构
2. 业务逻辑处理
3. Disruptors的输入和输出
4. 队列和机制偏爱的缺乏
5. 你需要使用这个架构吗

过去几年我们不断提供这样声音：免费午餐已经结束。我们不再能期望在单个CPU上获得更快的性能，因此我们需要写使用多核处理的并发软件，不幸的是， 编写并发软件是很难的，锁和信号量是很难理解的和难以测试，这意味着我们要花更多时间在计算机上，而不是我们的领域问题，各种并发模型，如Actors 和软事务STM(Software Transactional Memory), 目的是更加容易使用，但是按下葫芦飘起瓢，还是带来了bugs和复杂性.

我很惊讶听到去年3月QCon上一个演讲， LMAX是一种新的零售的金融交易平台。它的业务创新 – 允许任何人在一系列的金融衍生产品交易。这就需要非常低的延迟，非常快速的处理，因为市场变化很快，这个零售平台因为有很多人同时操作自然具备了复杂性，用户越多，交易量越大，不断快速增长。

鉴于多核心思想的转变，这种苛刻的性能自然会提出一个明确的并行编程模型 ，但是他们却提出用一个线程处理6百万订单，而且是每秒，在通用的硬件上。

通过低延迟处理大量交易，取得低延迟和高吞吐量，而且没有并发代码的复杂性，他们是怎么做到呢？现在LMAX已经产品化一段时间了，现在应该可以揭开其神秘而迷人的面纱了。

阅读全文

原文地址：http://mechanitis.blogspot.com/2011/08/dissecting-disruptor-why-its-so-fast.html （因有墙，移到墙内）

My recent slow-down in posting is because I’ve been trying to write a post explaining memory barriersand their applicability in the Disruptor. The problem is, no matter how much I read and no matter how many times I ask the ever-patient Martin and Mike questions trying to clarify some point, I just don’t intuitively grasp the subject. I guess I don’t have the deep background knowledge required to fully understand.

So, rather than make an idiot of myself trying to explain something I don’t really get, I’m going to try and cover, at an abstract / massive-simplification level, what I do understand in the area.  Martin has written a post going into memory barriers in some detail, so hopefully I can get away with skimming the subject.

阅读全文