原文链接 作者：Jakob Jenkov 译者：申章 校对：丁一
锁像synchronized同步块一样，是一种线程同步机制，但比Java中的synchronized同步块更复杂。因为锁（以及其它更高级的线程同步机制）是由synchronized同步块的方式实现的，所以我们还不能完全摆脱synchronized关键字（译者注：这说的是Java 5之前的情况）。
自Java 5开始，java.util.concurrent.locks包中包含了一些锁的实现，因此你不用去实现自己的锁了。但是你仍然需要去了解怎样使用这些锁，且了解这些实现背后的理论也是很有用处的。可以参考我对java.util.concurrent.locks.Lock的介绍，以了解更多关于锁的信息。
以下是本文所涵盖的主题：
原文链接 作者：Jakob Jenkov 译者：He Jianjun 校对：丁一
在同一程序中运行多个线程本身不会导致问题，问题在于多个线程访问了相同的资源。如，同一内存区（变量，数组，或对象）、系统（数据库，web services等）或文件。实际上，这些问题只有在一或多个线程向这些资源做了写操作时才有可能发生，只要资源没有发生变化,多个线程读取相同的资源就是安全的。
原文 地址 作者 Trisha 译者：李同杰
LMAX Disruptor 是一个开源的并发框架，并获得2011 Duke’s 程序框架创新奖。本文将用图表的方式为大家介绍Disruptor是什么，用来做什么，以及简单介绍背后的实现原理。
Disruptor 是线程内通信框架，用于线程里共享数据。LMAX 创建Disruptor作为可靠消息架构的一部分并将它设计成一种在不同组件中共享数据非常快的方法。
基于Mechanical Sympathy（对于计算机底层硬件的理解），基本的计算机科学以及领域驱动设计，Disruptor已经发展成为一个帮助开发人员解决很多繁琐并发编程问题的框架。
很多架构都普遍使用一个队列共享线程间的数据（即传送消息）。图1 展示了一个在不同的阶段中通过使用队列来传送消息的例子（每个蓝色的圈代表一个线程）。 阅读全文
原文：False Shareing && Java 7 （依然是马丁的博客） 译者：杨帆 校对：方腾飞
在我前一篇有关伪共享的博文中，我提到了可以加入闲置的long字段来填充缓存行来避免伪共享。但是看起来Java 7变得更加智慧了，它淘汰或者是重新排列了无用的字段，这样我们之前的办法在Java 7下就不奏效了，但是伪共享依然会发生。我在不同的平台上实验了一些列不同的方案，并且最终发现下面的代码是最可靠的。（译者注：下面的是最终版本，马丁在大家的帮助下修改了几次代码） 阅读全文
原文：http://blog.codeaholics.org/2011/the-disruptor-lock-free-publishing/
译者：罗立树
假如你生活在另外一个星球，我们最近开源了一套高性能的基于消息传递的开源框架。
下面我给大家介绍一下如何将消息通过Ring buffer在无锁的情况下进行处理。
在深入介绍之前，可以先快速阅读一下Trish发表的文章，该文章介绍了ring buffer和其工作原理。
作者：Trisha 译者：古圣昌 校对：方腾飞
从上一篇文章中我们都了解了什么是Ring Buffer以及它是如何的特别。但遗憾的是，我还没有讲述如何使用Disruptor向Ring Buffer写数据和从Ring Buffer中读取数据。
原文地址：http://blog.trifork.nl/2011/07/20/processing-1m-tps-with-axon-framework-and-the-disruptor/
作者： Allard Buijze 译者：程晓明
LMAX，一家在英国的金融公司，最近开源了其（新型零售金融交易平台的）核心组件之一：Disruptor。这个组件通过删除必须的锁来降低执行开销，且任然保证正确的处理订单。如果你问我，我会说这是一个优美精巧的工程。我尝试把Disruptor应用到Axon控制总线中，就是想看看它到底有多大的潜力。结果相当惊人。
Martin Fowler在自己网站上写了一篇LMAX架构的文章，在文章中他介绍了LMAX是一种新型零售金融交易平台，它能够以很低的延迟产生大量交易。这个系统是建立在JVM平台上，其核心是一个业务逻辑处理器，它能够在一个线程里每秒处理6百万订单。业务逻辑处理器完全是运行在内存中，使用事件源驱动方式。业务逻辑处理器的核心是Disruptor。
Disruptor它是一个开源的并发框架，并获得2011 Duke’s 程序框架创新奖，能够在无锁的情况下实现网络的Queue并发操作。本文是Disruptor官网中发布的文章的译文（现在被移到了GitHub）。
原文地址：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版本，从我们开始将其开源以来发生了很多变化，现在是个时候推出一个正式的里程碑了。马丁的博客上涵盖了这次更新的所有内容，这篇文章的目的是尝试把我以前的博文以新框架的架构转述给大家，因为将它们都重写一遍要耗费很多时间。现在我看到手工绘图的缺点了。
(21 votes, average: 4.86 out of 5)
Loading...
(4 votes, average: 4.00 out of 5)