Busy loop in other thread delays EDT processing

Question

I have a Java program which executes a tight loop on a separate (non-EDT) thread. Although I would think the Swing UI should still be responsive, it is not. The example program below exhibits the problem: clicking the "Try me" button should pop up a dialog more-or-less half a second later, and it should be possible to close that dialog immediately by clicking any of its responses. Instead, the dialog takes much longer to appear, and/or takes a long time to close after clicking one of the buttons.

• Problem occurs on Linux (two different machines with different distributions), on Windows, on the Raspberry Pi (server VM only) and on Mac OS X (reported by another SO user).
• Java version 1.8.0_65 and 1.8.0_72 (tried both)
• i7 processor with many cores. The EDT should have plenty of spare processing power available.

Does anyone have any idea why the EDT processing is being delayed, even though there is only a single busy thread?

(Please note that despite various suggestions of the Thread.sleep call being the cause of the problem, it is not. It can be removed and the problem can still be reproduced, though it manifests slightly less frequently and usually exhibits the second behavior described above - i.e. non-responsive JOptionPane dialog rather than delayed dialog appearance. Furthermore, there is no reason that the sleep call should yield to the other thread because there are spare processor cores as mentioned above; the EDT could continue to run on another core after the call to sleep).

import java.awt.EventQueue;

import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JOptionPane;

public class MFrame extends JFrame
{
    public static void main(String[] args)
    {
        EventQueue.invokeLater(() -> {
            new MFrame();
        });
    }

    public MFrame()
    {
        JButton tryme = new JButton("Try me!");

        tryme.addActionListener((e) -> {
            Thread t = new Thread(() -> {
                int a = 4;
                for (int i = 0; i < 100000; i++) {
                    for (int j = 0; j < 100000; j++) {
                        a *= (i + j);
                        a += 7;
                    }
                }
                System.out.println("a = " + a);
            });

            t.start();

            // Sleep to give the other thread a chance to get going.
            // (Included because it provokes the problem more reliably,
            // but not necessary; issue still occurs without sleep call).
            try {
                Thread.sleep(500);
            }
            catch (InterruptedException ie) {
                ie.printStackTrace();
            }

            // Now display a dialog
            JOptionPane.showConfirmDialog(null, "You should see this immediately");
        });

        getContentPane().add(tryme);

        pack();
        setVisible(true);
    }
}

Update: The problem occurs only with the server VM (but see further update). Specifying the client VM (-client command line argument to java executable) seems to suppress the problem (update 2) on one machine but not another.

Update 3: I see 200% processor usage by the Java process after clicking the button, implying that there are 2 processor cores fully loaded. This doesn't make sense to me at all.

Update 4: Also occurs on Windows.

Update 5: Using a debugger (Eclipse) proves problematic; the debugger seems unable to stop the threads. This is highly unusual, and I suspect there is some sort of livelock or race condition in the VM, so I've filed a bug with Oracle (review ID JI-9029194).

Update 6: I found my bug report in the OpenJDK bug database. (I was not informed that it had been accepted, I had to search for it). The discussion there is most interesting and already sheds some light on what may be the cause of this problem.

Answer 1

I see the same effect to Mac OS X. Although your example is correctly synchronized, the platform/JVM variability you see is likely due to vagaries in how threads are scheduled, resulting is starvation. Adding Thread.yield() to the outer loop in t mitigates the problem, as shown below. Except for the artificial nature of the example, a hint like Thread.yield() would not ordinarily be required. In any case, consider SwingWorker, shown here executing a similarly tight loop for demonstration purposes.

I do not believe that Thread.yield() should need to be called in this case at all, despite the artificial nature of the test case, however.

Correct; yielding simply exposes the underlying problem: t starves the event dispatch thread. Note that the GUI updates promptly in the example below, even without Thread.yield(). As discussed in this related Q&A, you can try lowering the thread's priority. Alternatively, run t in a separate JVM, as suggested here using ProcessBuilder, which can also run in the background of a SwingWorker, as shown here.

but why?

All supported platforms are built on single-threaded graphics libraries. It's fairly easy to block, starve or saturate the governing event dispatch thread. Non-trivial background tasks typically yield implicitly, as when publishing intermediate results, blocking for I/O or waiting on a work queue. A task that does not do may have to yield explicitly.

import java.awt.EventQueue;
import javax.swing.JButton;
import javax.swing.JFrame;

public class MFrame extends JFrame {

    private static final int N = 100_000;
    private static final String TRY_ME = "Try me!";
    private static final String WORKING = "Working…";

    public static void main(String[] args) {
        EventQueue.invokeLater(new MFrame()::display);
    }

