blocks|key|111014|text|答：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|111015|在slicesK+>=+50000中，您的Disruptor可用环缓冲区不知何故已满，这会导致性能下降。|111016|备注:|offset|length|style|BOLD|111017|为了获得很高的性能，环缓冲区及其内容应该适合在L3+CPU缓存中进行线程间的交换。如果环形缓冲区用于重放场景(如市场数据或网络恢复)，则可能会更大，并从缓存丢失中产生明显的性能影响。|111018|​|111019|📷|atomic|111020|111021|Sequencer的角色之一是确保发布不包装环形缓冲区。要做到这一点，下游使用者中没有一个序列可能低于环形缓冲区的序列，小于环形缓冲区的大小。然而，使用依赖关系图可以进行有趣的优化。|111022|111023|111024|111025|111026|111027|111028|111029|111030|链接:|111031|解剖者:环形缓冲器有什么特别之处？|111032|干扰物常见问题|111033|LMAX体系结构|111034|LMAX+Disruptor信息页面|111035|Wiki+:循环缓冲区+(Disruptor不使用指针)|111036|其他循环缓冲wiki|111037|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://developer.qcloudimg.com/http-save/yehe-900000/0db025bd7433a9a4c4443adc11514c43.gif|imageAlt|1|https://developer.qcloudimg.com/http-save/yehe-900000/b74aaeb095fa4d483953d5f3d4672e8c.png|2|https://developer.qcloudimg.com/http-save/yehe-900000/f221a5e20ecf7bd5e4b6155da023556e.png|3|https://developer.qcloudimg.com/http-save/yehe-900000/865604b6a7ea117c39d8151778cc6b8c.png|4|LINK|MUTABLE|url|http://mechanitis.blogspot.be/2011/06/dissecting-disruptor-whats-so-special.html|5|https://code.google.com/p/disruptor/wiki/FrequentlyAskedQuestions|6|http://martinfowler.com/articles/lmax.html|7|https://github.com/LMAX-Exchange/disruptor/wiki/Introduction|8|https://en.wikipedia.org/wiki/Circular_buffer|9|http://www.boost.org/doc/libs/1_58_0/doc/html/circular_buffer.html^0|0|0|0|3|0|0|0|0|1|0|0|0|0|0|1|1|0|0|0|0|1|2|0|0|0|0|1|3|0|0|0|3|0|0|H|4|0|0|7|5|0|0|8|6|0|0|I|7|0|0|B|8|0|0|A|9|0^^$0|@$1|2|3|4|5|6|7|29|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|2A|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|2B|8|@$F|2C|G|2D|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|2E|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|2F|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|2G|8|@]|9|@$F|2H|G|2I|1|2J]]|A|$]]|$1|Q|3|M|5|6|7|2K|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|2L|8|@]|9|@]|A|$]]|$1|T|3|O|5|P|7|2M|8|@]|9|@$F|2N|G|2O|1|2P]]|A|$]]|$1|U|3|M|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|V|3|M|5|6|7|2R|8|@]|9|@]|A|$]]|$1|W|3|O|5|P|7|2S|8|@]|9|@$F|2T|G|2U|1|2V]]|A|$]]|$1|X|3|M|5|6|7|2W|8|@]|9|@]|A|$]]|$1|Y|3|M|5|6|7|2X|8|@]|9|@]|A|$]]|$1|Z|3|O|5|P|7|2Y|8|@]|9|@$F|2Z|G|30|1|31]]|A|$]]|$1|10|3|M|5|6|7|32|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|33|8|@$F|34|G|35|H|I]]|9|@]|A|$]]|$1|13|3|14|5|6|7|36|8|@]|9|@$F|37|G|38|1|39]]|A|$]]|$1|15|3|16|5|6|7|3A|8|@]|9|@$F|3B|G|3C|1|3D]]|A|$]]|$1|17|3|18|5|6|7|3E|8|@]|9|@$F|3F|G|3G|1|3H]]|A|$]]|$1|19|3|1A|5|6|7|3I|8|@]|9|@$F|3J|G|3K|1|3L]]|A|$]]|$1|1B|3|1C|5|6|7|3M|8|@]|9|@$F|3N|G|3O|1|3P]]|A|$]]|$1|1D|3|1E|5|6|7|3Q|8|@]|9|@$F|3R|G|3S|1|3T]]|A|$]]|$1|1F|3|-4|5|6|7|3U|8|@]|9|@]|A|$]]]|1G|$1H|$5|1I|1J|1K|A|$1L|1M|1N|-4]]|1O|$5|1I|1J|1K|A|$1L|1P|1N|-4]]|1Q|$5|1I|1J|1K|A|$1L|1R|1N|-4]]|1S|$5|1I|1J|1K|A|$1L|1T|1N|-4]]|1U|$5|1V|1J|1W|A|$1X|1Y]]|1Z|$5|1V|1J|1W|A|$1X|20]]|21|$5|1V|1J|1W|A|$1X|22]]|23|$5|1V|1J|1W|A|$1X|24]]|25|$5|1V|1J|1W|A|$1X|26]]|27|$5|1V|1J|1W|A|$1X|28]]]]

