僵尸是否存在……在.NET 中？

Question

我正在与一位队友讨论在 .NET 中的锁定问题。 他是一个非常聪明的人，在低级和高级编程方面都有广泛的背景，但他在低级编程方面的经验远远超过我。 无论如何，他认为，如果可能的话，应该在预计处于重负载下的关键系统上避免 .NET 锁定，以避免“僵尸线程”使系统崩溃的可能性很小。 我经常使用锁定，我不知道什么是“僵尸线程”，所以我问。 我从他的解释中得到的印象是，僵尸线程是一个已终止但仍以某种方式保留某些资源的线程。 他举的一个僵尸线程如何破坏系统的例子是一个线程在锁定某个对象后开始某个过程，然后在某个点在释放锁之前终止。 这种情况有可能使系统崩溃，因为最终，尝试执行该方法将导致所有线程都在等待访问永远不会返回的对象，因为使用锁定对象的线程已死。

我想我明白了这个要点，但如果我不在基地，请告诉我。 这个概念对我来说很有意义。 我并不完全相信这是在 .NET 中可能发生的真实场景。 我以前从未听说过“僵尸”，但我确实认识到在较低级别进行深入工作的程序员往往对计算基础（如线程）有更深入的了解。 然而，我确实看到了锁定的价值，而且我看到许多世界级的程序员利用锁定。 我自己评估这个的能力也有限，因为我知道lock(obj)语句实际上只是以下语法糖：

bool lockWasTaken = false;
var temp = obj;
try { Monitor.Enter(temp, ref lockWasTaken); { body } }
finally { if (lockWasTaken) Monitor.Exit(temp); }

并且因为Monitor.Enter和Monitor.Exit被标记为extern 。 似乎可以想象 .NET 会进行某种处理以保护线程免受可能产生此类影响的系统组件的影响，但这纯粹是推测性的，可能只是基于我从未听说过“僵尸线程”这一事实之前。 所以，我希望我能在这里得到一些反馈：

1. 是否有比我在这里解释的更清楚的“僵尸线程”定义？
2. .NET 上会出现僵尸线程吗？ （为什么/为什么不？）
3. 如果适用，如何强制在 .NET 中创建僵尸线程？
4. 如果适用，如何在不冒 .NET 中僵尸线程场景的风险的情况下利用锁定？

更新

两年多前我问过这个问题。 今天发生了这样的事情：

Answer 1

• 是否有比我在这里解释的更清楚的“僵尸线程”定义？

对我来说似乎是一个很好的解释 - 一个线程已经终止（因此不能再释放任何资源），但其资源（例如句柄）仍然存在并且（可能）导致问题。

• .NET 上会出现僵尸线程吗？ （为什么/为什么不？）
• 如果适用，如何强制在 .NET 中创建僵尸线程？

他们肯定会，看，我做了一个！

[DllImport("kernel32.dll")]
private static extern void ExitThread(uint dwExitCode);

static void Main(string[] args)
{
    new Thread(Target).Start();
    Console.ReadLine();
}

private static void Target()
{
    using (var file = File.Open("test.txt", FileMode.OpenOrCreate))
    {
        ExitThread(0);
    }
}

这个程序启动一个线程Target ，它打开一个文件，然后立即使用ExitThread杀死自己。 生成的僵尸线程永远不会释放“test.txt”文件的句柄，因此该文件将保持打开状态，直到程序终止（您可以使用进程资源管理器或类似工具进行检查）。 在调用GC.Collect之前，“test.txt”的句柄不会被释放——事实证明，创建一个泄漏句柄的僵尸线程比我想象的还要困难）

• 如果适用，如何在不冒 .NET 中僵尸线程场景的风险的情况下利用锁定？

不要做我刚刚做的事情！

只要您的代码正确地自行清理（如果使用非托管资源，请使用安全句柄或等效类），并且只要您不特意以奇怪而美妙的方式杀死线程（最安全的方法就是永远不要杀死线程 - 让它们正常终止自己，或者在必要时通过异常终止），您将拥有类似于僵尸线程的东西的唯一方法是出现非常错误的情况（例如，CLR 中出现问题）。

事实上，创建僵尸线程实际上非常困难（我不得不 P/Invoke 到一个函数中，该函数本质上在文档中告诉您不要在 C 之外调用它）。 例如，以下（糟糕的）代码实际上并没有创建僵尸线程。

static void Main(string[] args)
{
    var thread = new Thread(Target);
    thread.Start();
    // Ugh, never call Abort...
    thread.Abort();
    Console.ReadLine();
}

private static void Target()
{
    // Ouch, open file which isn't closed...
    var file = File.Open("test.txt", FileMode.OpenOrCreate);
    while (true)
    {
        Thread.Sleep(1);
    }
    GC.KeepAlive(file);
}

尽管犯了一些非常可怕的错误，“test.txt”的句柄仍然在调用Abort关闭（作为file终结器的一部分，在幕后使用SafeFileHandle来包装其文件句柄）

