线程在 ThreadPoolExecutor 中等待答案

【问题标题】：threads are WAITING in the ThreadPoolExecutor线程在 ThreadPoolExecutor 中等待
【发布时间】：2017-05-02 00:12:28
【问题描述】：

这段代码运行很慢。我转储了线程，几乎有一个线程同时运行，但是当我将ExecutorService 更改为ForkJoinPool 时，代码运行得非常快。我不知道为什么线程在等待，我的电脑有 8 个核心......

public class Tests {

    public static void main(String[] args) throws InterruptedException {

        int NUM_OF_THREADS = 8;
        int NUM_OF_INCREMENTS = 100_000_000;
        //ExecutorService service = Executors.newWorkStealingPool();
        ExecutorService service = Executors.newFixedThreadPool(NUM_OF_THREADS);
        final Counter counter = new StupidCounter();

        long before = System.currentTimeMillis();
        for (int i = 0; i < NUM_OF_INCREMENTS; i++) {
            service.submit(newCounterClient(counter, i));
        }
        service.shutdown();
        service.awaitTermination(1, TimeUnit.MINUTES);
        long end = System.currentTimeMillis();
        System.out.println(end - before);
        System.out.println(counter.getCounter());
    }


    static class CounterClient implements Runnable {
        private Counter counter;
        private int num;

        public CounterClient(Counter counter, int num) {
            this.counter = counter;
            this.num = num;
        }

        @Override
        public void run() {
            counter.increment();
        }
    }

    static interface Counter {
        void increment();

        long getCounter();
    }

    static class StupidCounter implements Counter {
        long i = 0;

        @Override
        public void increment() {
            i++;
        }

        @Override
        public long getCounter() {
            return i;
        }
    }

}

"pool-1-thread-7" #17 prio=5 os_prio=31 tid=0x00007faaa481c000 nid=0x6503 waiting on condition [0x0000700001d6d000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000006c006b3d8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibly(AbstractQueuedSynchronizer.java:897)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1222)
    at java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:335)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:439)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(617Thread.java:745)

【问题讨论】：

标签： java threadpool

【解决方案1】：

很难从这段代码中得出任何真正的结论，因为它并没有真正做任何事情。执行程序的内部队列是瓶颈，这就是为什么您一次只能看到 1 个线程“工作”。它并没有真正起作用，它正在从队列中获取下一个任务，使所有其他线程（也正在获取下一个任务）等待。除了LinkedBlockingQueue.take() 的功能之外，您在这里并没有真正测试任何东西。

increment() 方法不是线程安全的，所以基本上你正在测试错误的代码，结果几乎无关紧要。如果您让CounterClient 任务执行实际工作，这需要几毫秒，与ForkJoinPool 相比，您会发现性能差异（如果有的话）要小得多。

【讨论】：

【解决方案2】：

当使用 FixedThreadPool 时，大部分时间都用于 GarbageCollection，因为程序会消耗大量它。我尝试使用 VM 参数 -Xmx3g 执行，但在 VM 试图避免内存不足时仍然卡在垃圾收集中。

您可能想使用内存转储来深入了解消耗的根本原因，但我猜它是计数器中的 long 实例。

无论如何，根本原因似乎是 FixedThreadPool 使用 LinkedBlockingQueue 作为 workQueue。由于 for 循环将 100_000_000 个元素添加到 workQueue，很少有另一个线程能够从其中获取元素。所以他们大部分时间都在等待，直到所有 CounterClient 都被提交。

ForkJoinPool 使用更非阻塞的方式，据我所知，提交的操作有多个 WorkQueue。

【讨论】：