3

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

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

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

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

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

4

2 回答 2

4

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

所以它真的归结为一个模型之间的区别，你有线程可以并发访问可变变量，还有一个模型，你有有状态的参与者相互发送消息但不窥探彼此的内部。而且您绝对正确，在某些情况下，您必须在性能与使代码正确的容易性之间进行权衡。

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

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

于 2011-03-16T22:28:42.273 回答
3

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

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

于 2011-03-16T23:23:22.937 回答