Java对三种不同并发模型的支持

Question

在多线程环境(http://tutorials.jenkov.com/java-concurrency/concurrency-models.html)中，我正在经历不同的并发模型。

本文重点介绍了三种并发模型。

1. 并行工作人员 第一个并发模型是我所说的并行工作模型。传入的作业分配给不同的员工。
2. 装配线 工人们组织起来就像工人在工厂的装配线上一样。每个员工只执行全部工作的一部分。当该部分完成后，该工人将作业转发给下一个工人。 每个工作人员都在自己的线程中运行，并且不与其他工作人员共享状态。这有时也被称为共享无并发模型。
3. 函数并行 函数并行的基本思想是使用函数调用来实现程序。函数可以被看作是"agents“或"actors”，它们互相发送消息，就像在装配线并发模型(AKA反应性或事件驱动系统)中一样。当一个函数调用另一个函数时，这类似于发送消息。

现在，我想为这三个概念映射java API支持。

1. 并行工作人员：是ExecutorService，ThreadPoolExecutor，CountDownLatch API吗？
2. 装配线：向消息传递系统(如JMS )发送事件&使用队列和主题的消息传递概念。
3. 功能并行性：ForkJoinPool在某种程度上是java 8流。与流相比，ForkJoin池更容易理解。

我是否正确地映射了这些并发模型？如果没有，请纠正我。

Answer 1

这些模型中的每一个都从一般的角度说明了工作是如何完成/分离的，但是当涉及到实现时，它实际上取决于您的确切问题。一般来说，我是这样看的：

1. Parallel ：生产者在某个地方(例如在BlockingQueue中)创建新的作业，许多线程(通过ExecutorService)并行处理这些作业。当然，您也可以使用CountDownLatch，但这意味着您希望在处理了确切的N子问题之后触发一个操作(例如，您知道您的大问题可能在N较小的问题中被拆分，请检查这里的第二个例子)。
2. 装配线：对于每一个中间步骤，您都有一个BlockingQueue和一个Thread或ExecutorService。在每一步中，作业都从一个BlickingQueue中取出并放入下一个BlickingQueue中，以便进一步处理。JMS的思想是:JMS是连接分布式组件的，它是Java的一部分，被认为不用于高并发上下文(消息通常保存在硬盘上，然后再处理)。
3. 功能并行性：ForkJoinPool是如何实现这个功能的一个很好的例子。

Answer 2

一个很好的问题，对这个问题的答案可能不那么令人满意。列出的并发模型显示了实现并发系统的一些方法。API提供了用于实现任何这些模型的工具。

让我们从ExecutorService开始。它允许您以非阻塞方式提交要执行的任务。然后，ThreadPoolExecutor实现将限制最大可用线程数。ExecutorService不需要像您可能期望的并行工作人员那样执行完整的过程。任务可能仅限于流程的特定部分，并在完成后发送一条消息，该消息将启动装配线中的下一步。

CountDownLatch和ExecutorService为阻塞提供了一种方法，直到所有的工作人员都完成了，如果某个进程被划分为不同的并发子任务，这可能会派上用场。

JMS的目的是为组件之间的消息传递提供一种方法。它不强制执行特定的并发模型。队列和主题表示消息如何从发布服务器发送到订阅服务器。当您使用队列时，消息将准确地发送到一个订阅服务器。而主题则向主题的所有订阅者广播该消息。

例如，通过使用观察者模式，可以在单个组件中实现类似行为。

ForkJoinPool实际上是ExecutorService的一个实现(这可能会突出匹配模型和实现细节的困难)。它恰好是为处理大量的小任务而优化的。

摘要:在Java环境中有多种方法来实现特定的并发模型。无论所选择的并发模型如何，用于实现程序的接口、类和框架都可能有所不同。

Answer 3

Actor模型是装配线的另一个例子。例:阿克卡