Discussion :

[roukine]

Quand on éxécute Java en ligne de commande, il est possible (sous windows, en tous cas) de connaître la liste de tous threads en vie dans la VM à chaqueinstant grâce au cheat code ctrl+alt+pause.

Chaque thread est dumpé dans la console avec sa stack trace courante, d'une part, mais aussi la liste des locks. C'est très pratique pour partir à la chasse aux dead locks.

Connaissez-vous un moyen (plugin ?) sous Eclipse pour obtenir les mêmes infos ? En perspective "debug" il est possible de faire une pause suspendre l'exécution d'une VM et d'inspecter la pile de chaque thread... mais c'est un peu fastidieux de retrouver les différents locks.

[menuge]

le mode debug ne te suffit pas? Il y a pas mal d'info sur les threads et la stack trace

[roukine]

Bon, un exemple.

Le deadlock:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
package test;
 
public class LockTest {
    private static Object lock1 = new Object();
    private static Object lock2 = new Object();
    private static boolean b1 = false;
    private static boolean b2 = false;
 
    public static void main(String[] args) {
        new T1().start();
        new T2().start();
    }
 
    private static class T1 extends Thread {
        public void run() {
            synchronized (lock1) {
                b1 = true;
                while(!b2);
                synchronized (lock2) {
                    System.out.println("T1");
                }
            }
        }
    }
 
    private static class T2 extends Thread {
        public void run() {
            synchronized (lock2) {
                b2 = true;
                while(!b1);
                synchronized (lock1) {
                    System.out.println("T2");
                }
            }            
        }        
    }
}

Dans cet exemple, les deux threads créés sont en attente mutuelle l'un de l'autre. C'est le drame. Autrement dit, le deadlock.

Quand je lance la JVM en ligne de commande et que je fais CTRL+MAJ+PAUSE, j'obtiens tout plein d'infos qui me permettent de découvrir immédiatement la raison du blocage:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
 
Full thread dump Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode, sharing):
 
"DestroyJavaVM" prio=5 tid=0x00037d10 nid=0xd30 waiting on condition [0x00000000..0x0007fae8]
 
"Thread-1" prio=5 tid=0x00aa0de8 nid=0x5e0 waiting for monitor entry [0x02ccf000..0x02ccfd68]
        at test.LockTest$T2.run(LockTest.java:34)
        - waiting to lock <0x22a9da48> (a java.lang.Object)
        - locked <0x22a9da50> (a java.lang.Object)
 
"Thread-0" prio=5 tid=0x00a9b320 nid=0xbd0 waiting for monitor entry [0x02c8f000..0x02c8f9e8]
        at test.LockTest$T1.run(LockTest.java:21)
        - waiting to lock <0x22a9da50> (a java.lang.Object)
        - locked <0x22a9da48> (a java.lang.Object)
 
"Low Memory Detector" daemon prio=5 tid=0x00a6ff78 nid=0x508 runnable [0x00000000..0x00000000]
 
"CompilerThread0" daemon prio=10 tid=0x00a6ebe0 nid=0x504 waiting on condition [0x00000000..0x02bcf84c]
 
"Signal Dispatcher" daemon prio=10 tid=0x00a6de70 nid=0xa18 waiting on condition [0x00000000..0x00000000]
 
"Finalizer" daemon prio=9 tid=0x0003f980 nid=0x578 in Object.wait() [0x02b4f000..0x02b4fc68]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22a70840> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
        - locked <0x22a70840> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
 
"Reference Handler" daemon prio=10 tid=0x00a48aa0 nid=0xf94 in Object.wait() [0x02b0f000..0x02b0fce8]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22a70750> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:474)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
        - locked <0x22a70750> (a java.lang.ref.Reference$Lock)
 
"VM Thread" prio=10 tid=0x00a68428 nid=0xb14 runnable
 
"VM Periodic Task Thread" prio=10 tid=0x00a6ddb0 nid=0xc44 waiting on condition
 
 
Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x00a690ac (object 0x22a9da48, a java.lang.Object),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x00a690cc (object 0x22a9da50, a java.lang.Object),
  which is held by "Thread-1"
 
Java stack information for the threads listed above:
===================================================
"Thread-1":
        at test.LockTest$T2.run(LockTest.java:34)
        - waiting to lock <0x22a9da48> (a java.lang.Object)
        - locked <0x22a9da50> (a java.lang.Object)
"Thread-0":
        at test.LockTest$T1.run(LockTest.java:21)
        - waiting to lock <0x22a9da50> (a java.lang.Object)
        - locked <0x22a9da48> (a java.lang.Object)
 
Found 1 deadlock.

Quand je lance mon test dans eclipse, par défaut, je n'ai pas toutes ces infos :