101Causing Deadlocks in Swing Code

Author: Dr. Heinz M. KabutzDate: 2005-01-18Java Version: 1.2Category: GUI

Abstract: Swing uses several locks. When several threads work with the GUI at the same time, it is not always easy to determine the order of the locks. This can result in deadlocks, the famous "refresh bug".

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 :)

javaspecialists.teachable.com: Please visit our new self-study course catalog to see how you can upskill your Java knowledge.

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());
    setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    setSize(300, 300);
    setVisible(true);
    // If commented out, program works fine, otherwise it hangs
    new JInternalFrame();
  }

  private class MyJDesktopPane extends JDesktopPane {
    protected void paintComponent(Graphics g) {
      super.paintComponent(g);
      System.out.println("We will now call the static method...");
      staticMethod();
      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)
    *snip*
        - 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)
    *snip*
        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

Heinz

Comments

We are always happy to receive comments from our readers. Feel free to send me a comment via email or discuss the newsletter in our JavaSpecialists Slack Channel (Get an invite here)

Related Articles

Browse the Newsletter Archive