众所周知并行程序设计易于产生 bug。更为严重的是，往往在开发过程的晚期当这些并行 bug 引起严重的损害时才能发现它们并且难于调试它们。即使彻底地对它们进行了调试，常规的单元测试实践也很可能遗漏并行 bug。在本文中，并行专家 Shmuel Ur 和 Yarden Nir-Buchbinder 解释了为什么并行 bug 如此难于捕获并且介绍了 IBM Research 的一种新的解决方案。
并行程序易于产生 bug 不是什么秘密。编写这种程序是一种挑战，并且在编程过程中悄悄产生的 bug 不容易被发现。许多并行 bug 只有在系统测试、功能测试时才能被发现或由用户发现。到那时修复它们需要高昂的费用 -- 假设能够修复它们 -- 因为它们是如此难于调试。
在本文中，我们介绍了 ConTest，一种用于测试、调试和测量并行程序范围的工具。正如您将很快看到的，ConTest 不是单元测试的取代者，但它是处理并行程序的单元测试故障的一种补充技术。
注意本文中包含了一个 示例软件包 ，一旦理解了有关 ConTest 如何工作的基本知识，您就可以自己使用该软件包进行试验。
当问任何 Java™ 开发者时，他们都会告诉您单元测试是一种好的实践。在单元测试上做适当的投入，随后将得到回报。通过单元测试，能较早地发现 bug 并且能比不进行单元测试更容易地修复它们。但是普通的单元测试方法（即使当彻底地进行了测试时）在查找并行 bug 方面不是很有效。这就是为什么它们能逃到程序的晚期 。
为什么单元测试经常遗漏并行 bug？通常的说法是并行程序（和 bug）的问题在于它们的不确定性。但是对于单元测试目的而言，荒谬性在于并行程序是非常 确定的。下面的两个示例解释了这一点。
第一个例子是一个类，该类除了打印由两部分构成的名字之外，什么也不做。出于教学目的，我们把此任务分在三个线程中：一个线程打印人名，一个线程打印空格，一个线程打印姓和一个新行。一个包括对锁进行同步和调用 wait() 和 notifyAll() 的成熟的同步协议能保证所有事情以正确的顺序发生。正如您在清单 1 中看到的，main() 充当单元测试，用名字 "Washington Irving" 调用此类：
public class NamePrinter {
private final String firstName;
private final String surName;
private final Object lock = new Object();
private boolean printedFirstName = false;
private boolean spaceRequested = false;
public NamePrinter(String firstName, String surName) {
this.firstName = firstName;
this.surName = surName;
}
public void print() {
new FirstNamePrinter().start();
new SpacePrinter().start();
new SurnamePrinter().start();
}
private class FirstNamePrinter extends Thread {
public void run() {
try {
synchronized (lock) {
while (firstName == null) {
lock.wait();
}
System.out.print(firstName);
printedFirstName = true;
spaceRequested = true;
lock.notifyAll();
}
} catch (InterruptedException e) {
assert (false);
}
}
}
private class SpacePrinter extends Thread {
public void run() {
try {
synchronized (lock) {
while ( ! spaceRequested) {
lock.wait();
}
System.out.print(' ');
spaceRequested = false;
lock.notifyAll();
}
} catch (InterruptedException e) {
assert (false);
}
}
}
private class SurnamePrinter extends Thread {
public void run() {
try {
synchronized(lock) {
while ( ! printedFirstName || spaceRequested || surName == null) {
lock.wait();
}
System.out.println(surName);
}
} catch (InterruptedException e) {
assert (false);
}
}
}
public static void main(String[] args) {
System.out.println();
new NamePrinter("Washington", "Irving").print();
}
}
|
如果您愿意，您可以编译和运行此类并且检验它是否像预期的那样把名字打印出来。 然后，把所有的同步协议删除，如清单 2 所示：
public class NakedNamePrinter {
private final String firstName;
private final String surName;
public NakedNamePrinter(String firstName, String surName) {
this.firstName = firstName;
this.surName = surName;
new FirstNamePrinter().start();
new SpacePrinter().start();
new SurnamePrinter().start();
}
private class FirstNamePrinter extends Thread {
public void run() {
System.out.print(firstName);
}
}
private class SpacePrinter extends Thread {
public void run() {
System.out.print(' ');
}
}
private class SurnamePrinter extends Thread {
public void run() {
System.out.println(surName);
}
}
public static void main(String[] args) {
System.out.println();
new NakedNamePrinter("Washington", "Irving");
}
}
|
这个步骤使类变得完全错误：它不再包含能保证事情以正确顺序发生的指令。但我们编译和运行此类时会发生什么情况呢？所有的事情都完全相同！"Washington Irving" 以正确的顺序打印出来。
此试验的寓义是什么？设想 NamePrinter 以及它的同步协议是并行类。您运行单元测试 -- 也许很多次 -- 并且它每次都运行得很好。自然地，您认为可以放心它是正确的。但是正如您刚才所看到的，在根本没有同步协议的情况下输出同样也是正确的，并且您可以安全地推断在有很多错误的协议实现的情况下输出也是正确的。因此，当您认为 已经测试了您的协议时，您并没有真正地 测试它。
现在我们看一下另外的一个例子。
下面的类是一种常见的并行实用程序模型：任务队列。它有一个能使任务入队的方法和另外一个使任务出队的方法。在从队列中删除一个任务之前，work() 方法进行检查以查看队列是否为空，如果为空则等待。enqueue() 方法通知所有等待的线程（如果有的话）。为了使此示例简单，目标仅仅是字符串，任务是把它们打印出来。再一次，main() 充当单元测试。顺便说一下，此类有一个 bug。
import java.util.*;
public class PrintQueue {
private LinkedList<String> queue = new LinkedList<String>();
private final Object lock = new Object();
public void enqueue(String str) {
synchronized (lock) {
queue.addLast(str);
lock.notifyAll();
}
}
public void work() {
String current;
synchronized(lock) {
if (queue.isEmpty()) {
try {
lock.wait();
} catch (InterruptedException e) {
assert (false);
}
}
current = queue.removeFirst();
}
System.out.println(current);
}
public static void main(String[] args) {
final PrintQueue pq = new PrintQueue();
Thread producer1 = new Thread() {
public void run() {
pq.enqueue("anemone");
pq.enqueue("tulip");
pq.enqueue("cyclamen");
}
};
Thread producer2 = new Thread() {
public void run() {
pq.enqueue("iris");
pq.enqueue("narcissus");
pq.enqueue("daffodil");
}
};
Thread consumer1 = new Thread() {
public void run() {
pq.work();
pq.work();
pq.work();
pq.work();
}
};
Thread consumer2 = new Thread() {
public void run() {
pq.work();
pq.work();
}
};
producer1.start();
consumer1.start();
consumer2.start();
producer2.start();
}
}
|
运行测试以后，所有看起来都正常。作为类的开发者，您很可能感到非常满意：此测试看起来很有用（两个 producer、两个 consumer 和它们之间的能试验 wait 的有趣顺序），并且它能正确地运行。
但是这里有一个我们提到的 bug。您看到了吗？如果没有看到，先等一下；我们将很快捕获它。
  |
