http://www-128.ibm.com/developerworks/cn/java/j-csp3.html
JCSP 的高级主题

级别: 中级

Abhijit Belapurkar
高级技术架构师, Infosys Technologies Limited
2005 年 7 月 11 日

Abhijit Belapurkar 通过介绍 JCSP 开发高级主题，结束了由三部分组成的介绍适用于 Java 开发人员的 CSP 的系列文章，介绍的内容包括：JCSP 与 AOP 的相似性、JCSP 与 java.util.concurrent 的比较，以及用 JCSP 进行高级同步。

如果您从开始就一直阅读这个系列，那么到了现在，您应当同意 CSP 是一个值得研究的编程范式，而 JCSP 库则值得您添加到工具包中。在第 3 部分中，我只是给您提供了更多的研究 JCSP 理由。我将从讨论 CSP 的复合技术与面向方面编程（或 AOP） 的模块化技术之间的相似性开始。然后介绍 JCSP 的一些更高级的同步构造，并讨论适合应用它们的场景，还将更广泛地讨论使用 JCSP 进行多线程编程的好处，比如验证、维护以及可应用于分布式编程的一种方法。

我还要回答以下问题：如果已经采用了 java.util.concurrent 的并发性工具，那么是否还有学习 JCSP 的必要。（显然，我认为有这个必要！）

如果还没有阅读本文的 第 1 部分 和 第 2 部分，那么在继续我们的介绍之前，您可能需要这么做。

AOP 和 CSP
面向方面编程，即 AOP，是现在大多数 Java 开发人员都知道的一个术语。AOP 把系统当成方面或者关注点的的组合，而不是单纯地将系统看成是对象的组合。它试图通过把切入点组合成独立的模块，由模块代码解决一个特定关注，从而提高系统的模块性。这些模块可以用静态或动态编织技术编织在一起。

这个系列文章中已经介绍了很多内容，所以对您来说，应当很容易就可以看出 AOP 的概念 把模块编织在一起 与 CSP 的概念 组合进程网络 之间的相似性。两个技术之间的相似（绝对不是故意的！）主要是由于后者的复合性质。

一个基于安全性检测的示例被频繁地用作 AOP 的示例。在这个示例中，包含解决应用程序安全问题的代码的模块是以方面的形式编写和打包的；然后，这个方面将应用于整个应用程序中所有适当的业务对象。为了用 CSP 解决同样的问题，可以先从编写进程开始，编写一个包含业务对象的功能的进程，再编写另一个包含应用程序的安全性检测功能的进程。然后可以用 One2One 通道把两个进程连接起来。CSP 技术的优势与 AOP 技术类似：都可以将关注点分隔开。

不要错过本系列其余部分！
“适用于 Java 程序员的 CSP”是由三部分组成的介绍通信顺序进程（Communicating Sequential Processes —— CSP）的一个系列。CSP 是并发编程的一个范式，它承认了并发编程的复杂性，却没有把复杂性留给开发人员。请阅读本系列的其他部分：

第 2 部分：用 JCSP 进行并发编程

第 3 部分： JCSP 的高级主题

高级 JCSP 同步
通道不是进程间同步的惟一可用选择，也不总是最合适的选择。通道总是在以下两个进程间同步：阅读器和写入器。是否在运行多个阅读器/写入器并不重要，因为在 Any2One、One2Any 和 Any2Any 模型中，每种类型的进程都只有一个进程能够积极地参与到通道两边进行的会话中。

为了获得更高级的同步，即在多个进程之间的同步，JCSP 提供了 Barrier、Bucket 和 CREW 构造，还提供了一个叫作 ProcessManager 的类负责管理 CSProcess 实例。

Barrier 构造
barrier 是一个 JCSP 事件，可以充当多个进程之间的同步机制。每个 barrier 都能与多个进程相关联，任何在这个 barrier 上同步的进程都将被阻塞，直到其他进程已经同步为止。

必须用需要在 Barrier 类上同步的进程的数量来创建它，其中每个进程都运行在独立的线程中。在完成当前一轮工作之后，每个进程都调用 Barrier 实例的 sync() 方法，然后等候其他进程完成。

