从并发的角度来看 Java v Scala

Question

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

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

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

我正在考虑针对这种效果进行一些基准测试（选择排序、快速排序等；）但是因为一个是功能性的，一个是命令式的 - 我不会从算法的角度比较苹果和苹果。

非常感谢你们对上述内容的任何看法，让我有一些想法让我开始。 非常感谢。

Answer 1

Scala 的好处在于，您可以根据需要以 Java 方式进行并发。所有 Java 类都可用。

因此，这实际上归结为具有并发访问可变变量的线程的模型与具有相互发送消息但不窥视彼此内部的有状态参与者的模型之间的区别。而且你说得对，在某些情况下，你必须在性能和代码正确性之间进行权衡。

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

就其他大多数情况而言，与演员相关的性能损失并没有我所见的那么多。如果您可以将您的问题设想为大量的反应性元素（即它们只在收到消息时才需要时间），那么参与者可以特别好地扩展（数百万可用，尽管只有少数在任何给定时刻都在工作）；对于线程，您需要有某种额外的内部状态来跟踪谁应该做什么工作，因为您无法处理那么多活动线程。

Answer 2

我只想在这里指出，Scala 不会复制传递给参与者的参数，因此参与者可以共享传递给他们的任何参数。

与 Erlang 不同，程序员有责任避免共享可变的东西。但是，共享不可变的东西没有任何惩罚，因为不需要锁定它，因为对它的所有访问都是只读的。 Scala 对不可变数据结构有强大的支持。