C.Evenhuis 答案中的锁定示例可能是当线程以非奇怪的方式终止时无法释放资源（在这种情况下为锁）的最简单方法，但这可以通过使用lock语句轻松解决，或将发布放在finally块中。

另见

• C# IL 代码生成的微妙之处，用于一个非常微妙的情况，即使在使用lock关键字时，异常也可以阻止锁被释放（但仅限于 .Net 3.5 及更早版本）
• 锁和异常不混合

Answer 2

我已经清理了我的答案，但将原始答案留在下面以供参考

这是我第一次听说僵尸这个词，所以我假设它的定义是：

在没有释放所有资源的情况下终止的线程

因此，鉴于该定义，是的，您可以在 .NET 中执行此操作，就像使用其他语言（C/C++、java）一样。

但是，我不认为这是不在 .NET 中编写线程关键任务代码的充分理由。 决定不使用 .NET 可能还有其他原因，但仅仅因为您可以以某种方式拥有僵尸线程而注销 .NET 对我来说没有意义。 僵尸线程在 C/C++ 中是可能的（我什至认为在 C 中更容易搞砸）并且许多关键的线程应用程序在 C/C++ 中（大批量交易、数据库等）。

结论如果您正在决定使用一种语言，那么我建议您考虑大局：性能、团队技能、日程安排、与现有应用程序的集成等。当然，僵尸线程是您应该考虑的事情，但由于与 C 等其他语言相比，在 .NET 中实际犯这个错误非常困难，我认为这种担忧将被上述其他语言所掩盖。 祝你好运！

如果您不编写正确的线程代码，则原始答案僵尸^†可能存在。 对于 C/C++ 和 Java 等其他语言也是如此。 但这并不是不在 .NET 中编写线程代码的理由。

就像使用任何其他语言一样，在使用某些东西之前要知道价格。 它还有助于了解幕后发生的事情，以便您可以预见任何潜在的问题。

无论您使用何种语言，为关键任务系统编写可靠的代码都不容易。但我确信在 .NET 中正确执行并非不可能。 同样 AFAIK，.NET 线程与 C/C++ 中的线程没有什么不同，它使用（或构建自）相同的系统调用，除了一些 .net 特定构造（如 RWL 和事件类的轻量级版本）。

^†_{我第一次听说僵尸这个词，但根据你的描述，你的同事可能是指一个线程在不释放所有资源的情况下终止。 这可能会导致死锁、内存泄漏或其他一些不良副作用。 这显然是不可取的，但因为这种可能性而将 .NET 单挑出来可能不是一个好主意，因为它在其他语言中也是可能的。 我什至认为在 C/C++ 中比在 .NET 中更容易搞砸（尤其是在没有 RAII 的 C 中），但很多关键应用程序都是用 C/C++ 编写的，对吗？ 所以这真的取决于你的个人情况。 如果您想从应用程序中提取每一盎司的速度并希望尽可能接近裸机，那么 .NET可能不是最佳解决方案。 如果您的预算紧张并且需要与 Web 服务/现有 .net 库/等进行大量交互，那么 .NET可能是一个不错的选择。}

Answer 3

现在我的大部分答案已被下面的评论纠正。 我不会删除答案， 因为我需要声望点， 因为评论中的信息可能对读者有价值。

Immortal Blue 指出，在 .NET 2.0 及更高版本中， finally块不受线程中止的影响。 正如 Andreas Niederair 所评论的，这可能不是一个真正的僵尸线程，但以下示例显示了中止线程如何导致问题：

class Program
{
    static readonly object _lock = new object();

    static void Main(string[] args)
    {
        Thread thread = new Thread(new ThreadStart(Zombie));
        thread.Start();
        Thread.Sleep(500);
        thread.Abort();

        Monitor.Enter(_lock);
        Console.WriteLine("Main entered");
        Console.ReadKey();
    }

    static void Zombie()
    {
        Monitor.Enter(_lock);
        Console.WriteLine("Zombie entered");
        Thread.Sleep(1000);
        Monitor.Exit(_lock);
        Console.WriteLine("Zombie exited");
    }
}

但是，当使用lock() { }块时，以这种方式触发ThreadAbortException时仍会执行finally 。

事实证明，以下信息仅对 .NET 1 和 .NET 1.1 有效：

如果在lock() { }块内发生了其他异常，并且ThreadAbortException恰好在finally块即将运行时到达，则不会释放锁。 正如您所提到的， lock() { }块被编译为：

finally 
{
    if (lockWasTaken) 
        Monitor.Exit(temp); 
}

如果另一个线程在生成的finally块内调用Thread.Abort() ，则锁可能不会被释放。

Answer 4

这与 Zombie 线程无关，但 Effective C# 一书中有一节关于实现 IDisposable，（第 17 项），其中讨论了我认为您可能会感兴趣的 Zombie 对象。