Barrier 内部
从内部来看，Barrier 包含一个成员变量，在创建 Barrier 对象时，这个成员变量被初始化为指定的进程总数。每当进程调用 sync() 方法时，这个变量就减一，并发出 wait() 调用。（您会想起已经介绍过的内容：Java 线程在能够调用 wait() 方法之前必须一直持有恰当的锁。在这里，由于将 Barrier 的 sync() 方法标记为同步的，所以 Barrier 实例本身充当着锁的作用。） 检测是在最后一个调用 sync() 的进程所在的线程上进行的。如果成员变量变成 0，则清楚地表明，所有进程已经完成了对 sync() 的调用 ，可以安全的发出 notifyAll() 了。这时，内部的计数器被重新设置回最初提供的进程总数，从而使得 Barrier 实例可以在下一轮同步中重复使用。

注意，Barrier 并没有把进程的身份和自身关联起来。所以，只有能得到 Barrier 对象，任何进程（除了要在 Barrier 上同步的进程之外）都能调用对象上的sync，从而将一个或多个合法进程排除在外。要想防止这个问题，可以对 Barrier 对象的可见性进行严格控制，只允许那些已经在 Barrier 上同步的进程集看到它。

似曾相识！
如果您认为 Barrier 工作方式的描述听起来很熟悉，那就对了。Parallel 构造自行控制运行多个 CSProcess 实例的基础就是 Barrier 构造的底层机制。

您会想起前面介绍过，在您调用 Parallel 实例上的 run 方法时，它创建了 (n-1) 个线程来运行前面 (n-1) 个 CSProcess 实例，然后在自己的线程中运行最后一个 CSProcess 实例。所有这些进程都在一个公共的 Barrier 实例上进行 sync，这个实例是在 Parallel 类的构造函数中创建的（而且通过负责运行 CSProcess 的每个 n-1 线程的构造函数，可以将实例传递给每个线程）。

Barrier 是一个比 Parallel 级别低的构造，因此，相应地也就带来了更多的复杂性，进程可以在任意时间从 Barrier 对象 enroll（登记）或 resign（退出）。例如，在一个工作进程运行时，它可能想与时钟同步（实际上是模拟时钟滴答） ，然后停下来休息一段时间（在此期间，它应当从 barrier 退出），接着再登记到 barrier，重新开始工作。

Bucket 构造
bucket 也是一个用于多进程的同步 barrier。bucket 构造和 barrier 构造之间的区别是：在前者中，所有进程都被阻塞，直到另外一个（外部）进程决定释放它们，而释放是通过“清空 bucket”进行的。

使用 Bucket 的方法只是创建一个 bucket 构造；然后，每个需要在该构造上面同步的进程都可以调用这个 bucket 的 fallInto() 方法。fallInto() 是一个同步的方法，它维护一个内部变量，用该变量来跟踪当前（等候）的进程数量（也就是说，每有一个调用 fallInto() 方法的进程，计数器变量就加 1。）在计数增加之后，调用进程执行 wait()，这导致调用进程受阻塞。当外部进程调用 Bucket 的（也是同步的） flush() 方法时，就发送一个 notifyAll() ，唤醒所有受阻塞的线程。阻塞进程的最后计数将从这个调用中输出。

Barrier 是确定性的，而 Bucket 是非确定性的。可以保证同步到 Barrier 的进程得到重新安排，从而得以执行（在一个时间周期后，受阻时间长短等于组中最慢的进程的执行时间），同步到 Bucket 的线程受阻塞的时间是不确定的，时间长短取决于清除进程何时决定发出释放这些进程的调用。

在必须按照先后顺序处理一组进程时，Barrier 很有用。这就是说，每个进行到步骤 n 的进程都不能进行步骤 n+1，直到同组中的其他所有进程都已经完成它们的步骤 n。在每个进程都要完成自己分配的任务并且停在 bucket 中，以表明自己可以进行下一步，这种情况下，Barrier 很有用。清除进程可以周期性地清除这个 bucket （可能用某些工作调度算法），从而释放目前在 bucket 中的所有进程，开始下一组任务。

