Estaba teniendo una discusión con un compañero de equipo sobre bloquear en .NET. Es un tipo realmente brillante con una amplia experiencia tanto en programación de nivel inferior como de nivel superior, pero su experiencia con la programación de nivel inferior supera con creces la mía. De todos modos, argumentó que el bloqueo de .NET debe evitarse en los sistemas críticos que se espera que estén sometidos a una gran carga, si es posible, para evitar la pequeña posibilidad de que un "hilo zombie" estrelle un sistema. Usualmente uso el bloqueo y no sabía qué era un "hilo zombie", así que pregunté. La impresión que obtuve de su explicación es que un hilo zombie es un hilo que ha terminado pero que de alguna manera aún conserva algunos recursos. Un ejemplo que dio de cómo un hilo zombie podría romper un sistema fue que un hilo comienza un procedimiento después de bloquear un objeto, y luego termina en algún momento antes de que se pueda liberar el bloqueo. Esta situación tiene el potencial de bloquear el sistema, porque eventualmente, los intentos de ejecutar ese método darán como resultado que todos los hilos esperen el acceso a un objeto que nunca será devuelto, porque el hilo que está usando el objeto bloqueado está muerto.

Creo que entendí la esencia de esto, pero si estoy fuera de la base, por favor hágamelo saber. El concepto tenía sentido para mí. No estaba completamente convencido de que este fuera un escenario real que podría suceder en .NET. Nunca antes había oído hablar de "zombis", pero sí reconozco que los programadores que han trabajado en profundidad en los niveles inferiores tienden a tener una comprensión más profunda de los fundamentos de la informática (como el subprocesamiento). Sin embargo, definitivamente veo el valor en el bloqueo, y he visto a muchos programadores de clase mundial aprovechar el bloqueo. También tengo una capacidad limitada para evaluar esto por mí mismo porque sé que la lock(obj)declaración es realmente solo azúcar sintáctica para:

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

y porque Monitor.Entery Monitor.Exitestán marcados extern. Parece concebible que .NET realice algún tipo de procesamiento que proteja los hilos de la exposición a los componentes del sistema que podrían tener este tipo de impacto, pero eso es puramente especulativo y probablemente solo se base en el hecho de que nunca he oído hablar de "hilos de zombis" antes de. Entonces, espero poder obtener algunos comentarios sobre esto aquí:

1. ¿Existe una definición más clara de "hilo zombie" que la que he explicado aquí?
2. ¿Pueden aparecer hilos zombie en .NET? (¿Por qué por qué no?)
3. Si corresponde, ¿cómo podría forzar la creación de un hilo zombie en .NET?
4. Si corresponde, ¿cómo puedo aprovechar el bloqueo sin arriesgar un escenario de subproceso zombie en .NET?

Actualizar

Hice esta pregunta hace poco más de dos años. Hoy sucedió esto:

• ¿Existe una definición más clara de "hilo zombie" que la que he explicado aquí?

Parece una buena explicación para mí: un hilo que ha terminado (y por lo tanto ya no puede liberar ningún recurso), pero cuyos recursos (por ejemplo, identificadores) todavía están alrededor y (potencialmente) causan problemas.

• ¿Pueden aparecer hilos zombie en .NET? (¿Por qué por qué no?)
• Si corresponde, ¿cómo podría forzar la creación de un hilo zombie en .NET?

Seguro que sí, mira, ¡hice uno!

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

Este programa inicia un hilo Targetque abre un archivo y luego se mata inmediatamente usando ExitThread. El hilo zombie resultante nunca liberará el identificador del archivo "test.txt" y, por lo tanto, el archivo permanecerá abierto hasta que finalice el programa (puede consultar con el explorador de procesos o similar). El identificador de "test.txt" no se lanzará hasta que GC.Collectse llame; resulta que es aún más difícil de lo que pensé para crear un hilo zombie que filtra los identificadores)

• Si corresponde, ¿cómo puedo aprovechar el bloqueo sin arriesgar un escenario de subproceso zombie en .NET?

¡No hagas lo que acabo de hacer!

Siempre que su código se limpie correctamente después de sí mismo (use Safe Handles o clases equivalentes si trabaja con recursos no administrados), y siempre y cuando no salga de su camino para matar hilos de maneras extrañas y maravillosas (la forma más segura es solo para nunca matar subprocesos: deje que terminen normalmente, o mediante excepciones si es necesario), la única forma en que tendrá algo parecido a un hilo zombie es si algo ha salido muy mal (por ejemplo, algo sale mal en el CLR).

