当我从 20 年的基本、Pascal、COBOL 和 C 过程编程的背景中学习 Java 时，我当时认为，最难的事情是让我的头脑围绕 OOP 术语和概念。现在有了大约 8 年的扎实 Java 经验，我得出的结论是，在 Java 和 C# 等类似语言中编程最难的事情就是多线程/并发方面。
编写可靠且可扩展的多线程应用程序非常困难！随着处理器“更宽”而不是更快地增长的趋势，它正迅速变得至关重要。
当然，最难的领域是控制线程之间的交互以及由此产生的错误：死锁、竞争条件、陈旧数据和延迟。
所以我的问题是：您采用什么方法或方法来生成安全的并发代码，同时减少潜在的死锁、延迟和其他问题？我想出了一个有点非传统的方法，但在几个大型应用程序中效果很好，我将分享这个问题的详细答案。
【问题讨论】：
标签： multithreading multicore concurrency
这不仅适用于 Java，也适用于一般的线程编程。我发现自己只需遵循以下准则就可以避免大多数并发和延迟问题：
1/ 让每个线程运行自己的生命周期（即决定何时死亡）。它可以从外部提示（比如一个标志变量），但它完全负责。
2/ 让所有线程以相同的顺序分配和释放它们的资源 - 这保证不会发生死锁。
3/ 尽可能短的时间锁定资源。
4/ 将数据责任与数据本身一起传递 - 一旦您通知线程要处理数据，不要理会它，直到责任归还给您。
【讨论】：
有许多技术刚刚进入公众意识（例如：过去几年）。一个大的将是演员。这是 Erlang 首次引入网格铁的东西，但它已被 Scala 等新语言（JVM 上的参与者）发扬光大。虽然演员确实不能解决所有问题，但他们确实更加更容易推理您的代码并找出问题点。它们还使设计并行算法变得更加简单，因为它们强制您使用延续传递共享可变状态的方式。
Fork/Join 是您应该关注的，尤其是在您使用 JVM 时。 Doug Lea 撰写了关于该主题的开创性论文，但许多研究人员多年来一直在讨论它。据我了解，Doug Lea 的参考框架计划包含在 Java 7 中。
在侵入性稍小的层面上，通常简化多线程应用程序所需的唯一步骤就是降低锁定的复杂性。细粒度锁定（Java 5 风格）非常适合吞吐量，但很难做到正确。通过 Clojure 获得一些关注的另一种锁定方法是软件事务内存 (STM)。这本质上与传统锁定相反，因为它是乐观的而不是悲观的。您首先假设您不会有任何冲突，然后允许框架在问题发生时解决问题。数据库通常以这种方式工作。这对于碰撞率低的系统的吞吐量非常有用，但最大的胜利在于算法的逻辑组件化。无需将锁（或一系列锁）与某些数据任意关联，您只需将危险代码包装在事务中，让框架解决其余的问题。您甚至可以从像 GHC 的 STM monad 或我的实验性 Scala STM 这样的体面的 STM 实现中获得相当多的编译时检查。
有很多用于构建并发应用程序的新选项，您选择哪一种在很大程度上取决于您的专业知识、您的语言以及您尝试建模的问题类型。作为一般规则，我认为演员与持久、不可变的数据结构相结合是一个可靠的选择，但正如我所说，STM 的侵入性要小一些，有时可以产生更直接的改进。
【讨论】：
【讨论】：
对于 Java 中的线程安全，没有一个真正的答案。但是，至少有一本非常棒的书：Java Concurrency in Practice。我经常参考它（尤其是我旅行时的在线 Safari 版本）。
我强烈建议您深入阅读这本书。您可能会发现，您的非传统方法的成本和收益已经过深入研究。
【讨论】：
我通常遵循 Erlang 风格的方法。我使用主动对象模式。 它的工作原理如下。
将您的应用程序划分为非常粗粒度的单元。在我当前的一个应用程序（400.000 LOC）中，我有 appr。这些粗粒度单元中的 8 个。 这些单位根本不共享任何数据。每个单元都有自己的本地数据。每个单元都在自己的线程上运行（= 主动对象模式），因此是单线程的。您不需要单位内的任何锁。当单元需要向其他单元发送消息时，他们通过将消息发布到其他单元的队列来完成。另一个单元从队列中挑选消息并对该消息作出反应。这可能会向其他单位触发其他消息。 因此，这种类型的应用程序中唯一的锁围绕队列（每个单元一个队列和锁）。 根据定义，这种架构是无死锁的！
只要您了解了基本原理，该架构的扩展性非常好，并且非常容易实现和扩展。它喜欢将其视为应用程序中的 SOA。
通过将您的应用划分为多个单元，请记住。每个 CPU 内核的最佳长时间运行线程数为 1。
【讨论】：
我推荐基于流的编程，也就是数据流编程。它使用 OOP 和线程，我觉得这是一个自然的进步，就像 OOP 是程序化的一样。不得不说，数据流编程不是万能的，它不是通用的。
维基百科有关于这个主题的好文章：
http://en.wikipedia.org/wiki/Dataflow_programming
http://en.wikipedia.org/wiki/Flow-based_programming
此外，它还有几个优点，如令人难以置信的灵活配置、分层；程序员（组件程序员）不必编写业务逻辑，它是在另一个阶段完成的（将处理网络放在一起）。
你知道吗，make 是一个数据流系统？请参阅 make -j，尤其是在您拥有多核处理器的情况下。
【讨论】：
在多线程应用程序中编写所有代码非常...小心！我不知道有什么比这更好的答案。 （这涉及到jonnii 之类的东西）。
我听到人们争论（并同意他们的观点）传统的线程模型在未来真的行不通，所以我们将不得不开发一套不同的范例/语言来真正使用它们新奇的多核有效。像 Haskell 这样的语言，其程序很容易并行化，因为任何具有副作用的函数都必须以这种方式显式标记，还有 Erlang，不幸的是我不太了解。
【讨论】：
我建议演员模型。
【讨论】：
actor model 是您正在使用的，它是迄今为止最简单（和有效的方式）处理多线程的东西。基本上每个线程都有一个（同步的）队列（它可以依赖于操作系统或不依赖于操作系统），其他线程生成消息并将它们放入将处理消息的线程的队列中。
基本示例：
thread1_proc() {
msg = get_queue1_msg(); // block until message is put to queue1
threat1_msg(msg);
}
thread2_proc() {
msg = create_msg_for_thread1();
send_to_queue1(msg);
}
这是producer consumer问题的典型例子。
【讨论】：
这显然是一个难题。除了明显需要小心之外，我认为第一步是准确定义您需要哪些线程以及为什么需要。
像设计类一样设计线程：确保您知道是什么使它们保持一致：它们的内容以及它们与其他线程的交互。
【讨论】：
我记得当我发现 Java 的 synchronizedList 类不是完全线程安全的，而只是有条件的线程安全时，我感到有些震惊。如果我没有将我的访问（迭代器、设置器等）包装在同步块中，我仍然可能会被烧毁。这意味着我可能已经向我的团队和我的管理层保证我的代码是线程安全的，但我可能错了。我可以确保线程安全的另一种方法是使用工具来分析代码并让它通过。 STP、Actor 模型、Erlang 等是获得后一种保证形式的一些方法。能够可靠地确保程序的属性是/将是编程向前迈出的一大步。
【讨论】：
看起来你的 IOC 有点像 FBP :-) 如果 JavaFBP 代码能够得到像你这样精通编写线程安全代码艺术的人的彻底审查，那就太好了……它在 SourceForge 的 SVN 上.
【讨论】：
一些专家认为您的问题的答案是完全避免线程，因为几乎不可能避免无法预料的问题。引用The Problem with Threads:
我们开发了一个流程，其中包括 代码成熟度评级系统（有四个级别，红色、黄色、绿色和蓝色）、设计评审、代码 审查、夜间构建、回归测试和自动代码覆盖率指标。该部分 确保程序结构一致视图的内核是在 2000 年初编写的， 设计审查为黄色，代码审查为绿色。审稿人包括并发专家， 不仅仅是没有经验的研究生（Christopher Hylands（现为 Brooks）、Bart Kienhuis、John Reekie 和 [Ed Lee] 都是审稿人）。我们编写了实现 100% 代码的回归测试 覆盖... 系统本身开始被广泛使用，系统的每一次使用都锻炼了这一点 代码。在四年后的 2004 年 4 月 26 日代码陷入僵局之前，没有发现任何问题。
【讨论】：
使用多线程设计新应用程序的最安全方法是遵守规则：
设计下方无设计。
这是什么意思？
假设您确定了应用程序的主要构建块。让它成为 GUI，一些计算引擎。通常，一旦您拥有足够大的团队规模，团队中的一些人会要求“库”在这些主要构建块之间“共享代码”。虽然在开始时为主要构建块定义线程和协作规则相对容易，但所有这些努力现在都处于危险之中，因为“代码重用库”将设计得很糟糕，在需要时进行设计，并且到处都是锁和互斥锁“感觉不错”。 这些临时库是您设计之下的设计，也是您的线程架构的主要风险。
怎么办？
最后同样重要的是，考虑在您的主要构建块之间进行一些基于消息的交互；例如，参见经常提到的演员模型。
【讨论】：
我看到的核心问题是 (a) 避免死锁和 (b) 在线程之间交换数据。出租人的一个担忧（但只是轻微出租人）是避免瓶颈。我已经遇到过几个不同的乱序锁导致死锁的问题——说“总是以相同的顺序获取锁”很好，但在中型到大型系统中，实际上通常不可能确保这一点。
警告：当我想出这个解决方案时，我必须以 Java 1.1 为目标（所以并发包在 Doug Lea 眼中还不是一闪而过）——手头的工具完全同步并等待/通知。我借鉴了使用基于实时消息的系统 QNX 编写复杂的多进程通信系统的经验。
根据我使用 QNX 的经验，它存在死锁问题，但通过将消息从一个进程的内存空间处理到另一个进程来避免数据并发，我提出了一种基于消息的对象方法 - 我称之为 IOC，用于交互- 对象协调。一开始我设想我可能会像这样创建所有我的对象，但事后看来，它们只在大型应用程序的主要控制点是必要的 - “州际交换”，如果你will，不适用于道路系统中的每个“交叉口”。事实证明这是一个主要的好处，因为它们完全不是 POJO。
我设想了一个系统，其中对象在概念上不会调用同步方法，而是“发送消息”。消息可以是发送/回复的，发送者在消息被处理时等待并返回回复，或者是异步的，消息被放到队列中并在稍后阶段出列和处理。请注意，这是概念上的区别 - 消息传递是使用同步方法调用实现的。
消息系统的核心对象是IsolatedObject、IocBinding 和IocTarget。
IsolatedObject 之所以这样称呼是因为它没有公共方法；这是为了接收和处理消息而扩展的。使用反射进一步强制子对象没有公共方法，也没有任何包或受保护的方法，除了那些从 IsolatedObject 继承的方法，几乎所有这些方法都是最终的；一开始看起来很奇怪，因为当你继承IsolatedObject时，你创建了一个带有1个受保护方法的对象：
Object processIocMessage(Object msgsdr, int msgidn, Object msgdta)
其余所有方法都是处理特定消息的私有方法。
IocTarget 是一种抽象隔离对象可见性的方法，对于为另一个对象提供自引用以将信号发回给您非常有用，而不会暴露您的实际对象引用。
并且 IocBinding 只是将发送者对象绑定到消息接收者，这样就不会对发送的每条消息进行验证检查，而是使用 IocTarget 创建的。
与隔离对象的所有交互都是通过“发送”消息来实现的——接收者的 processIocMessage 方法是同步的，从而确保一次只处理一条消息。
Object iocMessage(int mid, Object dta)
void iocSignal (int mid, Object dta)
创建了这样一种情况，即隔离对象完成的所有工作都通过一个方法集中起来，接下来我通过它们在构造时声明的“分类”将对象排列在声明的层次结构中 - 只是一个将它们标识为的字符串是任意数量的“消息接收器类型”之一，它将对象置于某个预定的层次结构中。然后我使用消息传递代码来确保如果发送者本身是一个独立对象，对于同步发送/回复消息，它是层次结构中较低的对象。异步消息（信号）使用线程池中的单独线程分派给消息接收者，线程池的整个工作传递信号，因此信号可以从任何对象发送到系统中的任何接收者。信号可以传递任何所需的消息数据，但不能回复。
因为消息只能在向上方向传递（并且信号总是向上传递，因为它们是由专门为此目的运行的单独线程传递的）死锁被设计消除了。
由于线程之间的交互是通过使用 Java 同步交换消息来完成的，因此设计上同样消除了竞争条件和陈旧数据问题。
因为任何给定的接收器一次只处理一条消息，并且因为它没有其他入口点，所以消除了对对象状态的所有考虑 - 实际上，对象是完全同步的，并且不会意外地忽略任何方法；没有 getter 返回陈旧的缓存线程数据，也没有 setter 在另一个方法作用于它时更改对象状态。
由于只有主要组件之间的交互通过这种机制进行汇集，因此在实践中，这已经很好地扩展了 - 这些交互在实践中并不像我所推测的那样经常发生。
整个设计成为子系统的有序集合之一，以严格控制的方式进行交互。
请注意，这不适用于更简单的情况，即使用更传统的线程池的工作线程就足够了（尽管我经常通过发送 IOC 消息将工作线程的结果注入主系统）。它也不用于线程关闭并执行完全独立于系统其余部分的事情的情况，例如 HTTP 服务器线程。最后，它不用于资源协调器本身不与其他对象交互以及内部同步将完成工作而没有死锁风险的情况。
编辑：我应该声明交换的消息通常应该是不可变的对象；如果使用可变对象，则发送它的行为应被视为移交并导致发送者放弃所有控制权，并且最好不保留对数据的引用。就个人而言，我使用了一个可锁定的数据结构，它被 IOC 代码锁定，因此在发送时变得不可变（锁定标志是易失的）。
【讨论】：