Java 在日益流行的语言中重新创建线程和并发知识

我主要是一名Java开发人员，我已经阅读了大量关于线程和并发的深入研究。许多非常聪明的人（Doug Lea、Brian Goetz等）都写过关于这些主题的书，并为新的Java并发库做出了贡献

当我开始更多地了解Python、Ruby和其他语言时，我想知道：是否所有这些工作都必须为这些语言重新创建

是否会有或需要有“Python的Doug Lea”或“Ruby的Brian Goetz”，他们对这些语言的并发特性做出了类似的强大贡献

---

在Java中完成的所有并发工作都必须为将来的语言重新创建吗？或者，在Java中所做的工作会为未来的语言提供课程和指导吗？

并发编程的基本原理在Java之前就已经存在，并在您所谈论的Java书籍中进行了总结。concurrent库类似地源自先前关于并发编程的代码和研究论文

然而，一些实现问题是Java特有的。它有一个指定的内存模型，Java中的并发实用程序是根据具体情况定制的。经过一些修改，可以将它们移植到具有不同内存模型特征的其他语言/环境中

---

因此，您可能需要一本书来教您如何在其他语言中规范地使用并发工具，但这并不是重新发明轮子。

请记住，线程只是处理“并发”的几种可能模型之一。例如，Python拥有世界上最先进的异步（基于事件的）非线程模型之一。非阻塞模型功能非常强大，在大多数可伸缩性最高的应用程序（如nginx、lighttpd）中用作线程的替代品

---

您对其他流行语言需要线程的假设可能只是以java为中心（因此以线程为中心）世界观的一个症状。查看该页面，了解一些关于如何处理大量并发请求的模型，这些模型稍微过时，但信息量很大。

这不是flame bait，但IMHO Java提供了一种更简单、更受限制的线程和并发模型。 这不一定是一件坏事，但在它提供的粒度级别上，这意味着如果您有一个“以java为中心”的视图（如其他人所说），它为您提供的关于并发性是什么以及如何处理并发性的透视图在本质上是有限的

如果您认真对待并发性，那么就值得研究其他语言，因为存在不同的模型和习惯用法

---

一些最热门的领域是无锁编程（你会看到很多，但在C++中通常做得不好）和函数式编程（这已经存在了一段时间，但可以说，变得越来越重要。并发的一个主要例子可能是Erlang）

< P>我认为答案是肯定和否定。java可以说是最常用的命令语言（java、C++、python、Ruby等）中最明确定义的内存模型和执行语义。从某种意义上说，其他语言要么完全缺乏这一点，要么正在追赶（考虑到线程模型的不成熟，如果这是可能的话）

C++可能是一个值得注意的例外——它与C++0x走的是同一条路，在我的印象中可能已经超越了Java模型的当前状态

我说不，因为社区不是孤立的。许多从事这项工作的人都使用了不止一种语言（至少从指导的角度来看，如果不是从规范的直接手上）。因此，在从事JMM工作的人员和从事C++0x规范工作的人员之间存在着大量的串扰，因为他们基本上是在用许多相同的底层驱动程序（从底层的硬件人员和顶层的用户）解决相同的问题。我很确定JVM/CLR阵营之间在某种程度上也存在着串扰

正如其他人提到的，还有其他并发模型：Erlang和Scala中的参与者、Clojure中的代理/STM、F#中的FP崛起、Scala、Haskell、CLR land中的CCR和PLINQ等。现在是一个激动人心的时刻！我们可以使用尽可能多的并发专家，我想……）

是一个项目（我已开始并将继续致力于此），其目标是让并发成为您想要使用的工具，而不是让您感到痛苦。实际上，这意味着它主要是一个无共享模型和消息传递模型（基于Occam和Unix管道的世界视图）

这一目标的根本目的是希望让普通开发人员易于使用并发，从而避免他们遇到由许多并发方法引起的更糟糕的问题。（幻灯片上有很多演示文稿，解释了为什么会这样做）

此外，它还为您必须共享数据的情况提供了一个简单的软件事务内存模型，并使用了一个刻意简单的API

Kaaelia的主要实现是Python，Ruby和C++中有一个玩具实现。还有人将底层方法移植到了E，也移植到了Java。（尽管Java人已经消失了）（玩具的实现是健全的，如果需要被改写为本地习惯用法，可以在其他语言中工作）

也许你的问题不应该是“这些语言能学到什么”，而应该是“Java社区从别处能学到什么？”。许多学习python的人都是从其他地方来的宗教移民，并将他们对其他语言的知识带到了身边，因此从我的角度来看，python似乎已经开始向其他语言寻求灵感

例如，挑选一些具体的东西，-这是一种教小孩读写的工具，b