ฉันมีการพูดคุยกับเพื่อนร่วมทีมเกี่ยวกับการล็อคใน. NET เขาเป็นคนที่สดใสจริงๆมีภูมิหลังที่กว้างขวางทั้งในระดับล่างและระดับสูงกว่าการเขียนโปรแกรม แต่ประสบการณ์ของเขาในการเขียนโปรแกรมระดับล่างต่ำกว่าของฉัน อย่างไรก็ตามเขาแย้งว่าการล็อค. NET ควรหลีกเลี่ยงในระบบที่มีความสำคัญซึ่งคาดว่าจะอยู่ภายใต้ภาระหนักหากเป็นไปได้ทั้งหมดเพื่อหลีกเลี่ยงความเป็นไปได้เล็กน้อยของ "zombie thread" ที่ล้มเหลวของระบบ ฉันใช้การล็อคเป็นประจำและฉันไม่รู้ว่า "zombie thread" คืออะไรฉันจึงถาม ความประทับใจที่ฉันได้รับจากคำอธิบายของเขาก็คือว่าซอมบี้เป็นเธรดที่ถูกยกเลิก แต่ก็ยังมีทรัพยากรบางอย่างอยู่ ตัวอย่างที่เขายกให้วิธีที่เธรด zombie สามารถทำให้ระบบแตกได้เธรดจะเริ่มโพรซีเดอร์หลังจากล็อกวัตถุบางตัว จากนั้นจะถึงจุดสิ้นสุดก่อนที่จะสามารถปลดล็อคได้ สถานการณ์นี้มีโอกาสที่จะเกิดความผิดพลาดของระบบเพราะในที่สุดความพยายามที่จะดำเนินการวิธีการจะส่งผลให้เธรดทั้งหมดกำลังรอการเข้าถึงวัตถุที่จะไม่ถูกส่งคืนเนื่องจากเธรดที่ใช้วัตถุที่ถูกล็อคจะตาย

ฉันคิดว่าฉันได้รับส่วนสำคัญนี้ แต่ถ้าฉันไม่อยู่โปรดแจ้งให้เราทราบ แนวคิดนี้สมเหตุสมผลสำหรับฉัน ฉันไม่มั่นใจอย่างสมบูรณ์ว่านี่เป็นสถานการณ์จริงที่อาจเกิดขึ้นใน. 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 ทำการประมวลผลบางอย่างที่ป้องกันเธรดจากการสัมผัสกับส่วนประกอบของระบบที่อาจมีผลกระทบประเภทนี้ แต่นั่นเป็นการเก็งกำไรอย่างหมดจดและอาจเป็นไปตามข้อเท็จจริงที่ว่าฉันไม่เคยได้ยินเรื่อง "zombie threads" ก่อน. ดังนั้นฉันหวังว่าฉันจะได้รับคำติชมเกี่ยวกับสิ่งนี้ที่นี่:

1. มีคำจำกัดความที่ชัดเจนของ "เธรดซอมบี้" มากกว่าที่ฉันได้อธิบายไว้ที่นี่หรือไม่?
2. เธรดซอมบี้สามารถเกิดขึ้นได้บน. NET (ทำไม / เพราะเหตุใด?)
3. หากทำได้ฉันจะบังคับให้มีการสร้างเธรดซอมบี้ใน. NET ได้อย่างไร
4. หากทำได้ฉันจะยกระดับการล็อคโดยไม่เสี่ยงต่อสถานการณ์ของเธรด zombie ใน. NET ได้อย่างไร

ปรับปรุง

ฉันถามคำถามนี้เมื่อสองปีก่อน วันนี้สิ่งนี้เกิดขึ้น:

• มีคำจำกัดความที่ชัดเจนของ "เธรดซอมบี้" มากกว่าที่ฉันได้อธิบายไว้ที่นี่หรือไม่?

ดูเหมือนจะเป็นคำอธิบายที่ดีสำหรับฉัน - เธรดที่ยกเลิก (และไม่สามารถปล่อยทรัพยากรใด ๆ ได้อีกต่อไป) แต่ทรัพยากร (เช่นที่จับ) ยังคงอยู่และทำให้เกิดปัญหา