<h1>Answer :</h1>

Your Disruptor usable Ring Buffer is somehow full at slicesK >= 50000 which is cause the performance to drop. 

Notes :

For very high performance the ring buffer, and its contents, should fit in L3 CPU cache for exchanging between threads. If the ring buffer is used for a replay scenario, such as market data or network recovery, it may be larger and have obvious performance implications from the cache misses. 

<hr>

<h2><img src="https://i.stack.imgur.com/Yikno.gif" alt="Buffer"></h2>

<hr>

One of the Sequencer's roles is to ensure that publication does not wrap the Ring Buffer. To do this none of the downstream consumer may have a Sequence that is lower than the Ring Buffer's Sequence less the size of the Ring Buffer. However using the graph of dependencies an interesting optimization can be made
<img src="https://i.stack.imgur.com/hPaoc.png" alt="Disruptor with a set of dependent consumers.">

<hr>

<img src="https://i.stack.imgur.com/cdza4.png" alt="enter image description here">

------------------- ^ Thread 1 ^ ------------------------------------------------------------ ^ Thread 2 ^ ----------

<hr>

<img src="https://i.stack.imgur.com/e6xZ0.png" alt="enter image description here">

<hr>

Links :

<a href="http://mechanitis.blogspot.be/2011/06/dissecting-disruptor-whats-so-special.html" rel="nofollow noreferrer">Dissecting the Disruptor : What's so special about a ring buffer ?</a>

<a href="https://code.google.com/p/disruptor/wiki/FrequentlyAskedQuestions" rel="nofollow noreferrer">Disruptor FAQ</a>

<a href="http://martinfowler.com/articles/lmax.html" rel="nofollow noreferrer">The LMAX Architecture</a>

<a href="https://github.com/LMAX-Exchange/disruptor/wiki/Introduction" rel="nofollow noreferrer">LMAX Disruptor Info Page</a>

<a href="https://en.wikipedia.org/wiki/Circular_buffer" rel="nofollow noreferrer">Wiki : Circular buffer</a> (Disruptor does not use pointers)

<a href="http://www.boost.org/doc/libs/1_58_0/doc/html/circular_buffer.html" rel="nofollow noreferrer">Other Circular buffer wiki</a>

I have run this <a href="https://github.com/shipilev/disrupting-fjp" rel="nofollow">DisruptovsFJ</a> Mirco-Benchmarks written by <code>Aleskey Shipilev</code>, where ForkJoin and the Disruptor library performance is compared.

The results I have using JDK1.8.40 on a Linux platform i5:

<pre><code>Benchmark Score, Score Error (99.9%),Unit,Param: slicesK,

Disruptor.run, 939.801405, 20.741961,ms/op, 50000,0,10
ForkJoin.run, 1175.263451, 0.595711, ms/op, 50000,0,10
ForkJoinRecursive.run 771.854028, 26.022542,ms/op, 50000,0,10
ForkJoinRecursiveDeep.run, 1356.697011, 28.666325,ms/op, 50000,0,10
ForkJoinReuse.run, 7974.180793, 49.604539,ms/op, 50000,0,10 
</code></pre>

The first part of the results for <code>slicesK &lt; 50000</code> were expected as the <code>Disruptor</code> is using a RingBuffer and a mechanism that makes it much efficient in concurrent context.

Now when <code>slicesK &gt;= 50000</code> the <code>Disruptor</code> test is less performant than ForkJoinRecursiveDeep, and ForkJoinReuse.
Can someone explain to me those results ? Thank you

Benchmark results ForkJoin vs Disruptor?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我已经运行了由Aleskey Shipilev编写的这个Aleskey Shipilev镜像基准测试，其中比较了ForkJoin和Disruptor库的性能。我在Linux平台i5上使用JDK1.8.40的结果如下：Benchmark                     Score,     Score Error (99.9%),Unit,Param: slicesK,Disruptor.r

问ForkJoin对Disruptor的基准结果？
EN

回答 1

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ForkJoin对Disruptor的基准结果？EN