disruptor 为什么快_disruptor_disrupter(5)

测试结果：

319/1,000,000 = 3,134,000 //使用LinkedBlockingQueue在319毫秒内存取100万个简单对象，每秒钟能执行313万个

46/1,000,000 = 21,739,000 //使用Disruptor在46毫秒内存取100万个简单对象，每秒钟能执行2173万个

平均下来使用Disruptor速度能提高7倍。（不同电脑、应用环境下结果可能不一致）

4、随想：Disruptor、完成端口与Mechanical Sympathy

When pushing performance like this, it starts to become important to take account of the way modern hardware is constructed.

—The LMAX Architecture

“当对性能的追求达到这样的程度，以致对现代硬件构成的理解变得越来越重要。”这句话恰当地形容了Disruptor/LMAX在对性能方面的追求和失败。咦，失败？为什么会这么说呢？Disruptor当然是一个优秀的框架，我说的失败指的是在开发它的过程中，LMAX曽试图提高并发程序效率，优化、使用锁或借助其他模型，但是这些尝试最终失败了——然后他们构建了Disruptor。再提问：一个Java程序员在尝试提高他的程序性能的时候，需要了解很多硬件知识吗？我想很都会回答“不需要”，构建Disruptor的过程中，最初开发人员对这个问题的回答可能也是“不需要”，但是尝试失败后他们决定另辟蹊径。总的看下Disruptor的设计：锁到CAS、缓冲行填充、避免GC等，我感觉这些设计都在刻意“迁就”或者“依赖”硬件设计，这些设计更像是一种“(ugly)hack”（毫无疑问，Disruptor还是目前最优秀的方案之一）。

Disruptor我想到了完成端口，完成端口据说能是Windows上最快的并发网络“框架”：你只要通过API告诉Windows你想recv哪些socket，然后各个recv操作在内核层面上执行并加入到某个队列中，最后再使用Worker线程进行处理，大部分工作Windows都为你做好了，不使用锁也没有上下文切换和大量线程，是不是和Disruptor异曲同工呢？完成端口和Disruptor在追求性能时，都避免使用并行、锁、多线程等概念，这些概念的出现自有它们的原因，这里不用多说，但是为了性能（考虑到硬件）却不能充分使用它们，说明在处理并发、并行问题上，硬件和软件的发展存在不协调，可能冯氏计算机还是适合单“线程”顺序处理信息吧。关于这种不协调，我认为应该是硬件应该会逐步适应软件，但也有人提出了有意思的Mechanical Sympathy（链接[6]），至于未来会如何发展就不是这篇blog能讨论的了:) 。

（完）

链接：

[1]Disruptor介绍译文:

[2]Disruptor的GitHub:

其中这篇PDF对Disruptor作了很好的阐述。

[3]完成端口：

[4]致敬disruptor：CAS实现高效（伪）无锁阻塞队列实践:

[5]Disruptor 源码分析:

[6]Mechanical Sympathy:

----------------------------------（我是分割线）----------------------------------

PS：这是我第5个博客（不过前4个都不是技术blog，笑），以后我会尽量贴一些遇到的问题和思考到这里，水平有限，欢迎各位指出不足！

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-26632-5.html