Occasional InterruptedException when quitting a Swing application

Question

I recently updated my computer to a more powerful one, with a quad-core hyperthreading processor (i7), thus plenty of real concurrency available. Now I\'m occasionally

Answer 1

If you are using swing application then first call System.gc() and then call dispose() method. I think it will work fine.. I also use this.

Answer 2

Try this. This worked for me. I was creating JFileChooser instance which was not disposed properly after System.exit(0) call.

setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
addWindowListener(new WindowAdapter() {
             public void windowClosing(WindowEvent ev) {                	
                dispose();
                System.exit(0);
                }
 });

Answer 3

I have the same issue ( Java 6 ). I noticed an unknwon sun.awt.image.ImageFetcher thread in the debugger. I think it comes from me using JButtons with Icons. The ImageFetcher thread disappears after 2 seconds. If the ImageFetcher thread is not running my programm exits just fine.

Answer 4

System.exit() probably isn't the cleanest way of closing down a Swing based app

Can't you set your main frame to EXIT_ON_CLOSE:

mainFrame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE )

Then set it to invisible?

Related Q here; System.exit(0) in java

Answer 5

I wonder if it is not related to this bug :

Java Bug 6489540

Basically it means that if Java2D is used when an InheritableThreadLocal object exists or a custom contextClassLoader is present they are captured and live forever causing memory leaks and possibly these kind of weird locks.

If this is the case a workaround would be to trigger a Java2D action on the main thread (i.e. immediately when the application starts) so the DisposerThread lives in a "squeky clean" environment. It is started by a static initializer so just a dummy load of a java2d resource and freeing it would be enough to get a DisposerThread which does not hang on to undesirable stuff.

Answer 6

Your Disposer is blocked in a call to remove() (removing the next platform native resource). This means that the disposer thread (a daemon thread) is not being shutdown naturally when the VM exits (which you should expect since you are terminating it via System.exit()).

You have a non-daemon thread in your application which is keeping the VM from exiting when all your swing windows have been disposed.

Solution: find it and cause it to exit.

Normally a swing application exits gracefully if all of its swing windows have been disposed of, for example, this program will pop a window then exit once it is closed (all with no call to System.exit()):

public static void main(String args[]) throws Exception {
    JFrame jf = new JFrame();
    jf.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
    jf.setVisible(true);
}

You might also try running the garbage collector before exiting, just for kicks.