2009-12-04 15 views
8

Me gustaría eliminar los hilos que están atascados en el estado de interbloqueo. Primero, podemos detect thread ids in deadlock state usando el método findDeadlockedThreads() de la clase ThreadMXBean en java.lang.management.Cómo matar subprocesos bloqueados en Java?

Entonces, me gustaría eliminar los hilos por id. De subproceso, y así tengo dos preguntas relacionadas:
(1) ¿Cómo obtener el control de un subproceso por id de subproceso?
(2) ¿Cómo matar un hilo bloqueado? Creo que invocar el método de interrupción() dará una excepción al hilo y matará el hilo.

+3

Corregir el código para que los hilos no se estanquen en primer lugar debe ser lo que estás tratando de hacer. – Chris

+0

Al igual que Chris, creo que debes idear un plan para evitar estancamientos en primer lugar. – Alfred

+1

La única forma razonablemente segura de hacer lo que quieras es System.exit() ... y solo bromeo parcialmente. – PSpeed

Respuesta

3

Desde el grupo de subprocesos raíz, puede tener la clase de Subproceso enumerate all running threads. Luego puede llamar a Thread.stop en el que coincida con su ID.

Dicho esto, esto es muy peligroso debido a la posibilidad de dejar objetos en un estado incoherente. No creo que el método de interrupción haga que se libere un hilo que está atorado en espera en un bloqueo de sincronización, por lo que los métodos de detención (mal)

Véase también: "Java Thread Primitive Deprecation".

+3

La maldad de esto no se puede enfatizar lo suficiente. Es mejor escribir el código para evitar el punto muerto en primer lugar. – bmargulies

+0

Enumerar todos los hilos en ejecución es un artículo interesante, así que definitivamente lo usaré más adelante. Gracias. – Sangmin

+1

El enfoque Thread.stop() no parece funcionar en Java 1.5. Los subprocesos bloqueados permanecen en el estado BLOQUEADO. ¡Para mí, estoy intentando escribir una prueba unitaria para un detector de punto muerto y no puedo deshacerme de mis hilos intencionalmente en punto muerto! :-) –

6

El método java.util.concurrent.Lock.lockInterruptibly() es interrumpible, el bloqueo sincronizado mucho más común no lo es. Como se menciona en la documentación, la capacidad de enumerar subprocesos interbloqueos pretende ser una herramienta de depuración y no un medio de recuperación en un entorno de producción.

En producción, probablemente sea más seguro salir de todo el proceso y reiniciar.

+1

+1 para la frase final –

Cuestiones relacionadas