CREW 构造
并发读/排它写（Concurrent-Read-Exclusive-Write）构造，即 CREW 锁，允许多个并行阅读器访问共享资源，条件是：（1）“读”访问不会修改资源；（2）之前没有写入器正在访问资源。当写入器正在访问资源时，它对资源拥有排它权限：不管是阅读器还是写入器，都不允许访问资源。

CREW 锁的使用是为了消除争用风险（因为竞争的阅读器/写入器进程之间任意的交叉），并且由于允许多个阅读器进程并行执行而提高了性能。是否真的会有性能提升则取决于以下因素：以读模式访问资源的频率与以写模式访问资源的频率的比较、读操作和写操作的时间，以及在同一时间在冲突模式下试图访问共享资源的进程数量。

请参阅 JCSP 发行版附带的 Javadoc（在 参考资料中），以获得 CREW 锁的内部实现的精彩描述。

管理 CSProcess 实例
在 第 2 部分 中，我介绍了如何用 Parallel 构造把较低级别的“构造块”进程组合成更高级别的进程网络。虽然对于许多编程场景，这些描述都是合适的，但在这篇文章的示例中，我假设已经知道了需要创建的所有进程的全部细节。但是对于某些应用程序来说，可能会发现有必要根据只能在运行时才能计算的某些条件，动态地创建一个或多个进程，而且还应当能够管理它们。

JCSP.net
我在本文示例中使用的 JCSP 库实际上使用的是同一 JVM 中运行的线程，当然，JVM 可能正运行在单处理器或多处理器机器上。倘若您对是否有可能组合对跨许多 JVM 的进程进行通信和同步的分层网络感到怀疑，那么答案是肯定的！JCSP 库的叫作 JCSP.net 的一个变体可以让您精确地做到这点。使用 JCSP.net 编程的最大好处是：跨物理网络运行的虚拟通道看起来差不多就像您在本文中已经遇到过的本地的、单一 JVM 的通道一样，虽然很显然会更复杂一些。请参阅 参考资料，学习关于 JCSP.net 可用的商业版本的更多内容。

JCSP 为这类场景提供了一个叫作 ProcessManager 的类。这个类接受 CSProcess 实例作为输入参数，允许用以下两种不同的方法之一启动进程。如果在ProcessManager 上调用 run() 方法，那么 ProcessManager 将启动托管的进程，然后等候进程终止（被管理的进程在 ProcessManager 的线程上运行，所以，后者的运行被阻挡，直到托管的进程完成为止）。另一个选项是调用 ProcessManager 上的 start() 方法，这使托管的进程在独立的线程中启动，在这种情况下，ProcessManager 自己仍然继续运行。

管理并行优先级
我在 第 2 部分 中提到：Parallel 构造并行地运行构造函数中传递给它的数组中包含的所有 CSProcess 实例。但是在某些情况下，可能必须要为这些进程赋予不同的优先级。JCSP 提供了一个叫作 PriParallel 的类，可以为传递给它的进程加上优先级。

受控制的进程的优先级是由进程在数组中的位置索引决定的。在数组中，放在前面的进程拥有更高的优先级。注意，JCSP 以底层线程的优先级机制实现进程的优先级；所以优先级实际的工作方式取决于底层的 JVM 实现。