De hecho, es realmente sorprendente crear un hilo zombie (tuve que P / Invocar en una función que esencialmente te dice en la documentación que no lo llames fuera de C). Por ejemplo, el siguiente código (horrible) en realidad no crea un hilo zombie.

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

A pesar de cometer algunos errores bastante horribles, el identificador de "test.txt" todavía se cierra tan pronto como Abortse lo llama (como parte del finalizador para el filecual debajo de las cubiertas usa SafeFileHandle para ajustar su identificador de archivo)

El ejemplo de bloqueo en la respuesta de C.Evenhuis es probablemente la forma más fácil de no liberar un recurso (un bloqueo en este caso) cuando un subproceso se termina de una manera no extraña, pero eso se soluciona fácilmente mediante el uso de una lockdeclaración o poniendo el lanzamiento en un finallybloque.

Ver también

• Sutilezas de codegen C # IL para un caso muy sutil en el que una excepción puede evitar que se libere un bloqueo incluso cuando se usa la lockpalabra clave (pero solo en .Net 3.5 y versiones anteriores)
• Las cerraduras y las excepciones no se mezclan

Limpié un poco mi respuesta, pero dejé la original a continuación como referencia.

Es la primera vez que escucho sobre el término zombis, así que asumiré que su definición es:

Un hilo que ha terminado sin liberar todos sus recursos

Entonces, dada esa definición, entonces sí, puede hacerlo en .NET, como con otros lenguajes (C / C ++, java).

Sin embargo , no creo que esta sea una buena razón para no escribir código de misión crítica con hilos en .NET. Puede haber otras razones para decidir en contra de .NET, pero descartar .NET solo porque puede tener hilos zombie de alguna manera no tiene sentido para mí. Los hilos de Zombie son posibles en C / C ++ (incluso diría que es mucho más fácil desordenar en C) y muchas aplicaciones críticas y enhebradas están en C / C ++ (comercio de alto volumen, bases de datos, etc.).

Conclusión Si está en el proceso de decidir qué idioma utilizar, le sugiero que tenga en cuenta el panorama general: rendimiento, habilidades de equipo, programación, integración con aplicaciones existentes, etc. Seguro, los hilos zombies son algo en lo que debe pensar , pero dado que es muy difícil cometer este error en .NET en comparación con otros lenguajes como C, creo que esta preocupación se verá eclipsada por otras cosas como las mencionadas anteriormente. ¡Buena suerte!

Original Response Zombies ^† puede existir si no escribe el código de subproceso adecuado. Lo mismo es cierto para otros lenguajes como C / C ++ y Java. Pero esta no es una razón para no escribir código roscado en .NET.

Y al igual que con cualquier otro idioma, conozca el precio antes de usar algo. También ayuda saber qué sucede debajo del capó para poder prever cualquier problema potencial.

El código confiable para sistemas de misión crítica no es fácil de escribir, independientemente del idioma en el que se encuentre. Pero estoy seguro de que no es imposible hacerlo correctamente en .NET. También AFAIK, el enhebrado .NET no es tan diferente del enhebrado en C / C ++, usa (o está construido a partir de) las mismas llamadas del sistema, excepto algunas construcciones específicas de .net (como las versiones livianas de RWL y clases de eventos).

^{† La} _{primera vez que escuché hablar del término zombis, pero según tu descripción, tu colega probablemente significó un hilo que terminó sin liberar todos los recursos. Esto podría causar un punto muerto, pérdida de memoria o algún otro efecto secundario negativo. Obviamente, esto no es deseable, pero señalar .NET debido a esta posibilidad probablemente no sea una buena idea, ya que también es posible en otros lenguajes. Incluso diría que es más fácil equivocarse en C / C ++ que en .NET (especialmente en C donde no tiene RAII), pero muchas aplicaciones críticas están escritas en C / C ++, ¿verdad? Por lo tanto, realmente depende de sus circunstancias individuales. Si desea extraer cada onza de velocidad de su aplicación y desea acercarse lo más posible al metal desnudo, entonces .NET podríaNo sea la mejor solución. Si tiene un presupuesto ajustado e interactúa mucho con los servicios web / bibliotecas .net existentes / etc., entonces .NET puede ser una buena opción.}

En este momento, la mayor parte de mi respuesta ha sido corregida por los comentarios a continuación. No eliminaré la respuesta porque necesito los puntos de reputación porque la información en los comentarios puede ser valiosa para los lectores.

Immortal Blue señaló que en .NET 2.0 y los finallybloques superiores son inmunes a los abortos de subprocesos. Y como comentó Andreas Niedermair, este puede no ser un hilo zombie real, pero el siguiente ejemplo muestra cómo abortar un hilo puede causar problemas:

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