我建议阅读本书本身，但它的要点是，如果您有一个实现 IDisposable 或包含 Desctructor 的类，那么您唯一应该做的就是释放资源。 如果您在这里做其他事情，则对象可能不会被垃圾收集，但也无法以任何方式访问。

它给出了一个类似于下面的例子：

internal class Zombie
{
    private static readonly List<Zombie> _undead = new List<Zombie>();

    ~Zombie()
    {
        _undead.Add(this);
    }
}

当这个对象的析构函数被调用时，对自身的引用被放置在全局列表中，这意味着它在程序的生命周期内保持活动状态并在内存中，但不可访问。 这可能意味着资源（尤其是非托管资源）可能无法完全释放，从而导致各种潜在问题。

下面是一个更完整的示例。 当到达 foreach 循环时，Undead 列表中有 150 个对象，每个对象都包含一个图像，但该图像已被 GC 处理，如果您尝试使用它，则会出现异常。 在此示例中，当我尝试对图像执行任何操作时，无论是尝试保存它，还是查看高度和宽度等尺寸，我都会收到 ArgumentException（参数无效）：

class Program
{
    static void Main(string[] args)
    {
        for (var i = 0; i < 150; i++)
        {
            CreateImage();
        }

        GC.Collect();

        //Something to do while the GC runs
        FindPrimeNumber(1000000);

        foreach (var zombie in Zombie.Undead)
        {
            //object is still accessable, image isn't
            zombie.Image.Save(@"C:\temp\x.png");
        }

        Console.ReadLine();
    }

    //Borrowed from here
    //http://stackoverflow.com/a/13001749/969613
    public static long FindPrimeNumber(int n)
    {
        int count = 0;
        long a = 2;
        while (count < n)
        {
            long b = 2;
            int prime = 1;// to check if found a prime
            while (b * b <= a)
            {
                if (a % b == 0)
                {
                    prime = 0;
                    break;
                }
                b++;
            }
            if (prime > 0)
                count++;
            a++;
        }
        return (--a);
    }

    private static void CreateImage()
    {
        var zombie = new Zombie(new Bitmap(@"C:\temp\a.png"));
        zombie.Image.Save(@"C:\temp\b.png");
    }
}

internal class Zombie
{
    public static readonly List<Zombie> Undead = new List<Zombie>();

    public Zombie(Image image)
    {
        Image = image;
    }

    public Image Image { get; private set; }

    ~Zombie()
    {
        Undead.Add(this);
    }
}

再说一次，我知道你特别在问僵尸线程，但问题标题是关于 .net 中的僵尸，我想起了这一点，并认为其他人可能会觉得很有趣！

Answer 5

在重负载的关键系统上，编写无锁代码更好，主要是因为性能改进。 看看像LMAX这样的东西，以及它如何利用“机械同情”来对此进行深入讨论。 担心僵尸线程？ 我认为这是一个边缘情况，只是一个需要解决的错误，并不是不使用lock充分理由。

听起来更像是你的朋友只是在向我炫耀他对晦涩的外来术语的了解！ 在我在 Microsoft UK 运行性能实验室的所有时间里，我从未在 .NET 中遇到过此问题的实例。

Answer 6

1.“僵尸线程”的定义是否比我在这里解释的更清楚？

我确实同意“僵尸线程”的存在，它是一个术语，指的是那些留下资源的线程会发生什么，它们不会放手但还没有完全消亡，因此得名“僵尸”，所以你的这个转介的解释在金钱上非常正确！

2. .NET 上会出现僵尸线程吗？ （为什么/为什么不？）

是的，它们可以发生。 这是一个参考，实际上被 Windows 称为“僵尸”： MSDN 使用“僵尸”这个词来表示死进程/线程

经常发生是另一回事，取决于你的编码技术和实践，至于你喜欢线程锁定并且已经做了一段时间，我什至不会担心这种情况发生在你身上。

是的，正如@KevinPanko 在评论中正确提到的那样，“僵尸线程”确实来自 Unix，这就是为什么它们在 XCode-ObjectiveC 中使用并称为“NSZombie”并用于调试的原因。 它的行为方式几乎相同......唯一的区别是一个应该已经死亡的对象变成了用于调试的“ZombieObject”而不是“Zombie Thread”，这可能是您代码中的潜在问题。

Answer 7

我可以很容易地制作僵尸线程。

var zombies = new List<Thread>();
while(true)
{
    var th = new Thread(()=>{});
    th.Start();
    zombies.Add(th);
}

这会泄漏线程句柄（对于Join() ）。 就我们在​​托管领域而言，这只是另一种内存泄漏。

现在，以它实际持有锁的方式杀死一个线程是一种痛苦，但可能。 另一个人的ExitThread()完成了这项工作。 正如他发现的那样，文件句柄被 gc 清除了，但对象周围的lock却没有。 但你为什么要这样做？