C# 你应该编码以防线程死亡或冻结吗？

我有一个可以启动10个线程的应用程序。 每个线程执行其工作并等待（使用生产者-消费者模型）。 因此，当更多的工作出现时，其中一个线程被解锁，它完成了工作

一位同事坚持认为我应该编写一些代码来监控线程“以防万一”它们冻结/不响应或死亡

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

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

谢谢。

---

JD

理想情况下不，您的线程应该能够正常完成。监视它们不值得付出复杂性和处理时间。如果操作正确，就不需要监控。

这取决于具体情况。首先，您应该关注正确性，这样它就不会冻结或消亡，但如果您需要更高的可靠性，您应该首先考虑如何从这种情况中优雅地恢复过来。你应该想一想为什么它会冻死，如果它会冻死，现在你能做什么。如果你不能从这种情况中可靠地恢复过来，你甚至不应该尝试。如果你能在不使情况恶化的情况下做到这一点，那么你可以去尝试这样做

---

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

你应该始终为线程挂起或死亡的可能性编写代码，即使您所做的只是强制重新启动线程。

假设您是针对.NET framework 2或更高版本进行编码，工作线程中未经处理的异常将杀死整个应用程序

---

除非您完全确定线程代码不会抛出异常（或保留内存，或抓取句柄，或调用未编写的框架代码…），否则您首先要在线程入口方法中编写的是try/catch。

如果线程花费大量时间等待工作，你可以考虑重构你的应用程序使用<代码>系统。线程。线程池< /代码>类。这样做会将大部分线程管理工作转移到框架上。

除非用户代码中有错误，否则线程不会挂起或挂断。操作系统/框架出错的可能性微乎其微，实际上是不可能的。这就像担心硬盘无法写入文件一样，即使file.writealBytes（）成功。这根本不会发生

这就是说，工作线程中未处理的异常会作为未处理的异常在整个AppDomain中填充。最好的方法是使用“ThreadPool”并调用ThreadPool.QueueUserWorkItem，.Net非常有效地管理线程池

---

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

始终！并在执行时包含一些

Debug.Assert（true！=false）

语句：PI同意Thorarin。请看我的答案。您计划在哪个线程上进行监视？如果它“冻结并死亡”会发生什么？每个线程都有一个与数据库中的一条记录相对应的作业要做。当线程工作时，它会更新记录。如果线程冻结或死亡，那么如果自上次更新以来已过了大约10分钟，则另一个线程将清除该记录并使其可供另一个线程使用。至于你的问题，我正在考虑从主线程启动一个新线程，这样可以进行监视（但在这个阶段还没有决定）？我的另一个问题是，如果线程冻结，我将需要启动一个新线程。我该怎么做？你可能想重新考虑一下你的设计…每个DB记录一个线程@JD，我想@Eric Lippert想说的是，如果监视其他线程的线程死亡，会发生什么，即“谁监视看守人？”。你最终陷入了第二十二条军规，因为如果你不信任所有线程，你就不能信任任何线程。谢谢。到目前为止，一切似乎都很好，线程没有死机或冻结的问题。当我关闭应用程序时，它们会正确关闭。有一个try/catch会写入日志文件（使用企业日志记录）。所以在这方面，一切都很好。