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

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

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

原文地址：http://ifeve.com/false-sharing/

作者：Martin Thompson  译者：丁一

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

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

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

阅读全文

原文地址：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已经产品化一段时间了，现在应该可以揭开其神秘而迷人的面纱了。

阅读全文

Doug Lea 的文献

1. Synchronizer Framework  译者：ClarenceAu （已翻译完成,在校对）
2. Fork/Join  译者：Alex（陆续发表中）
3. Java Concurrency Constructs 译者：萧欢（已翻译完成）
4. Cancellation 译者：丁一  （已翻译完成）

以下文章来自：https://code.google.com/p/disruptor/wiki/BlogsAndArticles

如何使用Disruptor

1. What’s so special about a ring buffer? – A summary by Trisha of the data structure at the heart of the Disruptor patter, how it’s implemented and what’s so great about it. （译者：淘宝-欧立勇）
2. How do I read from a ring buffer? – Trisha gives an overview of the Consumer and ConsumerBarrier, which allows you to read stuff off the ring buffer.(译者：古圣昌)
3. Writing to the ring buffer – The third piece from Trisha explaining how to write to the ring buffer, and how it avoids wrapping.（译者：长源）
4. Lock-free publishing – Danny outlines the concepts behind putting items into the ring buffer.（译者：行知）
5. DSL for wiring up the Disruptor – Adrian came up with a cunning way to configure your Disruptor(译者：杨帆)
6. Disruptor wizard now part of the Disruptor – Adrian’s wizard now makes it easy to configure your very own Disruptor straight out of the box (译者：杨帆)
7. Disruptor version 2.0 – Trisha outlines the cosmetic changes to the Disruptor in version 2.0.(译者：杨帆)
8. Sharing Data Among Threads Without Contention – An updated and summarised version of Trisha’s blogs in Oracle’s Java Magazine.（译者：同杰）

Disruptor为什么这么快

1. Locks Are Bad – Trisha gives some basic concurrency background and explains why locks are evil. (译者：nick，潘曦，已经翻译完成)
2. Magic cache line padding – An explanation around why the odd cache line padding variables are required, by Trisha.(译者：方腾飞，已经翻译完)
3. Demystifying Memory Barriers – Trisha attempts to explain why memory barriers are important in the Disruptor. （译者：杜建雄）

其他人写的Disruptor文章

1. LMAX 架构  by Martin Fowler (已翻译)
2. Processing 1m TPS with the Axon Framework using the Disruptor.（译者，程晓明）

有兴趣的同学可以一起参与，有什么其他并发文献希望我们翻译的也可以通过留言告知我们。

如何翻译

1. 你可从以上几篇文章中挑选某一篇进行翻译，翻译时间最好是一个星期以内，翻译前请发邮件到main_shorttime（AT）163.com告诉我你要翻译的文章和预计完成时间。
2. 译者署名的顺序由翻译的字数确定。
3. 与其他译者交叉校对，互相讨论翻译与技术问题。
4. 提交翻译：在并发编程网用QQ登陆，然后发布译文。

注意事项

1: java并发编程实战

豆瓣地址：http://book.douban.com/subject/10484692/

2：多处理器编程的艺术

豆瓣地址：http://book.douban.com/subject/3901836/

3：推荐系列文章

1. IBM developerWorks 中国 : Java 多线程与并发编程专题 http://t.cn/SVFmtH
2. 原阿里同事@武汉伢袁志俊 写的“探索并发编程”系列文章http://t.cn/aF7gqD
3. 深入浅出java并发编程http://t.cn/hGJNqw by @饭饭泛

4：推荐精品文章

1. 阿里同事悟时写的一种高效无锁内存队列的实现
2. Hadoop并行计算原理与分布式并发编程 http://t.cn/zlsBCHk