java和scala在多线程方面的比较
我只是听到和看到人们说 scala 是为多线程设计的，尽管它实际上是为了通用目的。
它声称“问题是，虽然您可以在 Java 中使类线程安全（如果您知道自己在做什么），但 Scala 可以让这变得简单而自然。”
AKKA和Lift确实是用scala编写的。（实际上是java和scala）
但是java也通过java.util.concurrent的新包在这方面做了改进。 那么为什么AKKA和Lift没有在JAVA中诞生呢？
也许你会说 scala 让 java 看起来像 C。:-)
任何人都可以对此有更多的见解或更深入的想法吗？
我知道 JAVA 和 scala 可以混合使用。 Scala 能够无缝调用 Java 代码。 java有什么，scala也有。
但是无论语法如何不同，scala 真正改进了 java 尚未完成的哪些功能呢？
只有一些设计，如演员/代理或其他什么？ （注意 Actors/Agents 并不能解决多线程中的所有问题。）
或者 scala 编译器和采用一些函数式语言语法真的比 java 更重要或更有帮助吗？
我听说 scala 将能够采用 XText 的消息。能够利用XText来编写线程逻辑，不确定这是真的还是假的。
Scala 看起来像是一种语言的混合体，使用这种方法可以使其更具可扩展性来解决这方面的问题？
更新
感谢您从不同角度提供的精彩回答。我认为他们都很好。无论你站在哪一边。
编辑
下面的主题（在一年前）正在询问类似的事情。 “建设性”的结论非常相似。但这一次，一些新的观点出现了，可能我问的方式有点不同。仅供参考。
相关：
实际上我很感兴趣有人可以回答这个问题从一些全新的角度来启发我的思想，提供一些以前不知道的想法。
但由于没有建设性，它被关闭了。 :-)
I just hear and see people saying scala is designed for MultiThread though it's actually for general purpose.
And it claims "The thing is that while you can make classes thread-safe in Java (if you know what you're doing ), Scala makes it easy and natural to do."
And indeed AKKA and Lift is written in scala.(actually java and scala)
But java also did improves in this aspect with the new package of java.util.concurrent.
So why didn't AKKA and Lift born in JAVA?
Maybe you will say scala makes java looks like C. :-)
Anyone can tell more insight or deeper thoughts on this?
I know the fact that it is possible to mix JAVA and scala. Scala is able to call seamlessly into Java code. So what java have,so does scala.
But what scala really improves that java haven't done yet regardless of different grammers?
Only some design like Actors/Agents or something else?
(note Actors/Agents are cannot solve all the problem in MultiThread.)
Or does scala compiler and adopting some functional language grammer really matters or helps more than in java?
I heard some news that scala is going to be able to adopt XText. To be able to leverage XText to write thread logic, not sure if this is true or not.
Scala looks like a mixture of languages and using this approach makes it more extensible to solve problems in this aspect?
UPDATE
Thanks for your excellent answers from different angles. I think they are all very good. No matter what side you are standing.
EDIT
Topic below (in SO one year ago) was asking about the similiar thing. The "constructive" conclusion is quite similiar. But this time ,some new points are coming out probably the way I am asking is a bit different. Just FYI.
Related:
Actually I am very interested in some one can answer this question in some brand new angle which could enlighten my mind , provide some idea unknown before.
But it's closed due to not constructiveness. :-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我并不是这方面的真正专家，但 Scala 是一种（至少部分是）函数式编程语言，而 Java 不是（它是命令式的）。函数式编程的一个特点是它避免（以“自然”的方式）副作用。
另一方面，线程安全主要是为了避免副作用（即不同的线程同时修改相同的对象/部分内存/其他资源）。
I am not really an expert in this, but Scala is a (partly at least) a functional programming language while Java is not (it is imperative). One feature of functional programming is that it avoids (in a 'natural' way) side-effects.
Thread-safety on the other hand is pretty much about avoiding side-effects (i.e. different threads modifying same objects/parts of memory/other resources at the same time).
就目前情况而言，我发现 Scala 在处理多线程方面比 Java 差得多。
语言规范没有定义一些真正重要的东西，你可以依赖这些东西来制作线程安全的代码。
例如，您应该知道
final实例字段在处理多个线程时非常很特殊。在构造函数完成后，保证它们的初始值对所有线程可见，即使对象是在竞争条件下发布的。Scala 不保证
val将被编译为final字段。通常情况就是如此，但由于规格没有明确说明，因此您不能认为这是理所当然的。因此，要么编写 Java 中不存在的样板同步代码，要么编写不能保证线程安全的代码（并希望编译器继续将您的 val 映射到 Final 字段）。As it is today, I find Scala much worse than Java with respect to working with multiple threads.
The language specification doesn't define some really important things, that you would rely on, to make thread-safe code.
For instance, you should know that
finalinstance fields are very special when working with multiple threads. They are guaranteed to have their initial value visible to all threads after the constructor has completed, even if the object is published with race conditions.Scala makes no guarantees that a
valwill be compiled to afinalfield. It is usually the case, but since the specs don't state it clearly, you cannot take it for granted. Therefore, either you write boilerplate synchronization code that wouldn't exist in Java, or you write code that is not guaranteed thread-safe (and hope for the compiler to continue mapping your vals to final fields).我想说这并不是实际语言的问题，而是更多关于应用简化并发编程的原则，例如不共享、消息传递、不可变对象、无副作用函数等。Scala 不是 FP 语言这是最严格的意义上，但它提供了对函数式编程技术的访问。
像 Actors/Reactor 这样的抽象是框架（而不是语言）的一部分，完全解放了开发人员直接处理线程和关键部分同步。更重要的是：从 2.9.x 开始，并行集合直接包含在库中。
I'd say it not so much a matter of the actual language, but more about applying principles which ease concurrent programming, e.g. share nothing, message passing, immutable objects, side-effect free functions, etc. Scala is not a FP language in it's strictest sense, but it delivers access to functional programming techniques.
Abstractions like Actors/Reactors, which are part of the framework (not language), completely free the developer to handle threads and critical section synchronization directly. What's more: Since 2.9.x, parallel collections are directly included in the library.