Java 8中流的问题

Question

根据这个article，Java中的Fork-Join架构存在一些严重的缺陷。据我所知，Java8中的Streams在内部使用了Fork-Join框架。我们可以使用parallel()方法轻松地将流转换为并行。但是当我们将一个长时间运行的任务提交给一个并行流时，它会阻塞池中的所有线程，请检查this。这种行为对于现实世界的应用程序是不可接受的。

我的问题是，在高性能应用程序(例如股票分析、股票行情等)中使用这些构造之前，我应该考虑哪些不同的考虑因素。

Answer 1

注意事项与多线程的其他用法类似。

• 只使用多线程，如果你知道它们有帮助的话。目标不是使用你拥有的每一个核心，而是让一个程序来执行你的requirements.
• Don't，忘记多线程带来的开销，并且这个开销可能会超过你的get.
• Multi-threading可以体验到的大的异常值。当您测试性能时，您不仅应该查看吞吐量(应该更好)，还应该查看延迟的分布(在极端情况下通常会更差)
• 为了获得低延迟，请尽可能少地在线程之间切换。如果你可以在一个线程中做所有的事情，这可能是一个很好的选择。
• 用于低延迟，你不想玩得很好，相反，你想通过做一些事情来最小化抖动，比如将繁忙的等待线程钉在独立的核心上。隔离的内核越多，运行线程池等操作所需的垃圾内核就越少。

Answer 2

streams API使并行性看起来很简单。如前所述，使用并行流是否会加速您的应用程序，需要在实际的运行时上下文中进行彻底的分析和测试。我自己使用并行流的经验表明了以下几点(我确信这个列表还远远不完整)：

• 在流元素上执行的操作的成本与并行化机器的成本决定了并行流的潜在好处。例如，使用紧凑的循环在双精度数组中查找最大值是如此之快，以至于流开销从来都不值得。一旦操作变得更加昂贵，天平就开始倾向于并行流API -在理想的条件下，例如，一个专门用于单一算法的多核机器)。我鼓励您experiment.
• You需要有时间和耐力来学习stream API的本质。有一些意想不到的陷阱。例如，Spliterator可以从简单语句中的常规迭代器构造。根据迭代器产生的元素的数量，这种方法变得非常甚至非常耗费资源。
• 虽然引用的文章使我们看起来完全受制于甲骨文，但这并不完全正确。您可以编写自己的拆分器，将输入拆分成特定于您的情况的块，而不是依赖于默认实现。如果在流的元素上执行的任务使用ForkJoinPool本身，则可能会发生死锁。您需要学习如何使用ForkJoinPool.ManagedBlocker应用程序接口及其用法(我发现这与易于掌握正好相反)。从技术上讲，您是在告诉ForkJoinPool一个线程正在阻塞，这可能会导致创建额外的线程来保持并行度不变。

就我的五分钱……

Answer 3

本文的重点(实际上有17篇)是要指出，F/J框架更像是一个研究项目，而不是一个通用的商业应用程序开发框架。

批评对象，而不是人。当框架的主要问题是架构师是教授/科学家而不是工程师/商业开发人员时，尝试做到这一点是最困难的。可从本文下载的PDF合并更多地讨论了使用研究标准而不是工程标准的问题。

并行流可以很好地工作，直到您尝试扩展它们。框架使用pull技术；请求进入提交队列，线程必须将请求从提交队列中拉出。任务返回到派生线程的双队列中，其他线程必须将任务从双队列中拉出。这种技术不能很好地扩展。在推送技术中，每个任务分散到系统中的每个线程。这在大规模环境中效果要好得多。

正如甲骨文的Paul Sandoz指出的那样，扩展还有许多其他问题:例如，如果您有32个内核，并且正在执行Stream.of(s1，s2，s3，s4).flatMap(x -> x).reduce(...)那么你最多只能使用4个内核。这篇文章指出，对于可下载的软件，伸缩不能很好地工作，必须使用局部技术来避免堆栈溢出和OOME。

使用并行流。但要注意其中的局限性。