从并发的角度看 Java v Scala

Question

我现在正在开始我的最后一年项目。我将从 java 和 scala 的角度研究并发方法。从 Java 并发模块出来后，我可以理解为什么人们说共享状态线程方法难以推理。由于 Java 线程运行的不确定方式，您需要担心关键部分，冒着竞争条件和死锁等风险。在 1.5 中，这个推理变得更加清晰，但仍然远非一清二楚。

乍一看，scala 似乎通过 actor 类消除了这种复杂的推理。这使程序员能够从更顺序的观点和更容易概念化的角度开发并发系统。但是，对于这个积极的方面，我说有一些缺点是对的吗？例如，假设我们想在两种情况下对一个大列表进行排序——使用 Java，您创建两个线程将列表分成两部分，担心关键部分、原子操作等并执行代码。使用 scala，因为它是“不共享任何内容”，所以您实际上必须将 list/2 传递给两个参与者来执行排序操作，对吗？

我想我的问题是，您为更简单的推理付出的代价是必须在 Scala 中将集合传递给您的 Actor 的性能开销？

我正在考虑对此进行一些基准测试(选择排序、快速排序等)，但因为一个是功能性的，一个是命令性的——我不会从算法的角度来比较苹果与苹果。

如果你们对以上内容有任何看法，我将不胜感激，希望能给我一些想法让我开始。非常感谢。

Answer 1

Scala 的优点在于，如果需要，您可以使用 Java 方式进行并发。所有 Java 类都可用。

因此，这实际上归结为您拥有可同时访问可变变量的线程的模型与您拥有相互发送消息但不窥视彼此内部结构的有状态参与者的模型之间的区别。您完全正确，在某些情况下，您必须权衡性能与使代码正确的难易程度。

我通常发现一个粗略的经验法则，如果你要让一堆线程花费大量时间等待锁打开，使用 Java 模型，并且没有干净的方法来将工作分开以避免每个人都等待该资源，并且如果执行在线程之间快速切换，那么 Java 模型远远优于参与者模型，在参与者模型中，参与者将“我完成了”消息发回主管，后者然后发出“这是新作品!”给现有的不忙 Actor 的消息。排序算法，取决于您如何设想它们，很可能属于这一类。

就我所见，对于大多数其他方面，与 Actor 相关的性能损失并不多。如果您可以将您的问题设想为大量的 react 元素(即，他们只在收到消息时需要时间)，那么 actor 的扩展性特别好(数百万 可用，尽管只有少数在任何给定的时刻都在工作)；对于线程，您需要某种额外的内部状态来跟踪谁应该做什么工作，因为您无法处理那么多 Activity 线程。