众所周知并行程序设计易于产生 bug。更为严重的是，往往在开发过程的晚期当这些并行 bug 引起严重的损害时才能发现它们并且难于调试它们。即使彻底地对它们进行了调试，常规的单元测试实践也很可能遗漏并行 bug。在本文中，并行专家 Shmuel Ur 和 Yarden Nir-Buchbinder 解释了为什么并行 bug 如此难于捕获并且介绍了 IBM Research 的一种新的解决方案。
并行程序易于产生 bug 不是什么秘密。编写这种程序是一种挑战，并且在编程过程中悄悄产生的 bug 不容易被发现。许多并行 bug 只有在系统测试、功能测试时才能被发现或由用户发现。到那时修复它们需要高昂的费用 -- 假设能够修复它们 -- 因为它们是如此难于调试。
在本文中，我们介绍了 ConTest，一种用于测试、调试和测量并行程序范围的工具。正如您将很快看到的，ConTest 不是单元测试的取代者，但它是处理并行程序的单元测试故障的一种补充技术。
注意本文中包含了一个 示例软件包 ，一旦理解了有关 ConTest 如何工作的基本知识，您就可以自己使用该软件包进行试验。
为什么单元测试还不够
当问任何 Java™ 开发者时，他们都会告诉您单元测试是一种好的实践。在单元测试上做适当的投入，随后将得到回报。通过单元测试，能较早地发现 bug 并且能比不进行单元测试更容易地修复它们。但是普通的单元测试方法（即使当彻底地进行了测试时）在查找并行 bug 方面不是很有效。这就是为什么它们能逃到程序的晚期 。
为什么单元测试经常遗漏并行 bug？通常的说法是并行程序（和 bug）的问题在于它们的不确定性。但是对于单元测试目的而言，荒谬性在于并行程序是非常 确定的。下面的两个示例解释了这一点。
无修饰的 NamePrinter
第一个例子是一个类，该类除了打印由两部分构成的名字之外，什么也不做。出于教学目的，我们把此任务分在三个线程中：一个线程打印人名，一个线程打印空格，一个线程打印姓和一个新行。一个包括对锁进行同步和调用 wait() 和 notifyAll() 的成熟的同步协议能保证所有事情以正确的顺序发生。正如您在清单 1 中看到的，main() 充当单元测试，用名字 "Washington Irving" 调用此类：
清单 1. NamePrinter
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 所示：
清单 2. 无修饰的 NamePrinter
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 以及它的同步协议是并行类。您运行单元测试 -- 也许很多次 -- 并且它每次都运行得很好。自然地，您认为可以放心它是正确的。但是正如您刚才所看到的，在根本没有同步协议的情况下输出同样也是正确的，并且您可以安全地推断在有很多错误的协议实现的情况下输出也是正确的。因此，当您认为 已经测试了您的协议时，您并没有真正地 测试它。
现在我们看一下另外的一个例子。
多 bug 的任务队列
下面的类是一种常见的并行实用程序模型：任务队列。它有一个能使任务入队的方法和另外一个使任务出队的方法。在从队列中删除一个任务之前，work() 方法进行检查以查看队列是否为空，如果为空则等待。enqueue() 方法通知所有等待的线程（如果有的话）。为了使此示例简单，目标仅仅是字符串，任务是把它们打印出来。再一次，main() 充当单元测试。顺便说一下，此类有一个 bug。
清单 3. PrintQueue
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 的地方。
