quasar_Java IO基准：Quasar与异步ForkJoinPool与ManagedBlock

quasar

“ Arien看到了我们运行的parallelStreams和ForkJoin基准测试的结果后，在Twitter上与我们联系。 这激起了他的兴趣，因此他进行了一些自己的测试，将Quasar纤维加入了混合物。 这是他的结果和结论。” –塔基皮(Takipi)Alex Zhitnitsky

Arien Kock是Java软件工程师。 他喜欢单口喜剧，并且曾经是街头霸王的竞争者。

异步ForkJoinPool，managedBlock和Quasar在IO方案中如何执行？

我认为Quasar具有很大的潜力。 除了允许更多数量的并行操作之外，Quasar的光纤还允许OS线程不是一对一的映射，还允许程序员以同步方式(使用continuation )编写代码。 这比普通的异步样式代码趋向于提供回调的方式更容易解释和推理代码。 对于轻量级线程的性能优势，我考虑暂停绿色线程的性能的提高/纤维与停车操作系统线程非常成熟。 在这篇Takipi博客文章的启发下，我对Quasar在IO场景中的表现与替代品的表现感到好奇。 所以我做了一个基准。

新话题：Java的IO基准：类星体与异步ForkJoinPool与managedBlock http://t.co/2eoi4th2ZO pic.twitter.com/IDDGYPYvfI

— Takipi(@takipid) 2015年3月9日

设置

我使用JMH来避免重新发明测试轮的不良版本。 我首先找到了Caliper，但是后来我在Stackoverflow的某个地方读到JMH“更好”。 这是我第一次使用它，但这是一次非常积极的经历。 它带有事件探查器和自动参数排列以及许多其他用于编写微基准测试的出色功能。 我的基准测试比较了IO的三种样式。 直接使用AsynchronousFileChannel(带有回调)，使用常规的阻塞FileChannel，但使用ForkJoinPool的managedBlock工具，最后：Quasar(在AsynchronousFileChannel周围使用包装器对象，允许您编写同步样式代码)。 我使用IO操作之间的一些计算工作来运行测试，以从Quasar中获得大量上下文切换。 您可以在我的Github存储库中找到基准代码。 基准测试是在Windows 8笔记本电脑上以安全模式(我知道避免干扰的最佳方式)在SSD驱动器上运行的。

结果

通过5次热身迭代和15个真实样本，我相信这是非常准确的。

差异远在误差范围之内，我相信可以肯定地说它们是相等的。 运行堆栈分析器仅显示托管阻塞和非阻塞(Quasar和Async FJP)类型之间的差异，这会产生非常不同的调用堆栈。 我创建了一个使用Socket进行相同操作的基准，但是我很确定实现中存在错误。 如果有人想看一下代码，请放心。

我预计托管块会变慢，因为当无法保证FJP上的并行运算能力时，它将分配额外的线程(使用计算任务确实如此)。 在运行该基准测试时，我什至无法正常启动VisualVM。 大量的线程使其加载非常缓慢。 尽管频繁分配线程，但没有区别。 类星体也是如此。 暂挂光纤的开销是搁置执行进程的当前状态以释放CPU内核的操作，不会引起任何明显的延迟。 在“引人注目的”是关键的地方……

结论

面对IO，这三种实现的速度差异不明显。 我是否实现了灭火是没有关系的，因为CPU是瓶颈，因为在所有三种实现中，常规(非IO)代码都将以相同的速度和相同的并行度执行。 这是因为Quasar不会进行任何上下文切换，除非光纤实际阻塞了。 如果光纤花费太长时间执行而没有光纤阻塞，类星体甚至会发出警告。 似乎三种处理IO的性能均相同，这意味着对于这种类型的应用程序，在这三种类型之间进行选择将是一个问题。 但是，我认为这只是部分正确。 在回调样式和阻止样式之间，如果我要做的是同时处理8个文件，则可以清楚地选择阻止样式。 它更容易掌握。 接下来，在托管块(创建更多线程)和光纤块之间进行选择，托管块是最少的工作量。 案件尚未完全结案，但是……

潜伏

在客户端连接可以长时间保持打开的Web服务器中(例如，当我们等待缓慢的客户端和/或我们正在从数据库中获取数据时)，在事务期间阻塞线程可能会导致线程饥饿。 这是Quasar真正发挥作用的地方，这要归功于将许多用户空间线程复用到少数OS线程上。 然后有...

使用Quasar的(当前)“困难”

截至目前，使用quasar意味着使用Java代理，这仅需要一点努力。 现有代码也标记为@Suspendable，以便Quasar可以检测并阻止运行代码的光纤。 在pom.xml中查找执行发现/标记的maven-antrun-plugin。 如果您使用的是具有回调样式异步性的框架，那么您需要编写的自定义代码并不那么复杂，但是您仍然必须编写它。 看看Pulsar的现成集成。

IO光纤：是或否

当您要做的只是具有高吞吐量和低并行度的连续IO时，基准测试不会显示使用光纤的任何代价。 使用Quasar的额外工作(就额外的编码和配置而言)是一系列一次性任务，(我认为)这可以忽略不计。 Pulsar提供了一套很好的集成(尽管JDBC有点不足)。 使用这些和您自己的，您可以创建一个IO繁重的应用程序，例如Web应用程序，该应用程序具有一个用于接受连接的池和一个或多个用于处理后端调用的池。 您最终得到的是线程池，这些线程在后台将任务相互传递，而您的逻辑仍然以同步的方式从上到下读取，最后是return语句。

如果像大多数小型应用程序一样，您最多只能为数百名同时进行的用户做点事情：该技术值得一试，但是没有好处。 但是，如果您的应用程序需要处理大量的并行请求：我说，去吧。

翻译自: https://www.javacodegeeks.com/2015/03/java-io-benchmark-quasar-vs-async-forkjoinpool-vs-managedblock.html

quasar