考虑一些Mutex类实现的测试用例。测试在执行期间创建了几个std :: thread实例。如果根据测试正确实施Mutex类，则所有线程都应该完成。如果出现问题，则可能一个线程可能无限期地被阻塞。测试如何正确清理后自己？在自动测试后安全地清理阻塞std :: thread
起初我以为分离线程，但随后线程泄漏。更糟糕的是，线程依赖于测试用例内部的Mutex实例，在测试用例返回后偶尔会导致访问冲突。有些线程库在Qt的QThread中有terminate（）方法，但是我想使用std :: thread，即使Qt已经是我的项目的依赖项了。
是否存在测试潜在无限期阻塞并发代码的一般模式？
杀死可能存在锁定的线程是强制终止线程的主要原因之一，也是为什么C++ 11不支持它。你不应该这样做，这段时间。
如果你需要做这样的事情，你最好的最好的可能是产生一个新的进程来运行测试;如果它锁定了，你可以在没有相同风险的情况下终止这个过程。
有关终止线程为什么是坏消息的示例，请查看specific example from the Old New Thing on what sort of garbage thread termination leaves lying around on Windows;大多数操作系统在不同的环境下都会出现类似的问题。
我认为析构函数可以在这里得到帮助，是唯一100％确定在任何问题之后执行的设计。在离开它之前，我建议在某个析构函数内部进行一个很好的阻塞测试，并在SECURE WAY（智能指针？）中释放资源。
析构函数如何包装测试方法来解决问题？如果std :: thread实例的析构函数在这个包装析构函数中运行，那么你仍然有一个销毁正在运行的std :: thread的问题，导致你的整个应用程序被终止（崩溃）。 –
我在线程实例的析构函数中没有想到，可能是任何可以访问线程处理函数的析构函数（在最糟糕的情况下都是这样），这个问题的解决方案是收敛的（在我见过的实现的90％中）使用专用进程检查线程中的问题，因为之前的ShadowRanger注释可以使用该析构函数进行特别的测试，而不是在析构函数中运行进程。 http://stackoverflow.com/questions/29178435/safely-destroying-a-thread-pool?rq=1 检查这一点，它是不一样的，但会有所帮助。 –