Слишком низкая загрузка ЦП многопоточным Java-приложением в Windows

Для Windows количество потоков на процесс ограничено адресным пространством процесса (см. также Марк Руссинович - Расширение границ Windows: процессы и потоки). Думайте, что это вызывает побочные эффекты, когда оно приближается к ограничениям (замедление переключения контекста, фрагментация...). Для Windows я бы попытался разделить нагрузку на набор процессов. Для аналогичной проблемы, с которой я столкнулся много лет назад, я реализовал библиотеку Java, чтобы сделать это более удобно (Java 8), посмотрите, если хотите: Библиотека для создания задач во внешнем процессе.

Похоже, что Windows кэширует некоторую память в файл подкачки после того, как ее не трогали в течение некоторого времени, и поэтому процессор ограничен скоростью диска.

Вы можете проверить это с помощью Process Explorer и проверить, сколько памяти кешируется.

Я думаю, что эта разница в производительности связана с тем, как O.S. управляет потоками. JVM скрывает все различия ОС. Об этом можно прочитать на многих сайтах, например это, например. Но это не значит, что разница исчезает.

Я полагаю, вы работаете на Java 8+ JVM. В связи с этим предлагаю вам попробовать использовать возможности потокового и функционального программирования. Функциональное программирование очень полезно, когда у вас много небольших независимых задач, и вы хотите легко переключиться с последовательного выполнения на параллельное. Хорошей новостью является то, что вам не нужно определять политику для определения количества потоков, которыми вы должны управлять (как в случае с ExecutorService). Например (взято из здесь):

package com.mkyong.java8;

import java.util.ArrayList;
import java.util.List;
import java.util.stream.IntStream;
import java.util.stream.Stream;

public class ParallelExample4 {

    public static void main(String[] args) {

        long count = Stream.iterate(0, n -> n + 1)
                .limit(1_000_000)
                //.parallel()   with this 23s, without this 1m 10s
                .filter(ParallelExample4::isPrime)
                .peek(x -> System.out.format("%s\t", x))
                .count();

        System.out.println("\nTotal: " + count);

    }

    public static boolean isPrime(int number) {
        if (number <= 1) return false;
        return !IntStream.rangeClosed(2, number / 2).anyMatch(i -> number % i == 0);
    }

}

Результат:

Для обычных потоков это занимает 1 минуту 10 секунд. Для параллельных потоков это занимает 23 секунды. P.S Проверено с i7-7700, 16G RAM, Windows 10

Итак, я предлагаю вам прочитать о программировании функций, потоках, лямбда-функциях в Java и попробовать реализовать небольшое количество тестов с вашим кодом (адаптированным для работы в этом новом контексте).

Не могли бы вы опубликовать системную статистику? Диспетчер задач достаточно хорош, чтобы дать некоторую подсказку, если это единственный доступный инструмент. Он может легко определить, ожидают ли ваши задачи ввода-вывода, что звучит как виновник, исходя из того, что вы описали. Это может быть связано с определенной проблемой управления памятью, или библиотека может записать какие-то временные данные на диск и т. д.

Когда вы говорите, что 25% загрузки ЦП, вы имеете в виду, что только несколько ядер заняты одновременной работой? (Возможно, что все ядра работают время от времени, но не одновременно.) Не могли бы вы проверить, сколько потоков (или процессов) реально создано в системе? Всегда ли число больше, чем количество ядер?

Если потоков достаточно, многие из них простаивают в ожидании чего-то? Если это правда, вы можете попытаться прервать (или подключить отладчик), чтобы увидеть, чего они ждут.