• เธรดซอมบี้สามารถเกิดขึ้นได้บน. 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ทันที เธรด zombie ที่เป็นผลลัพธ์จะไม่ปล่อยหมายเลขอ้างอิงไปยังไฟล์ "test.txt" และดังนั้นไฟล์จะยังคงเปิดอยู่จนกว่าโปรแกรมจะสิ้นสุดลง (คุณสามารถตรวจสอบกับ process explorer หรือที่คล้ายกัน) หมายเลขอ้างอิงของ "test.txt" จะไม่ออกจนกว่าGC.Collectจะมีการเรียก - กลายเป็นว่ามันยากยิ่งกว่าที่ฉันคิดในการสร้างเธรดซอมบี้ที่รอยรั่วจับได้)

• หากทำได้ฉันจะยกระดับการล็อคโดยไม่เสี่ยงต่อสถานการณ์ของเธรด zombie ใน. NET ได้อย่างไร

อย่าทำสิ่งที่ฉันเพิ่งทำ!

ตราบใดที่โค้ดของคุณล้างตัวเองอย่างถูกต้อง (ใช้การจัดการที่ปลอดภัยหรือคลาสที่เทียบเท่าหากทำงานกับทรัพยากรที่ไม่มีการจัดการ) และตราบใดที่คุณไม่ต้องออกนอกเส้นทางของคุณเพื่อฆ่าเธรดด้วยวิธีแปลก ๆ และมหัศจรรย์ (วิธีที่ปลอดภัยที่สุดเป็นเพียง เพื่อไม่ฆ่าเธรด - ให้พวกเขายุติตัวเองตามปกติหรือผ่านข้อยกเว้นหากจำเป็น) วิธีเดียวที่คุณจะมีบางสิ่งที่คล้ายกับเธรดซอมบี้คือถ้ามีบางสิ่งผิดปกติมาก (เช่นมีอะไรผิดพลาดใน CLR)

