来自并发观点的Java v Scala

Question

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

在初看来，斯卡拉似乎通过演员类去除了这种复杂的推理。这使得程序员能够从更连续的观点开发并发系统，并且更容易概念化。但是，对于这个积极的方面，我是否有说缺点？例如，假设我们想要在两种情况下对一个大列表进行排序 - 用java创建两个线程将列表分成两部分，担心关键部分，原子操作等并执行代码。有了scala，因为它是“无分享”，你实际上必须通过列表/ 2到两个演员来执行排序操作，对吧？

我想我的问题是，你为简单的推理付出的代价是不得不将收集传递给你的演员，在斯卡拉的性能开销？

我的想法做一些基准测试这种效果（选择排序，快速排序等），但因为一个是功能，一个是势在必行 - 我不会跟苹果从算法的观点比较苹果。

我真的很感激你们对上述任何观点，给我一些想法让我开始。 非常感谢。

Answer 1

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

所以它真的归结到您必须用可变变量的并发访问的线程模型，并在那里你有哪些消息发送到对方，但不偷看对方的内部状态的行为模型之间的区别。您绝对正确的做法是，在某些情况下，您必须权衡性能，以便让代码正确无误。

我通常会发现，如果您将有一堆线程花费大量时间等待锁打开，使用Java模型，并且没有干净的方式将工作分开以避免每个人都在等待该资源，并且如果执行在线程之间快速切换，那么Java模型远远优于演员向主管发送“我已完成”消息的演员模型，然后发出“这是新工作！”消息给现有的非繁忙演员。排序算法，取决于你如何设想他们，可以非常落后于这个类别。

对于大多数其他事情来说，与演员相关的表演损失并不如我见过的那么多。如果你能想象你的问题，因为很多很多的活性元素（即他们只需要时，他们已经收到了消息的时间），然后演员可以扩展特别好（百万提供，虽然只有一小部分是在任何给定的工作瞬间）;与线程，你需要有某种额外的内部状态，以跟踪谁应该做的工作，因为你无法处理如此之多的活动线程。

Answer 2

我只是要在这里指出的Scala不会复制传递给演员参数，所以参与者可以共享不管它传递给他们。

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