Utilisez l'outil jstack du JDK pour découvrir la cause du blocage du programme d'exécution

Le contenu de cet article concerne l'utilisation de l'outil JDK jstack pour découvrir la cause du blocage du programme d'exécution. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

La programmation multithread Java est également un contenu fréquemment examiné dans les entretiens Java. Les amis qui débutent dans la programmation multithread Java peuvent accidentellement écrire certaines applications susceptibles de provoquer des blocages. Comment analyser les causes du multi-threading Java ? Souvent, nous définissons des points d'arrêt et un débogage en une seule étape sur des instructions suspectées de provoquer un blocage, mais elles ne peuvent pas être reproduites. Ce phénomène est normal, car le timing d'exécution du code est différent entre le débogage en une seule étape et l'exécution directe du programme, et les conditions de déclenchement d'un blocage peuvent ne pas être remplies.

En fait, JDK a fourni aux programmeurs Java de puissants outils d'analyse des blocages qui peuvent analyser directement une application d'état en cours d'exécution et bloquée, et donner la ligne spécifique du code Java qui a provoqué le blocage.

Cet article utilise un exemple pour montrer comment utiliser les outils standards fournis par le JDK.

Cet outil s'appelle jstack, qui est un fichier exécutable dans le dossier bin du répertoire d'installation du JDK.

Nous écrivons d'abord une application qui provoquera un blocage.

public class DeadLockExample {
    public static void main(String[] args) {
        final String resource1 = "ABAP";
        final String resource2 = "Java";
        Thread t1 = new Thread() {
            public void run() {
                synchronized (resource1) {
                    System.out.println("Thread 1: locked resource 1");
                    try {
                        Thread.sleep(100);
                    }
                    catch (Exception e) {
                    }
                    synchronized (resource2) {
                        System.out.println("Thread 1: locked resource 2");
                    }
                }
            }
        }
        ;
        Thread t2 = new Thread() {
            public void run() {
                synchronized (resource2) {
                    System.out.println("Thread 2: locked resource 2");
                    try {
                        Thread.sleep(100);
                    }
                    catch (Exception e) {
                    }
                    synchronized (resource1) {
                        System.out.println("Thread 2: locked resource 1");
                    }
                }
            }
        }
        ;
        t1.start();
        t2.start();
    }
}

L'idée de l'application est très simple. Démarrez deux threads en même temps, verrouillez respectivement la ressource1 et la ressource2, puis dormez pendant 0,1 seconde, puis essayez de demander les ressources ressource2 et ressource1 respectivement.

Exécutez l'application et entrez dans l'état de blocage après avoir imprimé le résultat suivant sur la console :

Thread 1 : ressource verrouillée 1

Thread 2 : ressource verrouillée 2

Utilisez la ligne de commande jps -l -m pour trouver l'ID de processus de l'application en état de blocage. D'après la figure ci-dessous, nous savons que le processus de blocage est 51476 :

Utilisez ensuite la ligne de commande jstack 51476 pour imprimer les informations de la pile en cours d'exécution de ce processus.

Les 0x00000000d6f64988 et 0x00000000d6f649b8 surlignés en rouge dans l'image ci-dessus représentent les deux ressources "ABAP" et "Java" dans le code.

Le résultat imprimé par jstack est très clair, montrant quelle ligne de code Java a essayé de verrouiller quelle ressource Java (en attendant de verrouiller dans l'image ci-dessous) mais a échoué, et la raison de l'échec était qu'elle possédait le ressource actuellement demandée. Le nom du fil est également imprimé.

Avec jstack, les programmeurs Java n'ont plus à réfléchir sérieusement au code multithread long et brûlant, JDK imprimera automatiquement la cause de l'impasse C'est tellement pratique de sortir.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!