Home of The JavaSpecialists' Newsletter

101Causing Deadlocks in Swing Code

Posted: 2005-01-18Category: GUIJava Version: 1.5+Dr. Heinz M. Kabutz



Welcome to the 101st edition of The Java(tm) Specialists' Newsletter, now sent to 107 countries. That is right, we had 5 new countries since the last edition: Four from Africa: Eritrea, Malawi, Zambia and Senegal, and one from Europe: The Former Yugoslav Republic of Macedonia. A special welcome to you :)

The worst time of year to be working in Cape Town is between Christmas and New Year. Our city grows by a few hundred thousand people, as the "Vaalies" (South Africans who live across the Vaal river, such as in Johannesburg) descend on Cape Town, together with lots of German and English tourists. All work stops, and if you are the odd-one-out who is trying to get something done, that week is the most depressing of the whole year. Since 1997, I got suckered EVERY year to work during that week, but this last December, I refused. The result? When I arrived in Germany last week, I was told that I looked 2 years younger :)

Dr Heinz's Extreme Java Courses: We offer our courses as In-house and Self-Study options. In-house is best for large teams of Java experts. Self-study is suitable for individual programmers w ho want to advance their careers. If you have any questions, please simply send me an email or fill in our enquiry form :-)

Causing Deadlocks in Swing Code

My first newsletter was about thread deadlocks that can occur in many places of Java, including the GUI. I then presented some code that automatically detected thread deadlocks in Issue 93.

It is easy to demonstrate deadlocks, but up till now, I did not have an example where incorrect coding in the Swing classes caused a deadlock. I had seen it "in the field", several times, but I did not have a one-page sample that demonstrated it. Many thanks to Dan Breen from USA who sent me this code sample :)

In this code, several factors come together. I am constructing the frame from within the static initializer block. Then, when I add the new MyJDesktopPane to the content pane, and set it to visible, it starts the Swing thread. However, I then construct a new JInternalFrame (with the main thread!) and at the same time, the Swing thread tries to call paintComponent() of MyJDesktopPane, which then hangs up when calling the staticMethod().

import javax.swing.*;
import java.awt.*;

public class StrangeProblem extends JFrame {
  static {
    new StrangeProblem();

  private static void staticMethod() {
    System.out.println("This is never reached");

  private StrangeProblem() {
    getContentPane().add(new MyJDesktopPane());
    setSize(300, 300);
    // If commented out, program works fine, otherwise it hangs
    new JInternalFrame();

  private class MyJDesktopPane extends JDesktopPane {
    protected void paintComponent(Graphics g) {
      System.out.println("We will now call the static method...");
      System.out.println("Static method was called.");

  public static void main(String[] args) {

You run this code by compiling it and typing java StrangeProblem. This will load the class (before calling main) which will call the static initializer block. You will notice that the line "This is never reached" is never seen, and neither is the line "Static method was called." When you dump the threads, you see:

We will now call the static method...
Full thread dump Java HotSpot(TM) Client VM (1.5.0_01-b08 mixed mode, sharing):

"AWT-EventQueue-0" prio=7 tid=0x009f87c0 nid=0x524 in Object.wait() [0x02f4f000..0x02f4fc64]
        at StrangeProblem$MyJDesktopPane.paintComponent(StrangeProblem.java:26)
        - locked <0x22b37728> (a java.awt.Component$AWTTreeLock)

"main" prio=5 tid=0x00236040 nid=0xc2c waiting for monitor entry [0x0006f000..0x0006fc38]
        at java.awt.Component.setFont(Unknown Source)
        - waiting to lock <0x22b37728> (a java.awt.Component$AWTTreeLock)
        at javax.swing.JInternalFrame.<init>(Unknown Source)
        at StrangeProblem.<init>(StrangeProblem.java:19)
        at StrangeProblem.<clinit>(StrangeProblem.java:6)

What I found amazing is that this code always causes a deadlock (or is that a livelock?) on Sun's VM's going right back to version 1.2.2_014.

Fixing the code is easy, and almost anything that we change will make the problem go away. For example, we could only call setVisible(true) after we finish adding components. Then, we could construct the object from within main() rather than the static initializer block.

However, the best change is to obey the Swing single-thread rule, which tells us to only ever call GUI code from within the Swing thread. In our case, we need to change the static initializer block to:

  static {
    SwingUtilities.invokeLater(new Runnable() {
      public void run() {
        new StrangeProblemFixed();

The lesson learnt is, when writing any GUI code, make sure that only the Swing event thread is changing or reading the GUI. This applies even to code that constructs a frame from within the main() function.

I have a newsletter written by Aleksey Gureev, which I will probably send in my next issue, which offers another excellent approach to automatically detecting thread deadlocks in the GUI.

Kind regards



Related Articles

Browse the Newsletter Archive

About the Author


Java Champion, author of the Javaspecialists Newsletter, conference speaking regular... About Heinz

Java Training

We deliver relevant courses, by top Java developers to produce more resourceful and efficient programmers within their organisations.

Java Consulting

Nobody ever wants to call a Java performance consultant, but with first-hand experience repairing and improving commercial Java applications - JavaSpecialists are a good place to start...

Threading Emergency?

If your system is down, we will review it for 15 minutes and give you our findings for just 1 € without any obligation.