🕸️ Виртуальные потоки в Java: балансируем на грани скорости и памяти

3D-сцена: ярко-желтые «виртуальные ниточки»-Pac-Man’ы вихрем обступают микросхему памяти с красным знаком «опасность», показывая, как быстродействие виртуальных потоков может привести к переполнению памяти.

Недавно мир Java обзавёлся новым мощным инструментом — виртуальными потоками. Программисты были в восторге: теперь можно создать миллионы потоков с минимальными затратами ресурсов! В теории всё звучит идеально. Но что происходит, если пустить виртуальные потоки в реальный бой, например, запустить мощный веб-краулер?

Такой вопрос задал себе автор статьи, Дарио Балинзо, и ответ оказался весьма неожиданным и поучительным.

🧵 Обычные потоки vs. виртуальные потоки: первые впечатления

Вначале Дарио написал простой веб-краулер, используя классические платформенные потоки:

• 🛠️ Ограниченное число потоков (например, 200) обрабатывает список URL-адресов.
• ⏳ Потоки периодически простаивают, ожидая ответа по сети.
• 📊 Производительность была приемлемой, но не поражала воображение.

Тогда автор решил применить новинку Java — виртуальные потоки (Virtual Threads):

// Переход с платформенных на виртуальные потоки
ExecutorService executorService = Executors.newVirtualThreadPerTaskExecutor();

Первые секунды эксперимента были восторженными: страницы загружались молниеносно. Но вскоре случилось то, чего никто не ожидал:

java.lang.OutOfMemoryError: Java heap space

Виртуальные потоки «съели» всю доступную память, полностью парализовав приложение.

🚀 Почему виртуальные потоки «улетели» за пределы памяти?

На самом деле проблема оказалась не в самих виртуальных потоках, а в том, как они изменили поведение системы:

• 🌐 Виртуальные потоки практически устранили простой во время ожидания ответа от сети.
• 🏃‍♂️ Это привело к резкому скачку параллельно загружаемых страниц.
• 📥 Полученные данные начали скапливаться в памяти быстрее, чем обрабатывались.

Получился парадокс: виртуальные потоки сделали систему настолько быстрой, что она перестала успевать справляться с результатами своей же работы!

🧯 Как решить проблему переполнения памяти?

Дарио предложил несколько простых и эффективных подходов:

🛑 Ограничение количества одновременных задач

Применив семафор, можно управлять нагрузкой:

public class ControlledVirtualThreadsCrawler {
private final ExecutorService executorService =
Executors.newVirtualThreadPerTaskExecutor();
private final Semaphore concurrencyLimit = new Semaphore(500);

private void downloadAndProcess(String url) {
concurrencyLimit.acquire();
try {
// обработка URL
} finally {
concurrencyLimit.release();
}
}
}

Теперь потоки будут ждать разрешения, если лимит превышен, и это позволит сохранить баланс скорости и памяти.

⏲️ Ограничение скорости поступления задач (rate limiting)

В реальных сценариях редко требуется обрабатывать тысячи URL сразу. Если распределять задания постепенно, система не будет переполняться:

• 📉 Ограничение количества запросов в единицу времени.
• 🗃️ Введение очередей с постепенной выдачей заданий.

📌 Что я вынес из этой истории?

Ситуация с виртуальными потоками наглядно демонстрирует важный принцип разработки ПО: «Не бывает бесплатных решений».

• 🧠 Новый подход требует новых решений: С переходом на виртуальные потоки необходимо пересмотреть архитектуру и стратегию управления ресурсами.
• ⚖️ Баланс важнее скорости: Гонка за производительностью без оглядки на память и ресурсы может привести к неожиданным провалам.
• 🔧 Управление ресурсами — ключ к успеху: Явные механизмы (семафоры, rate limiting) должны заменить неявные ограничения старых платформенных потоков.

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

🗒️ Личное мнение:

Лично мне кажется, что Java движется в правильном направлении. Виртуальные потоки — значительный шаг вперёд в управлении параллелизмом и многозадачностью. Но вместе с новыми возможностями неизбежно приходят новые вызовы. Теперь разработчикам придётся явно контролировать параллельные ресурсы, а это требует переосмысления старых архитектурных решений.

Возможно, в скором времени мы увидим новые паттерны и лучшие практики, специально адаптированные для виртуальных потоков, что позволит избежать подобных проблем на этапе проектирования.

🔗 Оригинальная новость:

• Virtual Threads Ate My Memory: A Web Crawler’s Tale of Speed vs. Memory — Medium (Dario Balinzo)

📖 Дополнительные материалы:

• Документация Oracle о виртуальных потоках