(如果可能的话)不要使用线程，使用actor /活动对象。易于测试。

(如果可能的话)不要使用线程，使用actor /活动对象。易于测试。

我最近发现了一个叫做Threadsafe的工具(用于Java)。它是一个静态分析工具，很像findbugs，但专门用于发现多线程问题。它不是测试的替代品，但我可以推荐它作为编写可靠的多线程Java的一部分。

它甚至可以捕捉到一些非常微妙的潜在问题，比如类包容、通过并发类访问不安全的对象以及在使用双重检查锁定范式时发现丢失的volatile修饰符。

如果您编写多线程Java，请尝试一下。

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

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

有一篇关于这个主题的文章，在示例代码中使用Rust作为语言:

https://medium.com/@polyglot_factotum/rust-concurrency-five-easy-pieces-871f1c62906a

总而言之，诀窍在于编写并发逻辑，使其对涉及多个执行线程的非确定性具有健壮性，使用通道和condvars等工具。

然后，如果这就是您构建“组件”的方式，那么测试它们的最简单方法是使用通道向它们发送消息，然后阻塞其他通道以断言组件发送某些预期的消息。

链接到的文章完全使用单元测试编写。

一个简单的测试模式可以用于一些(不是所有!)用例，就是多次重复相同的测试。例如，假设你有一个方法:

def process(input):
    # Spawns several threads to do the job
    # ...
    return output

创建一堆测试:

process(input1) -> expect to return output1
process(input2) -> expect to return output2
...

现在将每个测试运行多次。

如果流程的实现包含一个微小的错误(例如死锁、竞态条件等)，出现的概率为0.1%，那么运行1000次测试，则该错误至少出现一次的概率为64%。运行测试10000次，得到>99%的概率。