trochę wyczyściłem swoją odpowiedź, ale zostawiłem oryginalną poniżej dla odniesienia

Pierwszy raz słyszę o pojęciu zombie, więc zakładam, że jego definicja brzmi:

Wątek, który zakończył się bez uwolnienia wszystkich swoich zasobów

Więc biorąc pod uwagę tę definicję, to tak, można to zrobić w. NET, jak w innych językach(C / C++, java).

Jednak, nie uważam tego za dobry powód, aby nie pisać threaded, mission critical kod w .NET. mogą być inne powody, aby zdecydować się na. Net, ale odpisywanie. NET tylko dlatego, że można mieć wątki zombie jakoś nie ma dla mnie sensu. Wątki Zombie są możliwe w C / C++ (powiedziałbym nawet, że dużo łatwiej jest popsuć w C), a wiele krytycznych, wątkowych aplikacji jest w C / C++ (handel wielkimi wolumenami, bazy danych itp.).

Wniosek Jeśli jesteś w trakcie decydowania o języku, który chcesz użyć, proponuję wziąć pod uwagę szerszy obraz: wydajność, umiejętności zespołu, harmonogram, integracja z istniejącymi aplikacjami itp. Oczywiście, wątki zombie są czymś, o czym powinieneś pomyśleć, ale ponieważ tak trudno jest rzeczywiście popełnić ten błąd w.Net w porównaniu do innych języków, takich jak C, myślę, że ten problem zostanie przyćmiony przez inne rzeczy, takie jak wymienione powyżej. Powodzenia!

Oryginalna Odpowiedź Zombie^† może istnieć, jeśli nie napiszesz odpowiedniego kodu wątkowego. To samo dotyczy innych języków, takich jak C / C++ i Java. Ale nie jest to powód, aby nie pisać kodu w .NET.

I tak jak w każdym innym języku, poznaj cenę przed użyciem czegoś. Pomaga również wiedzieć, co dzieje się pod maską, dzięki czemu można przewidzieć wszelkie potencjalne problemy.

Niezawodny kod dla Systemów o znaczeniu krytycznym nie jest łatwy do napisania, niezależnie od języka, w którym się znajdujesz. Ale jestem pewien, że nie jest to niemożliwe zrobić poprawnie w. NET. również AFAIK,. NET threading nie różni się tak bardzo od threadingu w C / C++ używa (lub jest zbudowany z) tych samych wywołań systemowych, z wyjątkiem niektórych specyficznych dla. Net konstrukcji (takich jak lekkie wersje RWL i klasy event).

^†_{pierwszy raz słyszałem o pojęciu zombie, ale na podstawie Twojego opisu kolega pewnie miał na myśli wątek, który zakończył się bez Wydania wszystkich zasobów. Może to potencjalnie spowodować impas, wyciek pamięci lub inny zły efekt uboczny. To oczywiście nie jest pożądane, ale wyodrębnienie. NET z tego powodu Możliwość prawdopodobnie nie jest dobrym pomysłem, ponieważ jest to możliwe również w innych językach. Powiedziałbym nawet, że w C/C++ łatwiej jest namieszać niż w. NET (szczególnie w C gdzie nie ma RAII) , ale wiele krytycznych aplikacji jest napisanych w C/C++ prawda? Więc to naprawdę zależy od indywidualnych okoliczności. Jeśli chcesz wydobyć ze swojej aplikacji każdą uncję prędkości i chcesz zbliżyć się do gołego metalu, to.net może nie być najlepszym rozwiązaniem. Jeśli jesteś przy napiętym budżecie i wykonując wiele połączeń z usługami sieciowymi/istniejącymi bibliotekami. NET/etc,. NET może być dobrym wyborem.}

W tej chwili większość mojej odpowiedzi została poprawiona przez komentarze poniżej. Nie będę usuwał odpowiedzi , ponieważ potrzebuję punktów reputacji , ponieważ informacje w komentarzach mogą być cenne dla czytelników.

Immortal Blue zwrócił uwagę, że w. NET 2.0 i nowszych finally bloki są odporne na przerywanie wątków. Jak skomentował Andreas Niedermair, może to nie być prawdziwy wątek zombie, ale poniższy przykład pokazuje, jak przerwanie wątku może spowodować problemy:

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");
    }
}

Jednak przy użyciu bloku lock() { }, finally nadal będzie wykonywany, gdy ThreadAbortException zostanie wywołany w ten sposób.

