如果线程死亡或冻结，您应该编码吗？

Question

我有一个应用程序，启动10个线程。 每个线程是否工作并等待（使用生产者消费者模型）。所以当更多的工作出现时，其中一个线程被解锁并且完成工作。

一位同事在工作中坚持我应该写一些代码来监视线程“以防万一”他们冻结/不回应或死亡。

到目前为止，在我的测试中，他们工作正常，并正确关闭。

我的问题是“我应该把代码放在这么做吗？”？如果是这样，“我如何监控线程并检查它的状态”？

谢谢。 JD

Answer 1

这真的取决于情况。首先，你应该关注正确性，使其不会冻结或死亡，但如果你需要更多的可靠性，你应该首先考虑如何从这种情况中恢复正常。你应该思考它为什么会冻结或死亡，如果它真的存在，现在你可以做什么。如果你无法做出任何可以从这种情况中可靠恢复的事情，那么你甚至不应该尝试。如果可以做到这一点而不会使情况变得更糟，那么你可以去尝试这样做。

显然，如果你做出了这样的选择，你必须小心，不要把事情搞砸，并引入一些错误，这些错误实际上会让坏的事情发生。

Answer 2

理想情况下否，您的线程应该能够正常完成。监测它们不值得复杂和处理时间。如果你做得对，你就不需要监控。

Answer 3

即使您只是强制重新启动线程，您也应该始终编写线程可能挂起或死亡的机会。

Answer 4

假设您使用.NET Framework 2或更高版本进行编码，工作线程中的未处理异常将会终止整个应用程序。

除非你确定你的线程代码不会抛出异常（或者保留内存，或者抓住一个句柄，或者调用你没有编写的框架代码......），否则你首先需要的是写入你的线程入口方法是一个try/catch。

Answer 5

如果你的线程花费了很多时间等待工作，你可以考虑重构你的应用程序以使用System.Threading.ThreadPool类。这样做会将大部分线程管理卸载到框架中。

Answer 6

线程不会挂起或死亡，除非用户代码中存在错误。操作系统/框架崩溃的可能性是微不足道的，以至于实际上，这是不可能的。这就像担心硬盘不能写入文件，即使File.WriteAllBytes（）成功。它只是不会发生。

也就是说，wildcard提出了一个很好的观点，即工作线程中的未处理异常作为整个AppDomain的未处理异常填充。

Answer 7

最好的方法是使用“ThreadPool”并调用ThreadPool.QueueUserWorkItem和.Net非常有效地管理ThreadPool。

你可以设置最大线程数分配，你不需要做任何等待操作等。你也可以得到WaitHandle等待完成。而且你不需要管理线程的阻塞/解锁。