Core Java Books

Tuesday, 5 April 2011

Java GUI Application Shutdown Gotcha

In recent times I've had issues with one or two Java GUI application not shutting down when I close them. They seem to stay around as a process, consuming computer resources. Today I got to the bottom of the problem and it's a bit of a nasty gotcha which I wasn't aware of before so I thought I would share it.

In theory when you close a Java application all the threads should be stopped and the process should die. Im my case when I monitored the application the threads I expected to finish such as Swing worker pools were still alive, Strange. The reason turned out to be that the AWT Shutdown thread wasn't terminating all the helper threads, and the reason for this was that there were still AWT Events in the EventQueues. The reason for this is a real sneaky little gatcha, I will explain.

My application used a Thread which had a regular sleep but when woke up would so some calculation and then make a call to update the gui:

Thread updateThread = new Thread(new Runnable() {

  @Override
  public void run() {
    int i = 0;
    do {
      try {
        Thread.sleep(300); // 300ms
        gui.updateValue(SOME_VALUE);
      catch (InterruptException ex) {
        return;
      }
      frame.setValue(SOMEDATA);
    while (i++ < 100);
  }


}"updateThread");

updateThread.setDaemon(true);
updateThread.start();

Now you will notice that the thread returns if it is interrupted and also it is started as a Daemon thread. I had thought that as part of the application shutdown the thread would be terminated but NO it wasn't. This was caused by gui.updateValue(SOME_VALUE) making use of InvokeLater:



  public void updateValue(final int value) {

        // make sure we access graphics in the EDT thread
        java.awt.EventQueue.invokeLater(new Runnable() {

          @Override
            public void run() {
                try {
                     ...
                     ...
                     ...
                    SOME CODE
                catch (Exception t) {
                    // not a lot to do
                }
            }
        });
    }

The InvokeLater is basically putting an event on the EventQueue and because of this the AWT Shutdown thread want shutdown the application. The AWT Shutdown thread checks the EventQueues every seconds but as you will see my Thread does an update subsecond (300ms) so there is always an event on the Queue! So in short the AWT Shutdown thread never terminates the threads I want it to terminate and so the application needs to be killed.

The work around is simple in the while loop of my thread I also check that the JComonent that is to be updated via it is still visible and shown, if it is not the loop is exited, the thread dies and so there are no more events put on the Event thread and whooohooo the application closes as expected :)


Thread updateThread = new Thread(new Runnable() {

  @Override
  public void run() {
    int i = 0;
    do {
      try {
        Thread.sleep(300); // 300ms
        gui.updateValue(SOME_VALUE);
      catch (InterruptException ex) {
        return;
      }
      frame.setValue(SOMEDATA);
    }while (i < 100 && progressGlassPane.isVisible() && progressGlassPane.isShowing());
  }
}"updateThread");
updateThread.setDaemon(true);
updateThread.start();


So in short don't call InvokeLater from a helper thread at sub-second frequency unless you also terminate the thread if the component it is updating is no longer visible!
 
As a side note after I spotted the issue I found this very useful article on the same subject which highlighted the same issue I was having.

6 comments:

  1. I believe isVisible() and isShowing() should only be executed on the EDT.

    -Charlie

    ReplyDelete
  2. Yes good point Charlie. A better approach would probably to set a boolean value when the component is removed from display and use that in the thread.

    Well spotted!

    Steve

    ReplyDelete
  3. I am not swing guru, but make sure that jvm doesn't cache the result of progressGlassPane.isVisible() && progressGlassPane.isShowing()

    ReplyDelete
  4. No its Ok in that respect Slim. However as Charlie pointed out in the previous comment I shouldn't really be calling these methods outside the EDT (Swing) thread, in fact no swing methods should be called outside the EDT thread (ever). I should probably be updating a boolean flag/s to indicate the component status and using these in the other thread. Thanks for the comment though.

    ReplyDelete
  5. Hi Steve,

    Nice blog! Is there an email address I can contact you in private?

    ReplyDelete
  6. I come from Indonesia, .. happy to visit your blog, ... wait behind the visit. Thank you.


    By : developing mobile app indonesia | firzil.co.id

    ReplyDelete