ในความเป็นจริงมันยากที่จะสร้างกระทู้ซอมบี้ (ฉันต้อง P / เรียกใช้ในฟังก์ชั่นที่บอกให้คุณทราบในเอกสารไม่ต้องเรียกมันนอก 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เรียกใช้ (ซึ่งเป็นส่วนหนึ่งของ finalizer fileที่อยู่ภายใต้ฝาครอบใช้SafeFileHandleเพื่อตัดการจัดการไฟล์)

ตัวอย่างการล็อกในคำตอบ C.Evenhuisน่าจะเป็นวิธีที่ง่ายที่สุดในการล้มเหลวในการปล่อยทรัพยากร (การล็อคในกรณีนี้) เมื่อเธรดถูกยกเลิกด้วยวิธีที่ไม่แปลก แต่ก็แก้ไขได้อย่างง่ายดายโดยการใช้lockคำสั่งแทนหรือ วางการวางจำหน่ายในfinallyบล็อก

ดูสิ่งนี้ด้วย

• รายละเอียดปลีกย่อยของ C # IL codegen สำหรับกรณีที่ละเอียดมากซึ่งข้อยกเว้นสามารถป้องกันการล็อกไม่ให้ถูกปล่อยแม้ว่าจะใช้lockคำหลัก (แต่ใน. Net 3.5 และรุ่นก่อนหน้าเท่านั้น)
• การล็อคและการยกเว้นจะไม่รวมกัน

ฉันได้คำตอบของฉันหมดแล้ว แต่ได้ทิ้งต้นฉบับไว้ด้านล่างเพื่อการอ้างอิง

เป็นครั้งแรกที่ฉันได้ยินคำว่า zombies ดังนั้นฉันจะถือว่าคำจำกัดความของมันคือ:

เธรดที่ถูกยกเลิกโดยไม่ปล่อยทรัพยากรทั้งหมด

ดังนั้นเมื่อนิยามแล้วคุณก็สามารถทำได้ใน. NET เช่นเดียวกับภาษาอื่น ๆ (C / C ++, java)

อย่างไรก็ตามฉันไม่คิดว่านี่เป็นเหตุผลที่ดีที่จะไม่เขียนเธรดรหัสภารกิจสำคัญใน. NET อาจมีเหตุผลอื่นในการตัดสินใจกับ. NET แต่การเขียน. NET เพียงเพราะคุณสามารถมีเธรดซอมบี้อย่างใดไม่เหมาะสมกับฉัน หัวข้อซอมบี้เป็นไปได้ใน C / C ++ (ฉันยังยืนยันว่ามันง่ายกว่าที่จะเลอะใน C) และแอพเธรดที่สำคัญจำนวนมากนั้นอยู่ใน C / C ++ (การซื้อขายในปริมาณมากฐานข้อมูล ฯลฯ )

บทสรุป หากคุณกำลังตัดสินใจใช้ภาษาอยู่ฉันขอแนะนำให้คุณพิจารณาภาพรวม: ประสิทธิภาพทักษะของทีมกำหนดการรวมกับแอพที่มีอยู่ ฯลฯ แน่นอนว่าหัวข้อซอมบี้เป็นสิ่งที่คุณควรนึกถึง แต่เนื่องจากเป็นการยากที่จะทำผิดพลาดจริง ๆ ใน. NET เมื่อเทียบกับภาษาอื่นเช่น C ฉันคิดว่าข้อกังวลนี้จะถูกบดบังโดยสิ่งอื่น ๆ เช่นที่กล่าวไว้ข้างต้น โชคดี!

คำตอบเดิม Zombies ^†สามารถมีอยู่ได้ถ้าคุณไม่เขียนรหัสเธรดที่เหมาะสม เช่นเดียวกับภาษาอื่นเช่น C / C ++ และ Java แต่นี่ไม่ใช่เหตุผลที่จะไม่เขียนโค้ดเธรดใน. NET

และเหมือนกับภาษาอื่น ๆ รู้ราคาก่อนใช้บางอย่าง นอกจากนี้ยังช่วยให้ทราบว่าเกิดอะไรขึ้นภายใต้ประทุนเพื่อให้คุณสามารถคาดการณ์ปัญหาที่อาจเกิดขึ้นได้

รหัสที่เชื่อถือได้สำหรับระบบที่มีความสำคัญต่อภารกิจไม่ใช่เรื่องง่ายที่จะเขียนไม่ว่าคุณจะใช้ภาษาใดก็ตาม แต่ฉันคิดว่ามันเป็นไปไม่ได้ที่จะทำอย่างถูกต้องใน. NET นอกจากนี้ AFAIK,. NET เธรดก็ไม่แตกต่างจากเธรดใน C / C ++ มันใช้ (หรือสร้างจาก) การเรียกระบบเดียวกันยกเว้นการสร้างเฉพาะ. net เฉพาะบางอย่าง (เช่นเวอร์ชันน้ำหนักเบาของ RWL และคลาสเหตุการณ์)

^† _{ครั้งแรกที่ผมเคยได้ยินคำว่าซอมบี้ แต่ขึ้นอยู่กับคำอธิบายของคุณเพื่อนร่วมงานของคุณอาจจะหมายถึงหัวข้อที่สิ้นสุดโดยไม่ต้องปล่อยทรัพยากรทั้งหมด สิ่งนี้อาจทำให้เกิดการหยุดชะงักการรั่วไหลของหน่วยความจำหรือผลข้างเคียงที่ไม่ดีอื่น ๆ เห็นได้ชัดว่าไม่ได้เป็นสิ่งที่น่าพึงพอใจ แต่การแยกแยะ NET ออกมาเนื่องจากความเป็นไปได้นี้อาจไม่ใช่ความคิดที่ดีเนื่องจากเป็นไปได้ในภาษาอื่นด้วย ฉันยังยืนยันว่ามันจะเลอะง่ายใน C / C ++ มากกว่าใน. NET (โดยเฉพาะอย่างยิ่งใน C ที่คุณไม่มี RAII) แต่มีแอพสำคัญมากมายที่เขียนด้วย C / C ++ ใช่ไหม? ดังนั้นมันขึ้นอยู่กับสถานการณ์ของคุณ หากคุณต้องการที่จะดึงออนซ์ความเร็วทุกจากโปรแกรมของคุณและต้องการที่จะได้ใกล้เคียงกับโลหะเปลือยที่เป็นไปได้แล้ว .NET อาจไม่ใช่ทางออกที่ดีที่สุด หากคุณอยู่ในงบประมาณที่ จำกัด และทำการเชื่อมต่อกับเว็บเซอร์วิส /. net libraries ที่มีอยู่ / etc. NET อาจเป็นทางเลือกที่ดี}

ตอนนี้คำตอบส่วนใหญ่ของฉันได้รับการแก้ไขโดยความคิดเห็นด้านล่าง ฉันจะไม่ลบคำตอบเพราะฉันต้องการคะแนนชื่อเสียงเนื่องจากข้อมูลในความคิดเห็นอาจมีประโยชน์ต่อผู้อ่าน

Immortal Blue ชี้ให้เห็นว่าใน. NET 2.0 ขึ้นไปfinallyบล็อกมีภูมิคุ้มกันต่อด้ายยกเลิก และตามที่คอมเม้นต์โดย Andreas Niedermair สิ่งนี้อาจไม่ได้เป็นเธรดซอมบี้จริง แต่ตัวอย่างต่อไปนี้แสดงให้เห็นว่าการยกเลิกเธรดสามารถทำให้เกิดปัญหาได้อย่างไร:

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() { }บล็อกfinallyจะยังคงถูกเรียกใช้เมื่อ a ThreadAbortExceptionถูกไล่ออกด้วยวิธีนั้น

ข้อมูลต่อไปนี้จะเปิดใช้งานได้เฉพาะกับ. NET 1 และ. NET 1.1 เท่านั้น:

หากภายในlock() { }บล็อกมีข้อยกเว้นอื่นเกิดขึ้นและการThreadAbortExceptionมาถึงอย่างแน่นอนเมื่อfinallyบล็อกกำลังจะถูกเรียกใช้การล็อคจะไม่ถูกปลด ดังที่คุณกล่าวถึงlock() { }บล็อกจะถูกรวบรวมเป็น:

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

หากมีเธรดอื่นโทรThread.Abort()เข้ามาในfinallyบล็อกที่สร้างขึ้นล็อคอาจไม่สามารถใช้งานได้

นี่ไม่ใช่เรื่องของ Zombie Zombie แต่หนังสือ Effective C # มีหัวข้อเกี่ยวกับการใช้ IDisposable (รายการที่ 17) ซึ่งพูดถึงวัตถุซอมบี้ที่ฉันคิดว่าคุณน่าสนใจ

ฉันขอแนะนำให้อ่านหนังสือด้วยตัวเอง แต่สิ่งสำคัญของมันคือถ้าคุณมีคลาสที่ใช้ IDisposable หรือมี Desctructor สิ่งเดียวที่คุณควรทำคือปล่อยทรัพยากร หากคุณทำสิ่งอื่นที่นี่ก็มีโอกาสที่วัตถุจะไม่ถูกเก็บขยะ แต่จะไม่สามารถเข้าถึงได้ในทางใดทางหนึ่ง

มันให้ตัวอย่างคล้ายกับด้านล่าง:

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

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

เมื่อ destructor บนวัตถุนี้ถูกเรียกการอ้างอิงถึงตัวเองอยู่ในรายการส่วนกลางซึ่งหมายความว่ามันยังมีชีวิตอยู่และอยู่ในความทรงจำตลอดอายุการใช้งานของโปรแกรม แต่ไม่สามารถเข้าถึงได้ นี่อาจหมายความว่าทรัพยากร (โดยเฉพาะอย่างยิ่งทรัพยากรที่ไม่มีการจัดการ) อาจไม่ได้รับการเผยแพร่อย่างเต็มที่ซึ่งอาจทำให้เกิดปัญหาที่อาจเกิดขึ้นได้ทุกประเภท

ตัวอย่างที่สมบูรณ์ยิ่งขึ้นอยู่ด้านล่าง เมื่อถึงเวลาที่ foreach loop คุณมีวัตถุ 150 รายการใน Undead แต่ละรายการมีภาพ แต่ภาพนั้นเป็น GC'd และคุณได้รับการยกเว้นหากคุณพยายามใช้ ในตัวอย่างนี้ฉันได้รับ 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 และฉันได้รับการเตือนเรื่องนี้และคิดว่าคนอื่นอาจคิดว่ามันน่าสนใจ!

สำหรับระบบที่สำคัญภายใต้ภาระหนักการเขียนโค้ดที่ไม่ล็อคจะดีกว่าเป็นหลักเนื่องจากการปรับปรุงประสิทธิภาพ ดูสิ่งต่างๆเช่นLMAXและวิธีใช้ประโยชน์จาก "ความเห็นอกเห็นใจเชิงกล" เพื่อการอภิปรายที่ยอดเยี่ยมเกี่ยวกับเรื่องนี้ กังวลเกี่ยวกับเธรดซอมบี้ไหม ฉันคิดว่าเป็นกรณีที่เป็นข้อผิดพลาดที่จะรีดออกและไม่ใช่เหตุผลที่ดีพอที่จะไม่ใช้lockผมคิดว่าเป็นกรณีขอบนั่นเป็นเพียงข้อผิดพลาดที่จะรีดออกและไม่ได้เป็นเหตุผลที่ดีพอที่จะไม่ใช้

ดูเหมือนว่าเพื่อนของคุณจะเป็นคนที่มีความเพ้อฝันและแสดงความรู้เกี่ยวกับคำศัพท์ที่แปลกใหม่ให้กับฉัน! ตลอดเวลาที่ฉันใช้งานแล็บประสิทธิภาพที่ Microsoft UK ฉันไม่เคยเจอตัวอย่างของปัญหานี้ใน. NET

1. มีคำจำกัดความที่ชัดเจนของ "zombie thread" มากกว่าที่ฉันได้อธิบายไว้ที่นี่หรือไม่?

ฉันยอมรับว่ามี "Zombie Threads" อยู่มันเป็นคำที่อ้างถึงสิ่งที่เกิดขึ้นกับ Threads ที่เหลืออยู่กับทรัพยากรที่พวกเขาไม่ปล่อยให้ไปและยังไม่ตายอย่างสมบูรณ์ดังนั้นชื่อ "zombie" ของคุณ คำอธิบายการอ้างอิงนี้ค่อนข้างถูกต้องกับเงิน!

2.Can zombie เธรดเกิดอะไรขึ้นบน. (ทำไม / เพราะเหตุใด?)

ใช่พวกเขาสามารถเกิดขึ้นได้ เป็นข้อมูลอ้างอิงและ Windows อ้างอิงจริง ๆ ว่า "zombie": MSDN ใช้ Word "Zombie" สำหรับกระบวนการ / เธรดที่ตายแล้ว

การเกิดขึ้นบ่อยครั้งเป็นอีกเรื่องหนึ่งและขึ้นอยู่กับเทคนิคการเขียนรหัสและแนวทางปฏิบัติของคุณสำหรับคุณเช่น Thread Locking และได้ทำไปซักพักแล้วฉันจะไม่กังวลเกี่ยวกับสถานการณ์ที่เกิดขึ้นกับคุณ

และใช่ดังที่ @KevinPanko พูดถึงอย่างถูกต้องในความคิดเห็น "Zombie Threads" มาจาก Unix ซึ่งเป็นสาเหตุที่ใช้ใน XCode-ObjectiveC และเรียกว่า "NSZombie" และใช้สำหรับการดีบัก มันมีพฤติกรรมเหมือนกัน ... ความแตกต่างเพียงอย่างเดียวคือวัตถุที่ควรจะตายกลายเป็น "ZombieObject" สำหรับการดีบั๊กแทนที่จะเป็น "Zombie Thread" ซึ่งอาจเป็นปัญหาที่อาจเกิดขึ้นกับโค้ดของคุณ

ฉันสามารถสร้างหัวข้อซอมบี้ได้ง่ายพอ

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

สิ่งนี้รั่วที่จับเธรด (สำหรับ Join() ) มันเป็นเพียงแค่หน่วยความจำอื่นรั่วไหลเท่าที่เรากังวลในโลกที่มีการจัดการ

ตอนนี้การฆ่าเธรดในแบบที่มันถือล็อคจริงๆแล้วเป็นความเจ็บปวดทางด้านหลัง แต่เป็นไปได้ อีกคนหนึ่งExitThread()ทำงานได้ ในขณะที่เขาพบว่าตัวจัดการไฟล์ได้รับการทำความสะอาดโดย gc แต่lockวัตถุรอบ ๆ จะไม่เกิดขึ้น แต่ทำไมคุณถึงทำอย่างนั้น?