Swing pseudo-blocks upon launching a Thread OR a SwingWorker that does computation

I have a very simple application with a very strange behaviour.

It's essentially the SwingWorker example, but when I press the button the GUI behaves just like the EDT is being blocked. I can fire off two simultaneously and they run in parallel (have near identical run times) but still the menu freezes up while they're running. The exact same behaviour happens when I use a Thread with a runnable. Also interesting is that the GUI behaves properly if the loops are replaced by a Thread.sleep.

Any ideas?

public class DummyFrame extends JFrame {

        public DummyFrame() {
                JMenuBar bar = new JMenuBar();
                JMenu menu = new JMenu("File");
                menu.add(new JMenuItem("TEST1"));
                menu.add(new JMenuItem("Test2"));
                bar.add(menu);
                setJMenuBar(bar);

                JButton button = new JButton("FOOBAR");
                button.addActionListener(new开发者_Python百科 ActionListener() {
                        @Override
                        public void actionPerformed(ActionEvent arg0) {
                                final long start = System.currentTimeMillis();

                                SwingWorker<Void, Integer> testTask = new SwingWorker<Void, Integer>() {        
                                        @Override
                                        protected Void doInBackground()
                                        throws Exception {
                                                int k = 0;
                                                for (int i=0; i<200000; i++) {
                                                        for (int j=0; j<100000; j++) {
                                                                if (i==j && i%10000 == 0)
                                                                        k++;
                                                        }
                                                }
                                                System.out.println(k+" "+(System.currentTimeMillis()-start));
                                                return null;
                                        }
                                };
                                testTask.execute();
                        }

                });
                getContentPane().add(button);
                pack();
        }

        public static void main(String[] args) {
                SwingUtilities.invokeLater(new Runnable() {
                        public void run() {
                                DummyFrame f = new DummyFrame();
                                f.setVisible(true);     
                        }
                });
        }
}

The problem is in the VM's implementation of threads. The specification does not specify how this is to be done. Java threads are supposed to map to native Windows threads and then use the Windows scheduler to share time slices. It's unclear if this is exactly going on, and all of the official documentation only supports thread information running on Solaris.

I believe the main problem comes from implementation details for preemption of threads. Probably this is being caused by some combination of code optimization on compiling and preemption control between the JVM and the native OS. JVM's can use method calls as points to preempt threads, and I think part of the problem here is the two loops that you're calling one on top of the other. If you break them up with a function call, it performs much better on my machine. I'm using 1.6.0_23 64-Bit Server VM on Windows 7.

SwingWorker<Void, Integer> testTask = new SwingWorker<Void, Integer>() {

    private int k;

    private void inc() {
        this.k++;
    }

    private void innerLoop(int i) {
        for (int j=0; j<100000; j++) {
            if (i==j && i%10000 == 0)
                this.inc();
        }
    }

    @Override
    protected Void doInBackground()
    throws Exception {
        System.out.println("Started");
        for (int i=0; i<200000; i++) {
            this.innerLoop(i);
        }
        System.out.println(k+" "+(System.currentTimeMillis()-start));
        return null;
    }
};

Even this has problems after starting several of them at once, however. The best solution is to add a call to Thread.yield() each time you start the inner loop. This ensures that the compiled code gives the scheduler an opportunity each iteration to preempt the thread.

I think the problem is just that that code can use 100% CPU so easily. If you have one thread per core running that, there isn't much room for anything else.