Jeśli wewnątrz bloku lock() { } pojawi się inny wyjątek, a ThreadAbortException pojawi się dokładnie wtedy, gdy blok finally ma być uruchomiony, blokada nie zostanie zwolniona. Jak wspomniałeś, blok lock() { } jest skompilowany jako:

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

Jeśli inny wątek wywoła Thread.Abort() wewnątrz wygenerowanego bloku finally, blokada może nie zostać zwolniona.

Tu nie chodzi o wątki Zombie, ale książka Effective C# ma sekcję dotyczącą implementacji IDisposable, (poz. 17), która mówi o obiektach Zombie, które moim zdaniem mogą Cię zainteresować.

Zalecam przeczytanie samej książki, ale jej sednem jest to, że jeśli masz klasę implementującą IDisposable lub zawierającą Descructor, jedyną rzeczą, którą powinieneś robić w obu przypadkach, jest zwolnienie zasobów. Jeśli robisz tu inne rzeczy, istnieje szansa, że obiekt nie będzie być zbierane śmieci, ale również nie będą dostępne w żaden sposób.

Daje przykład podobny do poniższego:

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

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

Kiedy Destruktor na tym obiekcie jest wywoływany, odniesienie do niego jest umieszczane na liście globalnej, co oznacza, że pozostaje żywe i w pamięci przez całe życie programu, ale nie jest dostępne. Może to oznaczać, że zasoby (szczególnie zasoby niezarządzane) mogą nie być w pełni uwolnione, co może powodować różnego rodzaju potencjalne problemy.

Pełniejszym przykładem jest poniżej. Do czasu osiągnięcia pętli foreach, na liście nieumarłych znajduje się 150 obiektów, z których każdy zawiera obraz, ale obraz został GC ' D i otrzymasz wyjątek, jeśli spróbujesz go użyć. W tym przykładzie otrzymuję ArgumentException (parametr jest nieprawidłowy), gdy próbuję zrobić cokolwiek z obrazem, czy próbuję go zapisać, czy nawet wyświetlić wymiary takie jak wysokość i szerokość:

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);
    }
}

Ponownie, wiem, że pytałeś o wątki zombie w szczególności, ale tytuł pytania jest o zombie w. Net, i przypomniało mi się o tym i pomyślałem, że inni mogą uznać to za interesujące!

W krytycznych systemach pod dużym obciążeniem pisanie kodu bez blokady jest lepsze przede wszystkim ze względu na poprawę wydajności. Spójrz na rzeczy takie jak LMAX i jak wykorzystuje "mechaniczną sympatię" do wielkich dyskusji na ten temat. Martwisz się jednak o wątki zombie? Myślę, że to przypadek edge ' a, który jest tylko błędem do usunięcia, a nie wystarczająco dobrym powodem, aby nie używać lock.

Brzmi bardziej, jakby twój przyjaciel był po prostu fantazyjny i obnosił się ze swoją wiedzą o niejasnych egzotycznych terminologia dla mnie! Przez cały czas, gdy prowadziłem laboratoria wydajności w Microsoft Polska, nigdy nie natknąłem się na przypadek tego problemu w .NET.

1.Is jest jaśniejsza definicja "wątku zombie" niż to, co wyjaśniłem tutaj?

Zgadzam się, że" wątki Zombie " Istnieją, jest to termin odnoszący się do tego, co dzieje się z wątkami, które pozostały z zasobami, których nie puszczają, a jednak nie umierają całkowicie, stąd nazwa "zombie", więc twoje wyjaśnienie tego skierowania jest całkiem dobre na pieniądze!

2.Czy wątki zombie mogą występować na. Net? (Dlaczego/dlaczego nie?)

Dzieje się często to inna historia i zależy od twoich technik kodowania i praktyk, jeśli chodzi o Ciebie, że jak blokowanie wątków i zrobiłeś to przez jakiś czas, nie martwiłbym się nawet o ten scenariusz, który przydarzy się Tobie.

I tak, jak @ KevinPanko słusznie wspomniał w komentarzach, "wątki Zombie" pochodzą z Uniksa, dlatego są używane w XCode-objective i określany jako "NSZombie" i używany do debugowania. Zachowuje się prawie tak samo... jedyną różnicą jest to, że obiekt, który powinien umrzeć, staje się" ZombieObject "do debugowania zamiast" wątku Zombie", który może być potencjalnym problemem w Twoim kodzie.

Mogę łatwo tworzyć wątki zombie.

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

To przecieka uchwyty wątku (dla Join()). To kolejny wyciek pamięci, jeśli chodzi o zarządzany świat.