越来越多的构造！
迄今为止讨论的构造（从第 2 部分开始到现在这里）都是 JCSP 库的核心构造。可以用它们来解决普通的和高级的并发性问题，现在应当可以让您开始编写所喜爱（也没有错误）的多线程程序了。当然，在 JCSP 库中，这些问题只是冰山之一角。请考虑以下有趣的构造的应用，您也可以自己对它们进行研究：

  • BlackHoleChannel 实现 ChannelOutput 接口，包含一个空的 write() 方法。可以把任意数量的数据写入这个通道。如果想把现有进程用在不同的环境中，而 不 再使用某些输出，那么 BlackHoleChannel 类是最有用的。因为不能一直留着某个输出通道不处理（害怕造成死锁），所以最好的选择就是让进程在 BlackHoleChannel 的实例上产生输出，而 BlackHoleChannel 则有效地充当存放所生成数据的透明无底洞。

  • Paraplex 是一个进程，它将其输入通道集上的多个对象流转化到单一输出通道。等到每个输入通道上都有一些可用输入之后（在输入到达的时候就接受，没有要求或规定特定的顺序），就可以将这些输入打包成数组（数据的尺寸与输入通道的数量相同），然后把数据通过输出通道发送为单一输出。如果需要用表格的形式表现某些数据，那么 Paraplex 可能会很方便。例如，假设有一个三列的表，每列均用数字填充。前两列用前面已经介绍过的 JCSP 进程生成的数字填充：NumbersInt 为第一列生成从 0 开始的自然数序列，SquaresInt 为第二列生成对应的平方序列。一个即插即用的叫作 FibonacciInt 的 JCSP 进程（随 JCSP 库一道立即可用）可以用来为第三列生成斐波纳契数系列。

    可以容易地用一个组合了三个输入通道的 ParaplexInt 实例来处理这三个列。每个输入通道都要附着在前面提到过的三个进程中的一个的实例上。然后，ParaplexInt 的单一输出通道向 CSProcess 传送数据，后者则接着读取带有三个元素的数组，并在适当的格式化表格中输出它们。

  • Deparaplex 是一个类，它和 Paraplex 类相反， 它把数据从单一输入通道 分离 到一组输出通道。所以，Deparaplex 类可能读取一个数组对象（尺寸为 n），把数组中的每个元素逐个输出到它的 n 个输出通道上。然后，Deparaplex 进程会一直等候，直到它生成的每个元素都被写入的通道接受为止。

请参阅 JCSP 库的下载 （在 参考资料 中），以获得这结构造的更多文档，包括用例。

CSP 的好处
CSP 是基于成熟的数学理论的并发编程范式。因此，CSP 提供了丰富的设计模式和工具集，可以防范常见的多线程缺陷，例如争用风险、死锁、活动锁和资源耗尽。因为所有这些数学上的完善性都构建到了 JCSP 库中，所以可以直接用它根据规定好的指导原则来编写应用程序。 （也就是说，不必非得理解理论才能利用它；虽然清楚的了解会更有优势！）。因为存在正式的针对 Java 的 CSP 模型，所以可以分析并正式地验证用 JCSP 构造构建的任何多线程 Java 应用程序。

正如前面所指出的，AOP 的许多好处也适应于基于 CSP 的程序。基于 CSP 的程序的主要好处是关注点的分享。可以使用 CSP 作为程序的基础（例如通过 JCSP 库），还可以确保进程之间干净的解耦，因为它们只能通过通道进行交互，不能通过直接的方法调用进行交互。它还确保可以完美地把数据和应用程序逻辑封装在通道接口之后的进程之中。所有的副作用都被限制在进程的边界之内，编程实体之间的交互都是显式公开的。在基于 JCSP 的程序中，没有隐藏的互交 —— 在网络的每一级上，所有的管道都是可见的。

CSP 的第二个好处是它的复合性质。进程可以组合，从而构成更复杂的进程（复杂的进程还可以再组合起来构成更加复杂的进程），很容易地随时间推移进行修改和扩展。所以，基于 CSP 的应用程序设计特别简单并且易于理解，并且在进行维护的时候也非常健壮。CSP 的复合性质也促进了更好的重用；正如在第 2 部分的编程示例中看到的，可以用大量不同的设置使用一个 JCSP 进程，如果需要的话，可以将不希望的输出重定向到黑洞中。

用 CSP 进行并发编程的最后一个好处对于构建分布式系统的开发人员来说特别明显。在本文中，我描述了实现并发性的不同选项（运行在单一进程中的多线程、运行在一个器上的多进程和运行在多个处理器上的多进程）。通常，这些并发机制中的每一个都要求使用完全不同的执行机制、编程接口和设计范式。而一旦用 CSP 开发应用程序，那么可以在不影响（至少不非常显著）应用程序设计或代码的情况下决定在哪个平台上运行应用程序，比如，是在多线程平台上，还是单一处理器上的多进程平台上，亦或是在分布处理器上运行的多进程平台上。

JCSP 和 java.util.concurrent
大多数 Java 程序员都知道，java.util.concurrent 包是作为 J2SE 1.5 类库的标准组成部分引入的。因为JCSP 库出现的时间比这个包加入 Java 平台的时间早，所以您可能想知道是否需要两者都用，或者说您想知道，既然已经适应了 java.util.concurrent，为什么还要费力地学习 JCSP。