|
为什么这两个示例单元测试不能测试出并行 bug？虽然原则上线程调度程序可以 在运行的中间切换线程并以不同的顺序运行它们，但是它往往 不进行切换。因为在单元测试中的并行任务通常很小同时也很少，在调度程序切换线程之前它们通常一直运行到结束，除非强迫它（也就是通过 wait()）。并且当它确实 执行了线程切换时，每次运行程序时它往往都在同一个位置进行切换。
像我们前面所说的一样，问题在于程序是太确定的：您只是在很多交错情况的一种交错（不同线程中命令的相对顺序）中结束了测试。更多的交错在什么时候试验？当有更多的并行任务以及在并行类和协议之间有更复杂的相互影响时，也就是当您运行系统测试和功能测试时 -- 或当整个产品在用户的站点运行时，这些地方将是暴露出 bug 的地方。
|
|
当进行单元测试时需要 JVM 具有低的确定性，同时是更“模糊的”。这就是要用到 ConTest 的地方。如果使用 ConTest 运行几次 清单 2 的 NakedNamePrinter， 将得到各种结果，如清单 4 所示：
清单 4. 使用 ConTest 的无修饰的 NamePrinter
>Washington Irving (the expected result) > WashingtonIrving (the space was printed first) >Irving Washington (surname + new-line printed first) > Irving Washington (space, surname, first name) |
注意不需要得到像上面那样顺序的结果或相继顺序的结果；您可能在看到后面的两个结果之前先看到几次前面的两个结果。但是很快，您将看到所有的结果。ConTest 使各种交错情况出现；由于随机地选择交错，每次运行同一个测试时都可能产生不同的结果。相比较的是，如果使用 ConTest 运行如 清单 1 所示的 NamePrinter ，您将总是得到预期的结果。在此情况下，同步协议强制以正确的顺序执行，所以 ConTest 只是生成合法的 交错。
如果您使用 ConTest 运行 PrintQueue，您将得到不同顺序的结果，这些对于单元测试来说可能是可接受的结果。但是运行几次以后，第 24 行的 LinkedList.removeFirst() 会突然抛出 NoSuchElementException 。bug 潜藏在如下的情形中：
- 启动了两个 consumer 线程，发现队列是空的，执行
wait()。 - 一个 producer 把任务放入队列中并通知两个 consumer。
- 一个 consumer 获得锁，运行任务，并把队列清空。然后它释放锁。
- 第二个 consumer 获得锁（因为通知了它所以它可以继续向下进行）并试图运行任务，但是现在队列是空的。
这虽然不是此单元测试的常见交错，但上面的场景是合法的并且在更复杂地使用类的时候可能发生这种情况。使用 ConTest 可以使它在单元测试中发生。（顺便问一下，您知道如何修复 bug 吗？注意：用 notify() 取代 notifyAll() 能解决此情形中的问题，但是在其他情形中将会失败！）
|
|
ConTest 背后的基本原理是非常简单的。instrumentation 阶段转换类文件，注入挑选的用来调用 ConTest 运行时函数的位置。在运行时，ConTest 有时试图在这些位置引起上下文转换。 挑选的是线程的相对顺序很可能影响结果的那些位置：进入和退出 synchronized 块的位置、访问共享变量的位置等等。通过调用诸如 yield() 或 sleep() 方法来尝试上下文转换。决定是随机的以便在每次运行时尝试不同的交错。使用试探法试图显示典型的 bug。
注意 ConTest 不知道实际是否已经显示出 bug -- 它没有预期程序将如何运行的概念。是您，也就是用户应该进行测试并且应该知道哪个测试结果将被认为是正确的以及哪个测试结果表示 bug。ConTest 只是帮助显示出 bug。另一方面，没有错误警报：就 JVM 规则而言所有使用 ConTest 产生的交错都是合法的。
正如您看到的一样，通过多次运行同一个测试得到了多个值。实际上，我们推荐整个晚上都反复运行它。然后您就可以很自信地认为所有可能的交错都已经执行过了。
|
|
除了它的基本的方法之外，ConTest 在显示并行 bug 方面引入了几个主要特性：
- 同步覆盖：在单元测试中极力推荐测量代码覆盖，但是在测试并行程序时使用它，代码覆盖容易产生误导。在前两个例子中，无修饰的 NamePrinter 和多 bug 的 Print Queue，给出的单元测试显示完整的语句覆盖（除了
InterruptedException处理）没有显示出 bug。 同步覆盖弥补了此缺陷：它测量在 synchronized 块之间存在多少竞争；也就是说，是否它们做了“有意义的”事情，您是否覆盖了有趣的交错。有关附加信息请参见 参考资料 。 - 死锁预防： ConTest 可以分析是否以冲突的顺序嵌套地拥有锁，这表明有死锁的危险。此分析是在运行测试后离线地进行。
- 调试帮助：ConTest 可以生成一些对并行调试有用的运行时报告：关于锁的状态的报告（哪个线程拥有哪个锁，哪个线程处于等待状态等等），当前的线程的位置的报告和关于最后分配给变量和从变量读取的值的报告。您也可以远程进行这些查询；例如，您可以从不同的机器上查询服务器（运行 ConTest）的状态。另一个对调试有用的特性可能是重放，它试图重复一个给定运行的交错（不能保证，但是有很高的可能性）。
- UDP 网络混乱：ConTest 支持通过 UDP（数据报）套接字进行网络通信的域中的并行混乱的概念。 UDP 程序不能依靠网络的可靠性；分组可能丢失或重新排序，它依靠应用程序处理这些情况。与多线程相似，这带来对测试的挑战：在正常环境中，分组往往是按正确的顺序到达，实际上并没有测试混乱处理功能。ConTest 能够模拟不利的网络状况，因此能够运用此功能并显示它的 bug。
|
|
ConTest 是为 Java 平台创建的。用于 pthread 库的 C/C++ 版本的 ConTest 在 IBM 内部使用，但是不包含 Java 版的所有特性。出于两种原因，用 ConTest 操作 Java 代码比操作 C/C++ 代码简单：同步是 Java 语言的一部分，并且字节码非常容易使用。我们正在开发用于其他库的 ConTest，例如 MPI 库。如果您想要使用 C/C++ 版的ConTest，请与作者联系。硬实时软件对于 ConTest 也是一个问题，因为工具是通过增加延迟而工作。为使用 ConTest，我们正在研究与监视硬实时软件相似的方法，但是在目前我们还不能确定如何克服此问题。
至于将来的方向，我们正在研究发布一种 监听器 体系结构，它将允许我们在 ConTest 上应用基于监听器的工具。使用监听器体系结构将使创建原子数检查器、死锁侦听器和其他分析器以及尝试不必写入有关的基础设施的新的延迟机制成为可能。
|
|
ConTest 是用于测试、调试和测量并行程序的范围的工具。它由位于以色列海法市的 IBM Research 实验室的研究人员开发，可以 从 alphaWorks 获得 ConTest 的有限制的试用版。如果您有关于 ConTest 的更多问题，请联系作者。
|
|
| 描述 | 名字 | 大小 | 下载方法 |
|---|---|---|---|
| Presentation | j-contestsynch-pres.zip | 96KB | HTTP |
| Sample code | j-contestexamples.zip | 8KB | HTTP |
|
||||
 |
