运行多个线程并不困难;这是小菜一碟。不幸的是，线程通常需要彼此通信;这就是困难所在。

最初发明的允许模块之间通信的机制是函数调用;当模块A想要与模块B通信时，它只调用模块B中的一个函数。不幸的是，这对线程不起作用，因为当你调用一个函数时，该函数仍然运行在当前线程中。

为了克服这个问题，人们决定采用一种更原始的通信机制:只声明一个特定的变量，并让两个线程都可以访问该变量。换句话说，允许线程共享数据。分享数据是人们自然而然想到的第一件事，这似乎是一个不错的选择，因为它看起来非常简单。我是说，能有多难，对吧?会出什么问题呢?

竞态条件。这就是可能、也将会出错的地方。

当人们意识到他们的软件由于竞争条件而遭受随机的、不可复制的灾难性失败时，他们开始发明复杂的机制，如锁和比较-交换，旨在防止此类事情的发生。这些机制属于广义的“同步”范畴。不幸的是，同步有两个问题:

这是很难做到的，所以很容易出现bug。 它是完全不可测试的，因为您无法测试竞态条件。

精明的读者可能会注意到“非常容易出现bug”和“完全不可测试”是一个致命的组合。

现在，在自动化软件测试的概念变得流行之前，我上面提到的机制已经被行业的大部分人发明和采用了;所以，没有人知道这个问题有多致命;他们只是认为这是一个很难的主题，需要高手程序员，每个人都能接受。

如今，无论我们做什么，我们都把测试放在第一位。所以，如果某些机制是不可测试的，那么使用该机制就是不可能的。因此，同步已经失宠;现在还在练的人已经很少了，而且练的人一天比一天少。

没有同步线程就不能共享数据;然而，最初的要求不是共享数据;它允许线程之间进行通信。除了共享数据之外，还存在其他更优雅的线程间通信机制。

其中一种机制是消息传递，也称为事件。

对于消息传递，整个软件系统中只有一个地方利用了同步，那就是我们用来存储消息的并发阻塞队列收集类。(我们的想法是，我们应该至少能把那一小部分做对。)

消息传递的优点是它不受竞态条件的影响，并且是完全可测试的。

Pete Goodliffe有一个关于线程代码单元测试的系列。

是很困难的。我采用了更简单的方法，尽量将线程代码从实际测试中抽象出来。皮特确实提到了我分手的方式是错误的但我要么是正确的，要么就是我很幸运。

我喜欢编写两个或多个测试方法在并行线程上执行，并且每个方法都调用被测对象。我一直在使用Sleep()调用来协调来自不同线程的调用顺序，但这并不真正可靠。它也慢得多，因为你必须睡足够长的时间，时间通常是有效的。

我从编写FindBugs的同一组中找到了多线程TC Java库。它允许您在不使用Sleep()的情况下指定事件的顺序，而且它是可靠的。我还没试过。

这种方法的最大限制是它只允许您测试您怀疑会引起麻烦的场景。正如其他人所说，您确实需要将多线程代码隔离到少量简单类中，以便有希望彻底测试它们。

一旦您仔细测试了您预计会导致问题的场景，那么在类中抛出一堆并发请求的不科学测试是寻找意外问题的好方法。

更新:我已经玩了一些多线程TC Java库，它工作得很好。我还将它的一些特性移植到一个。net版本，我称之为TickingTest。

如果你正在测试简单的new Thread(runnable).run() 您可以模拟Thread来按顺序运行可运行对象

例如，如果被测试对象的代码像这样调用一个新线程

Class TestedClass {
    public void doAsychOp() {
       new Thread(new myRunnable()).start();
    }
}

然后模拟new Threads并按顺序运行runable参数会有所帮助

@Mock
private Thread threadMock;

@Test
public void myTest() throws Exception {
    PowerMockito.mockStatic(Thread.class);
    //when new thread is created execute runnable immediately 
    PowerMockito.whenNew(Thread.class).withAnyArguments().then(new Answer<Thread>() {
        @Override
        public Thread answer(InvocationOnMock invocation) throws Throwable {
            // immediately run the runnable
            Runnable runnable = invocation.getArgumentAt(0, Runnable.class);
            if(runnable != null) {
                runnable.run();
            }
            return threadMock;//return a mock so Thread.start() will do nothing         
        }
    }); 
    TestedClass testcls = new TestedClass()
    testcls.doAsychOp(); //will invoke myRunnable.run in current thread
    //.... check expected 
}

上周我花了大部分时间在大学图书馆学习并发代码的调试。核心问题是并发代码是不确定的。通常，学术调试可以分为三个阵营之一:

Event-trace/replay. This requires an event monitor and then reviewing the events that were sent. In a UT framework, this would involve manually sending the events as part of a test, and then doing post-mortem reviews. Scriptable. This is where you interact with the running code with a set of triggers. "On x > foo, baz()". This could be interpreted into a UT framework where you have a run-time system triggering a given test on a certain condition. Interactive. This obviously won't work in an automatic testing situation. ;)

现在，正如上面评论者所注意到的，您可以将并发系统设计成更确定的状态。然而，如果你做得不好，你就又回到了设计顺序系统的问题上。

我的建议是，专注于制定一个非常严格的设计协议，规定什么是线程，什么不是线程。如果你限制了你的接口，使元素之间的依赖最小化，那就容易多了。

祝你好运，继续解决这个问题。

Testing MT code for correctness is, as already stated, quite a hard problem. In the end it boils down to ensuring that there are no incorrectly synchronised data races in your code. The problem with this is that there are infinitely many possibilities of thread execution (interleavings) over which you do not have much control (be sure to read this article, though). In simple scenarios it might be possible to actually prove correctness by reasoning but this is usually not the case. Especially if you want to avoid/minimize synchronization and not go for the most obvious/easiest synchronization option.

我遵循的一种方法是编写高度并发的测试代码，以使潜在的未检测到的数据竞争有可能发生。然后我运行这些测试一段时间:)我曾经无意中看到一个演讲，一些计算机科学家展示了一个这样做的工具(根据规格随机设计测试，然后疯狂地运行它们，同时检查定义的不变量是否被破坏)。

顺便说一下，我认为测试MT代码的这一方面在这里还没有提到:确定可以随机检查的代码不变量。不幸的是，找到这些不变量也是一个相当困难的问题。此外，它们在执行期间可能不会一直保持，因此您必须找到/强制执行可以期望它们为真的执行点。将代码执行到这样的状态也是一个难题(并且本身可能会引起并发性问题)。呼，这太难了!

一些有趣的链接可供阅读:

确定性交错:允许强制执行某些线程交错，然后检查不变量的框架 jMock Blitzer:压力测试同步 assertConcurrent:压力测试同步的JUnit版本 测试并发代码:简要介绍两种主要方法:蛮力(压力测试)或确定性(使用不变量)