【问题标题】:Are Parallel Streams and forkjoinpool safe to use in Production?Parallel Streams 和 forkjoinpool 在生产环境中使用是否安全?
【发布时间】:2017-04-20 08:28:58
【问题描述】:

我们开发了一个使用 Java8 并行流的 API 调用,我们获得了非常好的性能,在进行压力测试时几乎是顺序处理的两倍。

我知道这取决于用例,但我将它用于加密操作,所以我认为这是一个很好的用例。

但是,我阅读了很多鼓励对它们非常小心的文章。还有一些文章讨论了它们的内部设计不是很好,比如here

因此:并行流生产准备好了吗?它们在生产系统中被广泛使用吗?

【问题讨论】:

  • 我所知道的大多数生产系统甚至都不使用 java8。
  • @HenningLuther 也不是我们的,但我们想继续前进。我想这应该是件好事
  • 你已经自己做了压力测试,为什么还要问这样的问题?我会说,您很可能会使用测试较少的 JRE 代码而不考虑它......
  • @Holger 如果不是我在问题中提到的在线阅读了很多关于并行流的警告,我不会问这个问题。此外,正如我在下面所说的“我只在测试服务器上对其进行了测试,但我没有资源来模仿当前生产系统的一部分来检查它是否在大规模上运行良好”我在我的自己判断,这就是我问的原因
  • 如果“安全”是指“实施是否可靠且经过良好测试”,那么是。如果您的意思是“我可以通过不遵守规则或运用常识来打自己的脚,得到错误的答案并获得糟糕的表现吗?”也可以。

标签: java parallel-processing java-8 production forkjoinpool


【解决方案1】:

这个问题邀请“意见”;但我尽量根据事实来回答。

分叉/加入

这些课程并不新鲜!如您所见,see,它们已经在 J​​ava 1.7 中引入。换句话说:这些课程已经存在好几年了;并在很多地方使用。因此:低风险。

并行流

在 Java 术语中是“最近”添加的(请记住 2017 年有多少遗留 Java;以及 [与其他语言相比]Java 的发展速度有多慢)。我认为这里的简单答案是:我们还不知道并行流是否会成为 Java 编程的“基石”,或者人们是否会更喜欢其他方法来解决并行流解决的问题一点。

除此之外:其他语言(例如 JavaScript)的用户习惯于几乎“每月”一次“换档”(又名框架)。这意味着大量的流失,但这也意味着“好东西”被迅速应用;比如:为什么要推迟改进?!

我的意思是:你发现并行流可以帮助你提高性能; 您的团队同意“是的,我们可以处理编写代码的流()方式”......然后继续前进。

换句话说:当并行流帮助您的团队/产品“变得更好”时,为什么不尝试利用它呢?现在,不是 12 或 24 个月。

如果流“不是那么大的东西”;那么好吧,也许你必须在将来的某个时候重写一些代码。

长话短说:这是关于平衡潜在风险和潜在收益。看来你已经取得了一些积极的经验;所以我认为一个合理的折衷方案是:应用流,但以一种受控的方式。所以,后来的决定“走错了,干掉他们”并不会变得太昂贵。

【讨论】:

  • 完全同意,这是问题的一部分,对并行流及其对服务器的作用存在疑问,我只在测试服务器上对其进行了测试,但我没有资源来模仿甚至部分要检查当前生产系统是否在大规模上运行良好。所以我认为有人可能已经开始了,这可以给我们一个提示。
  • 根据您上次的编辑,这就是我们实际所做的,我们只重新实现了来自整个系统的两个调用。
  • 我不一定会去更改大量现有代码。 new 代码使用并行流;并收集经验。
  • 触发重新实现的原因是当前代码的性能非常低。
【解决方案2】:

既然我写了你链接到的文章,我应该说几句话。

正如其他人所说,试试看。 Parallel Streams 想要拆分成平衡树:拆分左、右、左、右。我这样做了,那么性能就很好。如果不是,那么性能很糟糕。

框架使用二元递归除法。流是线性的。那不是一个很好的匹配。永远不要忘记音量会改变一切。将缩放添加到混合中可能会让您感到惊讶,但您只有尝试过才会知道。

让我们知道结果如何。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2022-11-28
    • 2016-04-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-11-04
    相关资源
    最近更新 更多