Много блокирующих задач в Java

Типичный веб‑сервис большую часть времени ждёт: сеть, диск, ответ СУБД. Задача при этом не нагружает процессор, но поток занят, пока вызов не вернётся. Если таких ожиданий тысячи, модель «один запрос, один платформенный поток» упирается в память и лимиты ОС.

Виртуальные потоки как раз рассчитаны на массовую блокирующую работу. Пока задача спит в Thread.sleep или ждёт I/O, носитель может переключиться на другой виртуальный поток. Поэтому десятки тысяч «спящих» задач в одной JVM на Java 27 обычно остаются практичными, если не держать лишние ссылки и не блокировать носитель синхронно без нужды.

Упрощённая имитация множества ожиданий через исполнитель и короткий сон:

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;

public class Main {
	public static void main(String[] args) throws InterruptedException {
		int tasks = 10_000;
		AtomicInteger done = new AtomicInteger();
		try (ExecutorService exec = Executors.newVirtualThreadPerTaskExecutor()) {
			for (int i = 0; i < tasks; i++) {
				exec.submit(() -> {
					try {
						Thread.sleep(10);
					} catch (InterruptedException e) {
						Thread.currentThread().interrupt();
						return;
					}
					done.incrementAndGet();
				});
			}
		}
		System.out.println("finished: " + done.get());
	}
}

После закрытия исполнителя счётчик должен показать 10000. На платформенном пуле с тем же числом потоков ОС такой эксперимент либо не стартовал бы, либо потребовал бы гигабайты стеков.

Важно не путать масштаб с CPU‑нагрузкой: если каждая задача крутит тяжёлые вычисления без пауз, выгода виртуальных потоков падает. Для чистого параллелизма на ядрах по‑прежнему смотрят на пулы платформенных потоков или специализированные API.

Запустите на виртуальных потоках 500 задач с sleep(20). Выведите число завершившихся задач. Сравните время выполнения с одним платформенным потоком, который выполняет те же шаги по очереди.