java.util.concurrent 包实际上是 Doug Lea 的一个很不错的流行的 util.concurrent 库的重新整理。这个包的设计目的是提供一个强壮的、高性能的标准化工具集，简化 Java 平台上的并发 —— 而这个目的已经实现了！毫无疑问！ 如果 java.util.concurrent 包中的工具适合您的应用程序，那么请使用它们，您将得到回报。

Java 中的通信线程
JCSP 不是 Java 平台上惟一可用的 CSP 实现。Java 中的通信线程（CTJ） 是另一个流行的 CSP 实现，由 Twente 大学的 Gerald Hilderink 和 Andy Bakkers 开发。请参阅 参考资料，以获得 JCSP 和 CTJ 的详细比较，比如说，比较它们的哲学、相似与不同、性能和使用场景。

但是，正如我希望的，本文中的讨论已经显示出：基于 CSP 的技术（通过 JCSP 库） 表现出的机制超出了 java.util.concurrent 的范围。可以把系统构建成通信进程的网络，并用它们组合成网中之网，实现这一点的范式既自然又简单。这不仅提高了编写多线程应用程序的体验，而且提高了产品 品质。用 JCSP 构建系统会产生干净的接口，很少有会造成产品不好维护和技术变化这类隐藏的副作用。正式的验证（即正式地推断应用程序的安全性和活动属性）对于安全敏感和高价值的财务应用程序来说也是强大的资产。

在许多情况下，这两个包不是互相排斥的：有些 JCSP 的核心要素非常有望会在 java.util.concurrent 提供的原子的低级机制顶部重新实现，新实现的开支可能要比目前使用的标准监视器机制的开支更少。

第 3 部分的结束语
在这篇介绍适用于 Java 程序员的 CSP 的系列文章中，介绍了许多基础知识。在 第 1 部分 中，我介绍了 Java 语言目前支持的多线程编程的构造。还解释了这些构造的起源，讨论了它们与 Java 平台多线程编程的 4 个常见缺陷（争用风险、死锁、活动锁和资源耗尽）之间的关系。在对第一部分进行总结时，我解释了为什么在任意、大型、复杂的多线程应用程序中，很难应用正式的理论消除编程 bug 或证明它们不存在。我推荐使用 CSP 作为这个困境的备选项。

在 第 2 部分 中，我介绍了 CSP 理论和它最流行的一个基于 Java 的实现 —— JCSP 库。我用了几个实例演示了基本的 JCSP 构造（ 例如进程、通道和警卫等）的使用。

在最后这篇文章中，我介绍了 JCSP 中的高级主题，其中包括它与面向方面编程的相似性，以及它与 Java 平台的其他一些并发编程包的比较。我还演示了一些用来解决更复杂的同步问题的 JCSP 构造，简要讨论了用 JCSP.net 包进行分布式编程的可能性。

我希望我已经表达得够清楚，用 JCSP 编写多线程 Java 应用程序有许多优势。下次您会发现，在您自己考虑（也可能要在躲避）多线程应用程序设计时，您可能想转而采用 JCSP 库。JCSP 提供了非常简化的并发编程方法，生成的程序既能对最常见的多线程应用程序开发缺陷进行验证，还易于理解、调试和长远维护它们。

致谢
非常感谢 Peter Welch 教授在我编写这个文章系列期间给予的鼓励。他在百忙之中抽出时间非常细致地审阅了草稿，并提供了许多宝贵的提高此系列文章的质量和准确性的建议。如果文章中还存在错误，那都是由于我的原因！我在文章中使用的示例基于或来自 JCSP 库的 javadoc 中提供的示例，以及 JCSP Web 站点上提供的 Powerpoint 演示文稿。这两个来源提供了需要探索的大量信息。

参考资料

关于作者
Abhijit Belapurkar 拥有位于印度德里市的印度理工学院（IIT）计算机科学的理工学士学位。在过去的 11 年中，他一直工作在分布式应用程序的架构和信息安全领域，他在使用 Java 平台构建 n 层应用程序方面大约有 6 年的工作经验。他目前是作为高级技术架构师在 J2EE 领域工作，服务于印度班加罗尔的 Infosys 科技有限公司。