首先迟到的祝大家中秋快乐。
最近一周多没有更新了。其实我一直想憋一个大招，分享一些大家感兴趣的干货。
鉴于最近我个人的工作内容，于是利用这三天小长假憋了一个出来（其实是玩了两天?）。
先简单说下本次的主题，由于我最近做的是物联网相关的开发工作，其中就不免会遇到和设备的交互。
最主要的工作就是要有一个系统来支持设备的接入、向设备推送消息；同时还得满足大量设备接入的需求。
所以本次分享的内容不但可以满足物联网领域同时还支持以下场景：
WEB 的聊天系统（点对点、群聊）。WEB 应用中需求服务端推送的场景。最近有些朋友在面试阿里，加上 Java-Interview 项目的原因也有小伙伴和我讨论，近期也在负责部门的招牌，这让我想起年初那段长达三个月的奇葩面试经历?。
本来没想拿出来说的，毕竟最后也没成。但由于那几个月的经历让我了解到了大厂的工作方式、对候选同学的考察重点以及面试官的套路等都有了全新的认识。
当然最重要的是这段时间的查漏补缺也让自己精进不少。
原文链接：A Java Fork/Join Framework(PDF) – Doug Lea
Doug Lea 大神关于Java 7引入的他写的Fork/Join框架的论文。
响应式编程（Reactive Programming / RP）作为一种范式在整个业界正在逐步受到认可和落地，是对过往系统的业务需求理解梳理之后对系统技术设计/架构模式的提升总结。Java作为一个成熟平台，对于趋势一向有些稳健的接纳和跟进能力，有着令人惊叹的生命活力：
(6 votes, average: 4.17 out of 5)
Loading...
(14 votes, average: 4.36 out of 5)Java 7提供了ForkJoinPool，支持了Java 8提供的Stream。Java 8还提供了Lamda（有效地表达和使用RP需要FP的语言构件和理念）。Java 9中提供了面向RP的官方Flow API，实际上是直接把Reactive Streams的接口加在Java标准库中，即Reactive Streams规范转正了，Reactive Streams是RP的基础核心组件。Flow API标志着RP由集市式的自由探索阶段 向 教堂式的统一使用的转变。通过上面这些说明，可以看到ForkJoinPool的基础重要性。
对了，另外提一下Java 9的Flow API的@author也是 Doug Lee 哦～
PS：基于Alex/萧欢 翻译、方腾飞 校对的译文稿：Java Fork Join 框架，补译『结论』之后3节，调整了格式和一些用词，整理成完整的译文。译文源码在GitHub的这个仓库中，可以提交Issue/Fork后提交代码来建议/指正。
这篇论文描述了Fork/Join框架的设计、实现以及性能，这个框架通过（递归的）把问题划分为子任务，然后并行的执行这些子任务，等所有的子任务都结束的时候，再合并最终结果的这种方式来支持并行计算编程。总体的设计参考了为Cilk设计的work-stealing框架。就设计层面来说主要是围绕如何高效的去构建和管理任务队列以及工作线程来展开的。性能测试的数据显示良好的并行计算程序将会提升大部分应用，同时也暗示了一些潜在的可以提升的空间。
本项目是 Apache Storm 官方文档的中文翻译版，致力于为有实时流计算项目需求和对 Apache Storm 感兴趣的同学提供有价值的中文资料，希望能够对大家的工作和学习有所帮助。
虽然 Storm 的正式推出已经有好几个年头了，发行版也已经到了 1.0.x，但是目前网络上靠谱的学习资料仍然不多，很多比较有价值的资料都过时了（甚至官方网站自己的资料都没有及时更新，这大概也是发展太快的社区的通病），而较新的资料大多比较零碎，在关键内容的描述上也有些模棱两可，给初学者带来了很大的困扰。本人自己在初学 Storm 的阶段就非常痛苦，一直想有一份较系统、实用的资源来方便学习。最近借着整理工作的机会，就下定决心通过官方文档的翻译梳理出 Storm 的技术路线，于是就有了这个翻译项目。非常感谢并发编程网对本项目的支持，由于本人水平有限，翻译中仍然存在不少问题，还请大家不吝斧正。如果对本项目有任何问题，欢迎在评论中或者本项目的 Github 页面中（https://github.com/weyo/Storm-Documents）提出，另外也可以直接给本人发邮件（ivicoco at gmail.com），谢谢。
原文地址：http://www.oraclejavamagazine-digital.com/javamagazine/20120304/?pg=56&pm=1&u1=friend 作者 Trisha
The London Multi-Asset Exchange (LMAX) Disruptor is an open source concurrency framework that recently won the 2011 Duke’s Choice Award for Innovative Programming Framework. In this article, I use diagrams to describe what the Disruptor is; what it does; and, to some extent, how it works.
原文 地址 作者 Trisha 译者：李同杰
LMAX Disruptor 是一个开源的并发框架，并获得2011 Duke’s 程序框架创新奖。本文将用图表的方式为大家介绍Disruptor是什么，用来做什么，以及简单介绍背后的实现原理。
Disruptor 是线程内通信框架，用于线程里共享数据。LMAX 创建Disruptor作为可靠消息架构的一部分并将它设计成一种在不同组件中共享数据非常快的方法。
基于Mechanical Sympathy（对于计算机底层硬件的理解），基本的计算机科学以及领域驱动设计，Disruptor已经发展成为一个帮助开发人员解决很多繁琐并发编程问题的框架。
很多架构都普遍使用一个队列共享线程间的数据（即传送消息）。图1 展示了一个在不同的阶段中通过使用队列来传送消息的例子（每个蓝色的圈代表一个线程）。 阅读全文
原文：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 重叠；如何通知消费者；生产者一端的批处理；以及多个生产者如何协同工作。 阅读全文
原文地址：LMAX Disruptor – High Performance, Low Latency and Simple Too 翻译：杨帆 校对：丁一
Disruptor是一个用于在线程间通信的高效低延时的消息组件，它像个增强的队列，并且它是让LMAX Exchange跑的如此之快的一个关键创新。关于什么是Disruptor、为何它很重要以及它的工作原理方面的信息都呈爆炸性增长 —— 这些文章很适合开始学习Disruptor，还可跟着LMAX BLOG深入学习。这里还有一份更详细的白皮书。
原文地址：http://ifeve.com/disruptor-memory-barriers/
译者：杜建雄 校对：欧振聪
最近我博客文章更新有点慢，因为我在忙着写一篇介绍内存屏障（Memory Barries）以及如何将其应用于Disruptor的文章。问题是，无论我翻阅了多少资料，向耐心的Martin和Mike请教了多少遍，以试图理清一些知识点，可我总是不能直观地抓到重点。大概是因为我不具备深厚的背景知识来帮助我透彻理解。
所以，与其像个傻瓜一样试图去解释一些自己都没完全弄懂的东西，还不如在抽象和大量简化的层次上，把我在该领域所掌握的知识分享给大家 。Martin已经写了一篇文章《going into memory barriers》介绍内存屏障的一些具体细节，所以我就略过不说了。
免责声明：文章中如有错误全由本人负责，与Disruptor的实现和LMAX里真正懂这些知识的大牛们无关。
原文地址：http://ifeve.com/ringbuffer/
作者：Trisha 译者：寒桐 校对：方腾飞
最近，我们开源了LMAX Disruptor，它是我们的交易系统吞吐量快（LMAX是一个新型的交易平台，号称能够单线程每秒处理数百万的订单）的关键原因。为什么我们要将其开源？我们意识到对高性能编程领域的一些传统观点，有点不对劲。我们找到了一种更好、更快地在线程间共享数据的方法，如果不公开于业界共享的话，那未免太自私了。同时开源也让我们觉得看起来更酷。
从这个站点，你可以下载到一篇解释什么是Disruptor及它为什么如此高性能的文档。这篇文档的编写过程，我并没有参与太多，只是简单地插入了一些标点符号和重组了一些我不懂的句子，但是非常高兴的是，我仍然从中提升了自己的写作水平。
我发现要把所有的事情一下子全部解释清楚还是有点困难的，所有我准备一部分一部分地解释它们，以适合我的NADD听众。
首先介绍ringbuffer。我对Disruptor的最初印象就是ringbuffer。但是后来我意识到尽管ringbuffer是整个模式（Disruptor）的核心，但是Disruptor对ringbuffer的访问控制策略才是真正的关键点所在。
原文地址：http://ifeve.com/false-sharing/
作者：Martin Thompson 译者：丁一
缓存系统中是以缓存行（cache line）为单位存储的。缓存行是2的整数幂个连续字节，一般为32-256个字节。最常见的缓存行大小是64个字节。当多线程修改互相独立的变量时，如果这些变量共享同一个缓存行，就会无意中影响彼此的性能，这就是伪共享。缓存行上的写竞争是运行在SMP系统中并行线程实现可伸缩性最重要的限制因素。有人将伪共享描述成无声的性能杀手，因为从代码中很难看清楚是否会出现伪共享。
为了让可伸缩性与线程数呈线性关系，就必须确保不会有两个线程往同一个变量或缓存行中写。两个线程写同一个变量可以在代码中发现。为了确定互相独立的变量是否共享了同一个缓存行，就需要了解内存布局，或找个工具告诉我们。Intel VTune就是这样一个分析工具。本文中我将解释Java对象的内存布局以及我们该如何填充缓存行以避免伪共享。
阅读全文
