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

Question

我有一个启动10个主题的应用程序。 每个线程都会工作并等待（使用生产者消费者模型）。 因此，当更多的工作出现时，其中一个线程被解除阻塞，它就能完成工作。

一位正在工作的同事坚持认为我应该编写一些监控线程的代码“以防万一”他们冻结/不响应或死亡。

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

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

感谢。 JD

Answer 1

这实际上取决于具体情况。首先，你应该专注于正确性，以便它不会冻结或死亡，但如果你需要更高的可靠性，你应该首先考虑如何从这种情况中优雅地恢复。你应该考虑为什么它可能会冻结或死亡，如果确实如此，现在你可以做什么。如果你无法做到可以从这种情况中可靠地恢复的任何好处，你甚至不应该尝试。如果可以做到这一点而不会使情况变得更糟，那么你可以尝试这样做。

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

Answer 2

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

Answer 3

假设您正在编写针对.NET框架2或更高版本的代码，工作线程中的未处理异常将终止整个应用程序。

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

Answer 4

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

Answer 5

除非用户代码中存在错误，否则线程不会挂起或死亡。 OS / Framework搞砸的可能性微不足道，实际上是不可能的。即使File.WriteAllBytes（）成功，也就像担心硬盘没有写入文件一样。它不会发生。

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

Answer 6

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

您可以设置要分配的最大线程数，也不需要执行任何等待操作等。您也可以让WaitHandle在完成后等待。而且您不需要管理阻塞/解除阻塞线程。

Answer 7

你应该总是编写线程可能挂起或死亡的机会，即使你所做的只是强行重启线程。