Sin embargo, cuando se usa un lock() { }bloque, finallyaún se ejecutará cuando a ThreadAbortExceptionse dispara de esa manera.

La siguiente información, como resultado, solo es válida para .NET 1 y .NET 1.1:

Si dentro del lock() { }bloque ocurre otra excepción, y ThreadAbortExceptionllega exactamente cuando el finallybloque está a punto de ejecutarse, el bloqueo no se libera. Como mencionó, el lock() { }bloque se compila como:

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

Si otro hilo llama Thread.Abort()dentro del finallybloque generado , es posible que no se libere el bloqueo.

No se trata de hilos de Zombie, pero el libro Effective C # tiene una sección sobre la implementación de IDisposable, (ítem 17), que habla sobre los objetos de Zombie que pensé que podrían encontrar interesantes.

Recomiendo leer el libro en sí, pero lo esencial es que si tienes una clase que implementa IDisposable o que contiene un Desctructor, lo único que debes hacer es liberar recursos. Si hace otras cosas aquí, entonces existe la posibilidad de que el objeto no se recolecte basura, pero tampoco será accesible de ninguna manera.

Da un ejemplo similar al siguiente:

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

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

Cuando se llama al destructor en este objeto, se coloca una referencia a sí mismo en la lista global, lo que significa que permanece vivo y en memoria durante la vida del programa, pero no es accesible. Esto puede significar que los recursos (particularmente los recursos no administrados) pueden no liberarse por completo, lo que puede causar todo tipo de problemas potenciales.

Un ejemplo más completo está debajo. Para cuando se alcanza el bucle foreach, tiene 150 objetos en la lista de No muertos, cada uno con una imagen, pero la imagen ha sido GC'd y obtiene una excepción si intenta usarla. En este ejemplo, obtengo una excepción ArgumentException (el parámetro no es válido) cuando intento hacer algo con la imagen, ya sea que trate de guardarla o incluso ver dimensiones como la altura y el ancho:

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

Una vez más, soy consciente de que estabas preguntando sobre hilos de zombies en particular, pero el título de la pregunta es sobre zombies en .net, ¡y me acordé de esto y pensé que otros podrían encontrarlo interesante!

En sistemas críticos bajo una gran carga, escribir código sin bloqueo es mejor principalmente debido a las mejoras de rendimiento. Mire cosas como LMAX y cómo aprovecha la "simpatía mecánica" para grandes discusiones sobre esto. Sin embargo, ¿te preocupan los hilos de zombis? Creo que es un caso límite que es solo un error que se debe solucionar, y no es una razón suficiente para no usarlo lock.

¡Parece que tu amigo solo es elegante y hace alarde de su conocimiento de una oscura y exótica terminología para mí! En todo el tiempo que estuve ejecutando los laboratorios de rendimiento en Microsoft UK, nunca encontré una instancia de este problema en .NET.

1. ¿Existe una definición más clara de "hilo zombie" que la que he explicado aquí?

Estoy de acuerdo en que existen "Zombie Threads", es un término para referirse a lo que sucede con los Threads que se quedan con recursos que no dejan ir y, sin embargo, no mueren por completo, de ahí el nombre de "zombie", por lo que su ¡La explicación de esta referencia es bastante acertada!

¿Pueden aparecer hilos de zombies en .NET? (¿Por qué por qué no?)

Sí, pueden ocurrir. Es una referencia, y en realidad Windows se refiere como "zombie": MSDN usa la palabra "Zombie" para procesos / hilos muertos

Suceder con frecuencia es otra historia, y depende de tus técnicas y prácticas de codificación, en cuanto a ti, que te gusta Thread Locking y lo has hecho por un tiempo, ni siquiera me preocuparía de que te ocurriera ese escenario.

Y sí, como @KevinPanko mencionó correctamente en los comentarios, "Zombie Threads" provienen de Unix, razón por la cual se usan en XCode-ObjectiveC y se conocen como "NSZombie" y se usan para la depuración. Se comporta más o menos de la misma manera ... la única diferencia es que un objeto que debería haber muerto se convierte en un "Objeto Zombie" para la depuración en lugar del "Hilo Zombie" que podría ser un problema potencial en su código.

Puedo hacer hilos de zombies con bastante facilidad.

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

Esto pierde las asas del hilo (para Join() ). Es solo otra pérdida de memoria en lo que a nosotros respecta en el mundo administrado.

Ahora bien, matar un hilo de una manera que realmente mantenga bloqueos es un dolor en la parte trasera, pero es posible. El otro tipo ExitThread()hace el trabajo. Como descubrió, el gc limpió el identificador del archivo, pero no lockalrededor de un objeto. ¿Pero por qué harías eso?