查找当前拥有锁的线程，以便我可以杀死它答案

【问题标题】：Find which thread currently owns a lock so I can kill it查找当前拥有锁的线程，以便我可以杀死它
【发布时间】：2013-06-16 22:18:43
【问题描述】：

我需要找出当前拥有锁的线程。

我正在使用托管独立应用程序实例的 ThreadPool 编写多线程服务器。关闭应用程序实例时，我调用 Monitor.TryEnter 来获取锁或超时。如果发生超时，我需要获取哪个线程拥有锁，以便我可以中止它。

如果应用程序中没有错误，我将永远不需要这样做，因为每个工作人员都会在进入和退出应用程序时锁定和解锁应用程序实例。但是，如果存在错误，并且无论出于何种原因，工作人员没有退出并且陷入死锁或陷入无限循环，我希望能够杀死该线程和应用程序实例，同时让我的服务器的其余部分继续存在。此时的应用程序实例是一个失败的原因。

似乎是一个非常直接的要求，但找不到任何内置功能。

一种解决方法是在与锁相同的上下文中添加一个线程成员，并让每个线程在获取锁时对其进行更新。但这依赖于每个人总是记得在获得锁时更新它。

【问题讨论】：

Nononononono... 中止线程只会让糟糕的情况变得更糟。不要这样做！您需要找出线程乱成一团的原因，然后解决问题
关键锁怎么可能被你无法控制的资源获取？你能详细说明一下吗？您应该将锁包装在您自己的锁实现中，该锁实现强制超时并且永远不会暴露真正的底层锁。
目前尚不清楚您认为需要这样做的原因。 CLR 已经非常有能力在进程退出时杀死线程池线程，而无需您的帮助。它是自动的，TP 线程的 IsBackground 属性设置为 true。
我目前没有遇到死锁/无休止循环的问题，因为正如您指出的那样，它是我的所有代码，我应该控制它。我想要实现的是防止应用程序实例中的死锁或无限循环影响整个系统。
如果应用程序实例有错误并且丢失了原因，那么杀死它很可能会使您的系统处于不一致状态。这就是为什么你不应该这样做。

标签： c# .net multithreading locking clr

【解决方案1】：

您认为线程控制是自上而下的层次结构，但这不是多线程应用程序问题的正确思维方式。如果线程在执行过程中出现超时或其他问题，则线程本身必须负责释放锁并自行结束。

【讨论】：

那么是不是不可能处理一个应用程序实例陷入无限循环并吸收工作线程直到服务器重新启动的情况？理想情况下，线程不应该让自己处于这种状态，但如果是这样，我想要能够杀死它的额外保护。
@Mark：杀死一个线程会使您的进程处于不确定状态。唯一安全的做法是退出该过程。操作系统是为进程隔离而设计的，而不是线程隔离。