    private void display() {
        JButton tryme = new JButton(TRY_ME);
        tryme.addActionListener((e) -> {
            Thread t = new Thread(() -> {
                int a = 4;
                for (int i = 0; i < N; i++) {
                    for (int j = 0; j < N; j++) {
                        a *= (i + j);
                        a += 7;
                    }
                    Thread.yield();
                }
                EventQueue.invokeLater(() -> {
                    tryme.setText(TRY_ME);
                    tryme.setEnabled(true);
                });
                System.out.println("a = " + a);
            });
            t.start();
            tryme.setEnabled(false);
            tryme.setText(WORKING);
        });
        add(tryme);
        pack();
        setLocationRelativeTo(null);
        setDefaultCloseOperation(EXIT_ON_CLOSE);
        setVisible(true);
    }
}

Answer 2

My observations:

• Replace thread with swingworker:

  • No difference

• Replace thread with swingworker and do some work inside the first for loop:

  • Got the expected results of the ui not freezing and the it was just smooth sailing from here on

With this code, the expected behaviour is observed:

public class MFrame extends JFrame {
    public static void main(String[] args) {
        new MFrame();
    }

    public MFrame() {
        JButton tryme = new JButton("Try me!");

        tryme.addActionListener((e) -> {
            SwingWorker<Void, Void> longProcess = new SwingWorker<Void, Void>() {
                private StringBuilder sb = new StringBuilder();

                @Override
                protected Void doInBackground() throws Exception {
                    int a = 4;
                    for (int i = 0; i < 100000; i++) {
                        for (int j = 0; j < 100000; j++) {
                            a *= (i + j);
                            a += 7;
                        }
                        sb.append(a); // <-- this seems to be the key
                    }
                    System.out.println("a = " + a);
                    return null;
                }

                @Override
                protected void done() {
                    try {
                        get();
                        System.out.println(sb.toString());
                    } catch (InterruptedException | ExecutionException e1) {
                        e1.printStackTrace();
                    }
                }
            };

            longProcess.execute();

            // Sleep to give the other thread a chance to get going.
            // (Included because it provokes the problem more reliably,
            // but not necessary; issue still occurs without sleep call).
            try {
                Thread.sleep(500);
            }
            catch (InterruptedException ie) {
                ie.printStackTrace();
            }

            // Now display a dialog
            SwingUtilities.invokeLater(() -> JOptionPane.showConfirmDialog(this, "You should see this immediately"));
        });

        getContentPane().add(tryme);
        pack();
        setLocationRelativeTo(null);
        setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
        setVisible(true);
    }
}

The same observation is made by using OP's original code:

• Do some other work inside the first for loop
  • Got expected results

Example

tryme.addActionListener((e) -> {

    Thread t = new Thread(() -> {
        StringBuilder sb = new StringBuilder();

        int a = 4;
        for (int i = 0; i < 100000; i++) {
            for (int j = 0; j < 100000; j++) {
                a *= (i + j);
                a += 7;
            }
            sb.append(a); // <-- again the magic seems to be on this line
        }
        System.out.println(sb.toString());
    });
    ...
});

I am running Ubuntu 14.04 on a semi powerful machine.

java version "1.8.0_72"
Java(TM) SE Runtime Environment (build 1.8.0_72-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.72-b15, mixed mode)

What do my observations mean?

Not much other than all is not lost and someone might have optimized the compiler a bit too much which makes it somehow block the UI thread. Honestly I'm not sure what it all means but I'm sure someone will figure it out

Answer 3

• by default everything started from EDT (in this case inside the ActionListener) locked by Thread.sleep ended when all code is executed including Thread.sleep, with assumtion that you are lost all events incl. painting, during whole time cunsumed this code, all events are painted at the end and in one time

• this code lost autoclose JOptionPane, never is painted to the screen (simulation of how to confortly Thread.sleep kills painting in Swing)

• Swing GUI is unresponsible to mouse or key event, isn't possible to terminating this aplication, this is possible just from Runnable#Thread and SwingWorker, thats are designated to start new, another thread (Workers Thread), during anything inside Runnable#Thread and SwingWorker is task cancelable (or by using Runnable#Thread is there possible to pause, modify...)

• this isn't about multithreading, nor about to share resourcer to another core(s), in Win10 all cores showing me, sharing the increment proportionally

output from (little bit modified) code (based on your SSCCE / MCVE)

run:
test started at - 16:41:13
Thread started at - 16:41:15
to test EDT before JOptionPane - true at 16:41:16
before JOptionPane at - 16:41:16
Thread ended at - 16:41:29
a = 1838603747
isEventDispatchThread()false
after JOptionPane at - 16:41:29
Thread started at - 16:41:34
to test EDT before JOptionPane - true at 16:41:34
before JOptionPane at - 16:41:34
Thread ended at - 16:41:47
a = 1838603747
isEventDispatchThread()false
after JOptionPane at - 16:41:47
BUILD SUCCESSFUL (total time: 38 seconds)

again autoclose JOptionPane never will be painted to the screen (tested win10-64b, i7, Java8), probably up to Java 1.6.022 everything will be painted and correctly (AFAIK the last fix to edt and from this time SwingWorker works without bugs)

