Я люблю стректрейсы и понятный линейный код. И соответственно не люблю реактивщину. Все примеры будут нереактивными с последовательным понятным кодом.
Примеры запускались на доступной сегодня jdk.
openjdk version "19-loom" 2022-09-20
OpenJDK Runtime Environment (build 19-loom+6-625)
OpenJDK 64-Bit Server VM (build 19-loom+6-625, mixed mode, sharing)Не забываем про --enable-preview флажок.
В этой jdk доступны такие методы для экспериментирования с виртуальными потоками:
/**
* Creates a virtual thread to execute a task and schedules it to execute.
*
* <p> This method is equivalent to:
* <pre>{@code Thread.ofVirtual().start(task); }</pre>
*
* @param task the object to run when the thread executes
* @return a new, and started, virtual thread
* @throws UnsupportedOperationException if preview features are not enabled
* @see <a href="#inheritance">Inheritance when creating threads</a>
* @since 19
*/
@PreviewFeature(feature = PreviewFeature.Feature.VIRTUAL_THREADS)
public static Thread startVirtualThread(Runnable task) { ... }и
/**
* Creates an Executor that starts a new virtual Thread for each task.
* The number of threads created by the Executor is unbounded.
*
* <p> This method is equivalent to invoking
* {@link #newThreadPerTaskExecutor(ThreadFactory)} with a thread factory
* that creates virtual threads.
*
* @return a new executor that creates a new virtual Thread for each task
* @throws UnsupportedOperationException if preview features are not enabled
* @since 19
*/
@PreviewFeature(feature = PreviewFeature.Feature.VIRTUAL_THREADS)
public static ExecutorService newVirtualThreadPerTaskExecutor() { .... }Не очень много, но для экспериментов хватит.
Общий код запуска тестов:
@BenchmarkMode(Mode.AverageTime)
@Warmup(iterations = 1)
@Measurement(iterations = 2)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@State(Scope.Benchmark)
public class BenchmarkThreading {
public static void main(String[] args) throws RunnerException {
Options opt = new OptionsBuilder()
.include(BenchmarkThreading.class.getSimpleName())
.forks(1)
.build();
new Runner(opt).run();
}
//тут тесты
}Производительность
Для начала проверим самое простое. Создание потоков. Убедимся что виртуальные потоки работают так как и ожидается.
@Benchmark
public void testCreateVirtualThread(Blackhole blackhole) {
for (int i=0; i<100; ++i) {
int finalI = i;
Thread.startVirtualThread(() -> blackhole.consume(finalI));
}
}
@Benchmark
public void testCreateThread(Blackhole blackhole) {
for (int i = 0; i < 1000; ++i) {
int finalI = i;
var thread = new Thread(() -> blackhole.consume(finalI));
thread.start();
}
}
Benchmark Mode Cnt Score Error Units
BenchmarkThreading.testCreateThread avgt 199158,959 us/op
BenchmarkThreading.testCreateVirtualThread avgt 53,674 us/opРезультат получился ожидаемый и не удивительный. Виртуальные потоки создаются на порядки быстрее обычных как и ожидается.
А что они нам дадут в более-менее реальных примерах использования? Нормальная программа на Джаве не создает потоки в нагруженных участках кода, а использует пулы и экзекуторы.
Попробуем экзекутором выполнить микрозадачи:
@Benchmark
public void testVirtualExecutorSmallTask(Blackhole blackhole) {
try(var executor = Executors.newVirtualThreadPerTaskExecutor()){
for (int i = 0; i < 100; ++i) {
int finalI = i;
executor.submit(() -> blackhole.consume(finalI));
}
}
}
@Benchmark
public void testCachedExecutorSmallTask(Blackhole blackhole) throws InterruptedException {
try(var executor = Executors.newCachedThreadPool()){
for (int i = 0; i < 100; ++i) {
int finalI = i;
executor.submit(() -> blackhole.consume(finalI));
}
}
}
@Benchmark
public void testFixedExecutorSmallTask(Blackhole blackhole) throws InterruptedException {
try(var executor = Executors.newFixedThreadPool(20)){
for (int i = 0; i < 100; ++i) {
int finalI = i;
executor.submit(() -> blackhole.consume(finalI));
}
}
}Benchmark Mode Cnt Score Error Units
BenchmarkThreading.testCachedExecutorSmallTask avgt 2 1233,639 us/op
BenchmarkThreading.testFixedExecutorSmallTask avgt 2 2156,590 us/op
BenchmarkThreading.testVirtualExecutorSmallTask avgt 2 96,231 us/opРезультат тоже хорош. За исключение того что с размером fixed пула я не угадал. Ну ладно, на практике в продакшен коде типовой мидл тоже никогда не угадает.
А что если сделать тест еще ближе к реальности? В нормальном коде в поток выносят операции занимающее какое-то значимое количество времени.
На моей тестовой машине Blackhole.consumeCPU(100_000_000) занимает около 200мс что можно принять разумным временем на задачу которую уже можно отправлять в отдельный поток.
@Benchmark
public void testVirtualExecutorNormalTask(Blackhole blackhole) {
try(var executor = Executors.newVirtualThreadPerTaskExecutor()){
for (int i = 0; i < 100; ++i) {
executor.submit(() -> Blackhole.consumeCPU(100_000_000));
}
}
}
@Benchmark
public void testCachedExecutorNormalTask(Blackhole blackhole) throws InterruptedException {
try(var executor = Executors.newCachedThreadPool()){
for (int i = 0; i < 100; ++i) {
executor.submit(() -> Blackhole.consumeCPU(100_000_000));
}
}
}
@Benchmark
public void testFixedExecutorNormalTask(Blackhole blackhole) throws InterruptedException {
try(var executor = Executors.newFixedThreadPool(20)){
for (int i = 0; i < 100; ++i) {
executor.submit(() -> Blackhole.consumeCPU(100_000_000));
}
}
}
Benchmark Mode Cnt Score Error Units
BenchmarkThreading.testCachedExecutorNormalTask avgt 2 5249759,575 us/op
BenchmarkThreading.testFixedExecutorNormalTask avgt 2 5247051,750 us/op
BenchmarkThreading.testVirtualExecutorNormalTask avgt 2 5246058,750 us/opРазницы нет. Это было ожидаемо. На такой нагрузке работа с потоками занимает пренебрежимо малое время по сравнению с бизнес логикой. Не загромождая статью исходниками покажу результат для других значений Blackhole.consumeCPU(ххх)
10_000_000 или 20мс на задачу
Benchmark Mode Cnt Score Error Units
BenchmarkThreading.testCachedExecutorNormalTask avgt 2 553018,934 us/op
BenchmarkThreading.testFixedExecutorNormalTask avgt 2 564500,005 us/op
BenchmarkThreading.testVirtualExecutorNormalTask avgt 2 530236,755 us/op
1_000_000 или 2мс на задачу
Benchmark Mode Cnt Score Error Units
BenchmarkThreading.testCachedExecutorNormalTask avgt 2 65124,411 us/op
BenchmarkThreading.testFixedExecutorNormalTask avgt 2 54710,276 us/op
BenchmarkThreading.testVirtualExecutorNormalTask avgt 2 53285,513 us/op
100_000 или 0.2мс на задачу
Benchmark Mode Cnt Score Error Units
BenchmarkThreading.testCachedExecutorNormalTask avgt 2 14088,289 us/op
BenchmarkThreading.testFixedExecutorNormalTask avgt 2 8267,134 us/op
BenchmarkThreading.testVirtualExecutorNormalTask avgt 2 5792,022 us/op
10_000 или 0.02мс на задачу
Benchmark Mode Cnt Score Error Units
BenchmarkThreading.testCachedExecutorNormalTask avgt 2 2377,223 us/op
BenchmarkThreading.testFixedExecutorNormalTask avgt 2 2757,024 us/op
BenchmarkThreading.testVirtualExecutorNormalTask avgt 2 664,795 us/opРазница становится явно видна на совсем маленьких задачах. Там где менеджмент потоков начинает занимать значимое время от всей остальной логики.
Можно сделать вывод что в типовом нормальном Джава коде плюсов по производительности от простого включения виртуальных потоков мы не заметим. Если вы у себя её заметили, то стоит покопаться по коду поискать где вы используете потоки для слишком маленьких задач.
Зато мы получаем возможность кидать в отдельный поток просто все что угодно. Разница для микрозадач колоссальна. Это откроет некоторые возможности более удобно писать код и лучше утилизировать все доступные ядра во вроде бы однопоточном коде. Может быть наконец-то появится смысл в .parallelStream() при использовании виртуальных потоков внутри.
И как обычно пойдет куча ошибок с созданием слишком большого и ненужного числа виртуальных потоков, со всеми радостями отладки без стектрейсов потом. Исследовать непойманное исключение в логах в котором нет ни одной строчки твоего кода это очень увлекательный процесс.
А что с памятью?
Уже давно ходят слухи что потоки в Джаве очень прожорливы до памяти. Я читал версии что каждый поток стоит мегабайты памяти просто так на создание. И виртуальные потоки всех нас спасут от покупки дополнительной памяти в наши кластера.
Исследовать расход памяти в Джаве на что-то это довольно неоднозначный процесс. Предлагаю тривиально оценить расход памяти на какое-то число созданных, запущенных и ничего не делающих потоков. Это довольно типовая ситуация когда основная часть потоков висит на IO и ждет данных. Обычно именно таких потоков хочется побольше для удобства разработки.
Приложение для оценки простейшее:
public static void main(String[] args) {
for(int i=0; i<100; ++i) {
var thread = new Thread(() -> {
Blackhole.consumeCPU(1);
try {
Thread.sleep(100_000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
});
thread.start();
}
System.exit(0);
}
JDK17 LTS. Тех кто еще не обновился мне уже даже не жалко. Давно пора обновиться было.
openjdk version "17.0.3" 2022-04-19
OpenJDK Runtime Environment Temurin-17.0.3+7 (build 17.0.3+7)
OpenJDK 64-Bit Server VM Temurin-17.0.3+7 (build 17.0.3+7, mixed mode, sharing)Никаких особых ключей запуска: -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary -XX:+PrintNMTStatistics -Xmx4G
71
Thread (reserved=75855304, committed=4_793_800)
(thread #71) (stack: reserved=75497472, committed=4435968)
(malloc=178456 #744)
(arena=179376 #245)
1_016
Thread (reserved=1069151112, committed=65_549_192)
(thread #1016) (stack: reserved=1066401792, committed=62799872)
(malloc=1526056 #7146)
(arena=1223264 #2040)
10_018
Thread (reserved=10532726584, committed=643_856_184)
(thread #10018) (stack: reserved=10505682944, committed=616812544)
(malloc=15013392 #70316)
(arena=12030248 #20051)Видна хорошая закономерность с расходом около 64 килобайт памяти на пустой поток.
Виртуальные потоки в этом месте память под себя не требуют, и будут занимать что-то схожее с типичным Джава объектом размером в десятки-сотни байт. Можно упрощенно считать что это 0 по сравнению с 64 килобайтами на классический поток.
Выводы
Отрицательно:
Нас ждут увлекательные баталии в код ревью о новых практиках написания кода
Количество ошибок с многопоточностью заметно возрастет
Нейтрально:
Виртуальные потоки не дадут никакого ускорения в типичном джава приложении без переписывания кода
Виртуальные потоки не уменьшат потребление памяти нормально сделанным приложением. 64 килобайта * 1_000 типовых потоков, это неинтересно
Положительно:
Виртуальные потоки дадут возможность по новому писать код. Паралелим все что не запрещено математикой
.parallelStream обретает смысл
Виртуальные потоки дадут возможность более эффективно утилизировать доступные ядра. Без выделения больших независимых кусков кода и реактивщины