关于下载方法的信息 | |
||
学习
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
- Multithreaded Java program test generation（Orit Edelstein、Eitan Farchi、Evgeny Goldin、Yarden Nir、Gil Ratsaby、Shmuel Ur；IBM Systems Journal， 2002 年 11 月）：ConTest 的作者对 ConTest 进行了深入讨论。
- Framework for testing multi-threaded Java programs （Orit Edelstein、Eitan Farchi、Evgeny Goldin、Yarden Nir、Gil Ratsaby、Shmuel Ur； Concurrency and Computation: Practice and Experience， 2003 年 2 月）：介绍作为新的测试框架的 ConTest。
- "Java theory and practice: Concurrency in JDK 5.0"（Brian Goetz，developerWorks，2004 年 11 月）：学习 JDK 5.0 中对并行的支持是如何有助于更快更容易地维护代码。
- "Java 理论与实践: JDK 5.0 中更灵活、更具可伸缩性的锁定机制" （Brian Goetz，developerWorks，2004 年 10 月）：讨论新的锁设施如何支持在 JDK 5.0 中进行高性能应用程序开发。包括对原子变量的解释。
- "Java 理论与实践: 修复 Java 内存模型，第 1 部分" and 第 2 部分（Brian Goetz，developerWorks，2004 年 2月/3月）：解释最初的 Java 平台内存模型如何破坏并行程序设计以及 JDK 5.0 做了哪些工作来修补这种损害。
- "Diagnosing Java Code: The Orphaned Thread bug pattern"（Eric Allen，developerWorks，2001 年 8 月）：看一看重要的并行 bug 模式。
- "关注性能: 等待泄漏"（Jack Shirazi and Kirk Pepperdine， developerWorks，2005 年 1 月）：演示如何发现等待漏洞，它在并行程序中经常出现。
- "Double-checked locking and the Singleton pattern"（Peter Haggar，developerWorks，2002 年 5 月）：解释为什么不应使用双层检查锁。
- "Classworking 工具箱: 用 Hansel 和 Gretel 覆盖代码"（Dennis Sosnoski，developerWorks，2005 年 2 月）：对代码覆盖技术的介绍。
- "追求代码质量: 不要被覆盖报告所迷惑"（Andrew Glover，developerWorks，2006 年1 月）：讨论使用代码覆盖测量作为代码质量指示的一些缺陷。
- Java 技术专区 有数百篇关于 Java 编程各方面的文章。
获得产品和技术