import java.awt.Component;
import java.awt.EventQueue;
import java.awt.Window;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.text.SimpleDateFormat;
import java.util.Date;
import javax.swing.AbstractAction;
import javax.swing.Action;

import javax.swing.JButton;
import javax.swing.JDialog;
import javax.swing.JFrame;
import javax.swing.JOptionPane;
import javax.swing.SwingUtilities;
import javax.swing.Timer;

public class MFrame extends JFrame {

    public static void main(String[] args) {
        EventQueue.invokeLater(() -> {
            new MFrame();
        });
    }

    public MFrame() {
        SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss");
        System.out.println("test started at - " + sdf.format(getCurrDate().getTime()));
        //http://stackoverflow.com/a/18107432/714968
        Action showOptionPane = new AbstractAction("show me pane!") {
            private static final long serialVersionUID = 1L;

            @Override
            public void actionPerformed(ActionEvent e) {
                createCloseTimer(3).start();
                System.out.println("before JOptionPane at - "
                        + sdf.format(getCurrDate().getTime()));
                JOptionPane.showMessageDialog((Component) e.getSource(), "nothing to do!");
            }

            private Timer createCloseTimer(int seconds) {
                ActionListener close = new ActionListener() {

                    @Override
                    public void actionPerformed(ActionEvent e) {
                        Window[] windows = Window.getWindows();
                        for (Window window : windows) {
                            if (window instanceof JDialog) {
                                JDialog dialog = (JDialog) window;
                                if (dialog.getContentPane().getComponentCount() == 1
                                        && dialog.getContentPane().getComponent(0) instanceof JOptionPane) {
                                    dialog.dispose();
                                    System.out.println("after JOptionPane at - "
                                            + sdf.format(getCurrDate().getTime()));
                                }
                            }
                        }
                    }
                };
                Timer t = new Timer(seconds * 1000, close);
                t.setRepeats(false);
                return t;
            }
        };
        JButton tryme = new JButton("Try me!");
        tryme.addActionListener((e) -> {
            System.out.println("Thread started at - "
                    + sdf.format(getCurrDate().getTime()));
            Thread t = new Thread(() -> {
                int a = 4;
                for (int i = 0; i < 100000; i++) {
                    for (int j = 0; j < 100000; j++) {
                        a *= (i + j);
                        a += 7;
                    }
                }
                System.out.println("Thread ended at - "
                        + sdf.format(getCurrDate().getTime()));
                System.out.println("a = " + a);
                System.out.println("isEventDispatchThread()" + 
                        SwingUtilities.isEventDispatchThread());
            });
            t.start();
            // Sleep to give the other thread a chance to get going:
            try {
                Thread.sleep(500);
            } catch (InterruptedException ie) {
                ie.printStackTrace();
            }
            // Now display a dialog
            System.out.println("to test EDT before JOptionPane - "
                    + SwingUtilities.isEventDispatchThread()
                    + " at " + sdf.format(getCurrDate().getTime()));
            showOptionPane.actionPerformed(e);
        });
        setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        add(tryme);
        pack();
        setLocation(150, 150);
        setVisible(true);
    }

    private Date getCurrDate() {
        java.util.Date date = new java.util.Date();
        return date;
    }
}

note have to test with Runnable#Thread and SwingWorker too

Answer 4

This is not a final answer, but it gets closer to understanding the problem.

I tried to minimize the code to remove potential pitfalls with sleep and actionPerformed and I believe I have done so while keeping the problem intact:

public class MFrame extends JFrame {

    public static void main(String[] args) {

        EventQueue.invokeLater(() -> new MFrame());
    }

    public MFrame() {

        Thread t = new Thread(() -> {
            int a = 4;
            for (int i = 0; i < 50000; i++) {
                for (int j = 0; j < 50000; j++) {
                    a *= (i + j);
                    a += 7;
                }
            }
//          System.out.println("c" + a);
        });

        System.out.println("a");
//      pack();
        t.start();
//      pack();
        System.out.println("b");
    }
}

On Win7, i7 2670QM, JDK 1.8.0_25 I get the following results:

Only 2nd pack commented out:

a
b [pause]
c-1863004573

(expected since even without synchronization, printing b would be reached before printing c, unless maybe you are on some superduper processor that could do the calculation faster?)

Only 1st pack commented out:

a [pause]
c-1863004573
b

(not expected)

Can you confirm my results with/out the -client flag?

Answer 5

This seems to be an issue. Below are the observation Event Dispatcher Thread delays the processing, Should have responded immediately:

1. Execute sample program
2. Click "Try me" button
3. Click any button (yes/no/cancel) to close the resulting dialog

On Windows

Long delay observe between step 2 and step 3.

Step 3 -> closes the dialog immediately.

On Linux

Step 2 to step 3 - no delay.

Step 3 -> long delay to close the dialog .