Виртуальные потоки — это упрощённая реализация потоков, предоставляемая JDK, а не операционной системой. Они представляют собой разновидность потоков пользовательского режима, которые успешно используются в других многопоточных языках (например, горутины в Go и процессы в Erlang). Потоки пользовательского режима даже назывались «зелёными потоками» в ранних версиях Java, когда потоки операционной системы ещё не были широко распространены. Однако все «зелёные» потоки Java использовали один поток ОС (планирование M:1) и в конечном счёте уступали в производительности платформенным потокам, реализованным как оболочки для потоков ОС (планирование 1:1). Виртуальные потоки используют планирование M:N, при котором большое количество (M) виртуальных потоков планируется к запуску на меньшем количестве (N) потоков ОС.

Потоки в Java

Про потоки в Java важно знать, что они — нормальные потоки операционной системы. Когда-то в первых JVM были реализованы так называемые green threads — зелёные потоки, когда на самом деле стек java-потока как-то жил своей жизнью, и один поток операционной системы выполнял то один java-поток, то другой. Это всё развивалось до тех пор, пока в операционных системах не появилась нормальная многопоточность. После этого все забыли «зелёные» потоки как страшный сон, потому что с нативными потоками код работает лучше.

S>async Task<int> SumAsync(int a, int b) {
S>    return a + b;
S>}

S>var x = await SumAsync(2, 3);
S>

S>func sumAsync(a, b int) <-chan int {
S>    ch := make(chan int, 1)

S>    go func() {
S>        ch <- a + b
S>        close(ch)
S>    }()

S>    return ch
S>}

S>x := <-sumAsync(2, 3)
S>

func sum(a, b int) int {
    return a+b;
}

x:=sum(2,3)

func read() ? {
   data, err := os.ReadFile("image.png")
   ...
}

x:=read()

async Task<?> read() {
   var data = await System.IO.File.ReadAllBytesAsync("image.png")
   ...
}

x = await read();

func sum(a, b int) int {
    return a+b;
}

x:=sum(2,3)

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading;
using System.Threading.Tasks;

class Program
{
    private static int _globalCounter = 0;

    static async Task Main()
    {
        const int n = 10;
        var tasks = new List<Task<int>>(n);

        for (int i = 0; i < n; i++)
        {
            tasks.Add(Task.Run(async () =>
            {
                await Task.Delay(1000);

                int current = Interlocked.Increment(ref _globalCounter);

                if (current % 2 == 0)
                    throw new InvalidOperationException($"Ошибка: счетчик={current}, нельзя вернуть чётное значение.");

                return current;
            }));
        }

        // Ждём все задачи и "гасим" исключение на уровне await через continuation
        await Task.WhenAll(tasks).ContinueWith(t =>
        {
            // можно оставить пусто
            // если нужно — тут можно залогировать:
            // if (t.Exception != null) Console.WriteLine(t.Exception);

        }, TaskContinuationOptions.ExecuteSynchronously);

        var successful = tasks
            .Where(t => t.Status == TaskStatus.RanToCompletion)
            .Select(t => t.Result)
            .ToList();

        var errors = tasks
            .Where(t => t.IsFaulted)
            .SelectMany(t => t.Exception!.Flatten().InnerExceptions)
            .Select(ex => ex.Message)
            .ToList();

        Console.WriteLine("Успешные результаты: " + (successful.Count == 0 ? "(нет)" : string.Join(", ", successful)));
        Console.WriteLine("Сумма успешных результатов: " + successful.Sum());

        Console.WriteLine($"Успешно: {successful.Count}, с ошибкой: {errors.Count}");

        Console.WriteLine("Тексты ошибок:");
        if (errors.Count == 0)
        {
            Console.WriteLine("(нет)");
        }
        else
        {
            foreach (var e in errors)
                Console.WriteLine(" - " + e);
        }

        Console.WriteLine("Финальный глобальный счетчик: " + _globalCounter);
    }
}

·>Перечитай ещё раз. В java нет зелёных потоков четверть века.

Плюсы
Простое API: go f() — и готово.

Масштабируемость по умолчанию.

Автоматическая работа с блокировками I/O.

Минусы
Нет контроля над временем жизни — нет structured concurrency.

Потенциальные утечки: забыли завершить — висят.

Возможны блокировки, если не соблюдать правила, например, mutex.

import kotlinx.coroutines.*

fun main() = runBlocking {
    launch {
        println("Привет из корутины!")
    }
    println("Привет из main")
    delay(1000L)
}

Плюсы
Очень экономичны по ресурсам.

Structured concurrency, runBlocking, coroutineScope.

Совместимы с существующим синхронным кодом.

Минусы
Сложная внутренняя реализация — CPS, state‑machine.

Нужно уметь работать с context«ами, scope, Job, Dispatcher.

Возможны утечки при неправильном использовании.

Что обещали и что получилось
Ожидания: миллионы легких потоков, «магическое» устранение простоев на I/O, совместимость со старым кодом, простота reasoning, минимум усилий со стороны разработчика.

Реальность в целом подтвердилась — если не задевать проблемные места. Там, где нет synchronized, нет повсюду ThreadLocal и не нужно дебажить потоки, все работает, как задумано. Но в продакшене быстро проявились нюансы.

Выводы по Java 21
Работает «из коробки». Виртуальные потоки действительно легкие: можно запускать десятки тысяч.

Совместимость со старым кодом — в целом «да».

Узкое место — synchronized. Множество библиотек, заточенных под старую модель, оказались не готовы.

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