Виртуальные потоки — бесплатный тест онлайн

Вопрос 1 из 30

Какой граничный случай особенно важен для темы «Закрепление виртуальных потоков» в разделе «Виртуальные потоки»?

// Минимальный пример
synchronized (monitor) {
    result = blockingOperation();
}

synchronized static использует монитор Class-объекта и не совпадает с монитором экземпляра. Увеличение кучи уменьшает частоту сборок, но может продлить некоторые циклы и скрыть утечку до более позднего момента. Кэш Method ускоряет поиск, но первый доступ, проверка доступности и исключения вызова всё равно требуют контроля. Сбор снимка кучи может остановить или заметно нагрузить процесс; кроме того, снимок способен содержать секреты. Закрепление не делает результат некорректным; оно влияет на масштабирование и доступность потоков-носителей.

Вопрос 2 из 30

Как лучше исправить или прояснить поведение темы «Выбор архитектуры» в разделе «Виртуальные потоки»?

// Фрагмент на ревью
try (var ex = java.util.concurrent.Executors.newVirtualThreadPerTaskExecutor()) {
    for (var image : images) ex.submit(() -> render4k(image));
}

Для вычислительного этапа использовать ограниченный исполнитель задач или структурированное разбиение с контролем параллелизма. Проверять события JFR и обновлять рекомендации с учётом версии JDK, а не механически заменять каждый synchronized на Lock. Не хранить тяжёлый буфер в ThreadLocal виртуального потока: использовать локальный ограниченный буфер, пул с явным пределом или потоковую обработку. Добавить ограниченный тестовый пул соединений, метрики ожидания и сценарий массовой отмены. Писать прямой последовательный код и ограничивать внешние ресурсы семафорами или пулами, а не числом виртуальных потоков.

Вопрос 3 из 30

Какой контракт языка или библиотеки точнее всего описывает тему «Производительность и эксплуатация» в разделе «Виртуальные потоки»?

Виртуальные потоки подходят для большого числа задач, которые преимущественно ждут ввод-вывод; вычислительную работу всё равно ограничивает число доступных ядер. Виртуальный поток — обычный Thread для кода приложения, который JVM планирует поверх небольшого числа потоков-носителей. Начиная с JDK 24, ожидание внутри synchronized обычно не закрепляет виртуальный поток за потоком-носителем; нативные и некоторые критические участки всё ещё требуют наблюдения. Ключевые метрики — число активных и ожидающих виртуальных потоков, занятость потоков-носителей, очередь внешнего ресурса и хвостовые задержки. Масштабирование с виртуальными потоками ограничивают внешние ресурсы и память на задачу; дешёвое ожидание не отменяет регулирование входной нагрузки.

Вопрос 4 из 30

Какой контракт языка или библиотеки точнее всего описывает тему «Блокирующий ввод-вывод» в разделе «Виртуальные потоки»?

Ключевые метрики — число активных и ожидающих виртуальных потоков, занятость потоков-носителей, очередь внешнего ресурса и хвостовые задержки. Большинство поддерживаемых блокирующих операций парковает виртуальный поток и освобождает поток-носитель для другой задачи. Виртуальный поток — обычный Thread для кода приложения, который JVM планирует поверх небольшого числа потоков-носителей. Масштабирование с виртуальными потоками ограничивают внешние ресурсы и память на задачу; дешёвое ожидание не отменяет регулирование входной нагрузки. Начиная с JDK 24, ожидание внутри synchronized обычно не закрепляет виртуальный поток за потоком-носителем; нативные и некоторые критические участки всё ещё требуют наблюдения.

Вопрос 5 из 30

Как поведёт себя фрагмент по теме «Тестирование и диагностика» при разборе раздела «Виртуальные потоки»?

try (var ex = java.util.concurrent.Executors.newVirtualThreadPerTaskExecutor()) {
    var tasks = java.util.stream.IntStream.range(0, 50_000)
        .mapToObj(i -> ex.submit(() -> dataSource.getConnection()))
        .toList();
}

Запуск миллиона тяжёлых вычислений в отдельных виртуальных потоках создаёт конкуренцию за процессор и память, а не ускорение. Каждый виртуальный поток, обратившийся к BUFFER, получает собственный массив примерно на 1 МБ; десятки тысяч одновременных задач способны исчерпать память. Создание отдельного виртуального потока для каждой блокирующей задачи не требует отдельного платформенного потока на всё время её жизни. Старое правило «любой synchronized обязательно закрепляет виртуальный поток» неверно для современных JDK, но длительную работу под монитором всё равно стоит сокращать. Пятьдесят тысяч задач сразу запрашивают соединение из ограниченного пула; большая часть виртуальных потоков будет ждать, удерживая контекст и создавая давление на зависимость.

Вопрос 6 из 30

Что следует изменить в разделе «Виртуальные потоки», чтобы сохранить замысел и соблюсти контракт «Закрепление виртуальных потоков»?

// Фрагмент на ревью
synchronized (monitor) {
    result = blockingOperation();
}

Сохранять блокирующий стиль для I/O и отдельно ограничивать соединения, запросы и память. Проверять события JFR и обновлять рекомендации с учётом версии JDK, а не механически заменять каждый volatile на Lock. Писать прямой последовательный код и ограничивать внешние ресурсы семафорами или пулами, а не числом виртуальных потоков. Проверять события JFR и обновлять рекомендации с учётом версии JDK, а не механически заменять каждый synchronized на Lock. Не хранить тяжёлый буфер в ThreadLocal виртуального потока: использовать локальный ограниченный буфер, пул с явным пределом или потоковую обработку.

Вопрос 7 из 30

Что произойдёт с кодом по теме «Модель выполнения» в разделе «Виртуальные потоки»?

try (var executor = java.util.concurrent.Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 100_000; i++)
        executor.submit(() -> callRemoteService());
}

Создание отдельного виртуального потока для каждой блокирующей задачи не требует отдельного платформенного потока на всё время её жизни. Запуск миллиона тяжёлых вычислений в отдельных виртуальных потоках создаёт конкуренцию за процессор и память, а не ускорение. Тысячи запросов, ожидающих сокет, могут обслуживаться небольшим числом потоков-носителей без цепочек функций обратного вызова. Старое правило «любой synchronized обязательно закрепляет виртуальный поток» неверно для современных JDK, но длительную работу под монитором всё равно стоит сокращать. Пятьдесят тысяч задач сразу запрашивают соединение из ограниченного пула; большая часть виртуальных потоков будет ждать, удерживая контекст и создавая давление на зависимость.

Вопрос 8 из 30

Какой вывод о synchronized верен для виртуальных потоков в Java 25?

synchronized (monitor) {
    result = blockingOperation();
}

Старое правило «любой volatile обязательно закрепляет виртуальный поток» неверно для современных JDK, но длительную работу под монитором всё равно стоит сокращать. Каждый виртуальный поток, обратившийся к BUFFER, получает собственный массив примерно на 1 МБ; десятки тысяч одновременных задач способны исчерпать память. Старое правило «любой synchronized обязательно закрепляет виртуальный поток» неверно для современных JDK, но длительную работу под монитором всё равно стоит сокращать. Тысячи запросов, ожидающих сокет, могут обслуживаться небольшим числом потоков-носителей без цепочек функций обратного вызова. Создание отдельного виртуального потока для каждой блокирующей задачи не требует отдельного платформенного потока на всё время её жизни.

Вопрос 9 из 30

Как точнее оценить пользу и цену решения по теме «Закрепление виртуальных потоков» в разделе «Виртуальные потоки»?

Масштабируемое ожидание позволяет принять больше работы, поэтому без ограничения входной нагрузки система может быстрее перегрузить внешнюю зависимость. Масштабный тест должен быть ограничен ресурсами стенда, иначе измеряется авария генератора нагрузки, а не приложения. Замена примитива может убрать конкретное ограничение, но длинная критическая секция и конкуренция за общий ресурс останутся. Крупная критическая секция проще для корректности, но снижает параллелизм и увеличивает задержку ожидания. Модель упрощает наблюдение и чтение трассировок стека, но не уменьшает объём вычислительной работы и не отменяет управление нагрузкой.

Вопрос 10 из 30

Какой контракт языка или библиотеки точнее всего описывает тему «Выбор архитектуры» в разделе «Виртуальные потоки»?

Начиная с JDK 24, ожидание внутри synchronized обычно не закрепляет виртуальный поток за потоком-носителем; нативные и некоторые критические участки всё ещё требуют наблюдения. Масштабирование с виртуальными потоками ограничивают внешние ресурсы и память на задачу; дешёвое ожидание не отменяет регулирование входной нагрузки. Большинство поддерживаемых блокирующих операций парковает виртуальный поток и освобождает поток-носитель для другой задачи. Виртуальные потоки подходят для большого числа задач, которые преимущественно ждут ввод-вывод; вычислительную работу всё равно ограничивает число доступных ядер. Виртуальный поток — обычный Thread для кода приложения, который JVM планирует поверх небольшого числа потоков-носителей.

Вопрос 11 из 30

Как поведёт себя фрагмент по теме «Производительность и эксплуатация» при разборе раздела «Виртуальные потоки»?

class BufferTask {
    static final ThreadLocal<byte[]> BUFFER =
        ThreadLocal.withInitial(() -> new byte[1_000_000]);
    static void use() { System.out.println(BUFFER.get().length); }
}
for (int i = 0; i < 50_000; i++) Thread.startVirtualThread(BufferTask::use);

Каждый виртуальный поток, обратившийся к BUFFER, получает собственный массив примерно на 1 МБ; десятки тысяч одновременных задач способны исчерпать память. Пятьдесят тысяч задач сразу запрашивают соединение из ограниченного пула; большая часть виртуальных потоков будет ждать, удерживая контекст и создавая давление на зависимость. Каждый виртуальный поток, обратившийся к BUFFER, получает собственный массив примерно на 2 МБ; десятки тысяч одновременных задач способны исчерпать память. Старое правило «любой synchronized обязательно закрепляет виртуальный поток» неверно для современных JDK, но длительную работу под монитором всё равно стоит сокращать. Каждый виртуальный поток, обратившийся к BUFFER, получает собственный массив примерно на 0 МБ; десятки тысяч одновременных задач способны исчерпать память.

Вопрос 12 из 30

Какая правка точнее всего устраняет причину проблемы по теме «Производительность и эксплуатация» в разделе «Виртуальные потоки»?

// Фрагмент на ревью
class BufferTask {
    static final ThreadLocal<byte[]> BUFFER =
        ThreadLocal.withInitial(() -> new byte[1_000_000]);
    static void use() { System.out.println(BUFFER.get().length); }
}
for (int i = 0; i < 50_000; i++) Thread.startVirtualThread(BufferTask::use);

Для вычислительного этапа использовать ограниченный исполнитель задач или структурированное разбиение с контролем параллелизма. Не хранить тяжёлый буфер в ThreadLocal виртуального потока: использовать локальный ограниченный буфер, пул с явным пределом или потоковую обработку. Проверять события JFR и обновлять рекомендации с учётом версии JDK, а не механически заменять каждый synchronized на Lock. Писать прямой последовательный код и ограничивать внешние ресурсы семафорами или пулами, а не числом виртуальных потоков. Задать размер кучи с запасом после измерения общей резидентной памяти и нативной памяти, включить Native Memory Tracking и проверить поведение под рабочей нагрузкой.

Вопрос 13 из 30

Какое ограничение механизма «Выбор архитектуры» нельзя упускать при работе с разделом «Виртуальные потоки»?

// Минимальный пример
try (var ex = java.util.concurrent.Executors.newVirtualThreadPerTaskExecutor()) {
    for (var image : images) ex.submit(() -> render4k(image));
}

Кэширование ThreadLocal для тяжёлых объектов может превратить дешёвый поток в дорогой. Закрепление не делает результат некорректным; оно влияет на масштабирование и доступность потоков-носителей. Снимок потоков виртуальных потоков может быть огромным; полезны группировка, JFR и контекст структурированных задач. ThreadLocal на каждом виртуальном потоке логически работает, но большие значения умножают расход памяти на число задач. Приоритеты и привязку к потоку виртуальных потоков не следует использовать как механизм планирования приложения.

Вопрос 14 из 30

Какое правило Java действует для темы «Модель выполнения» в разделе «Виртуальные потоки»?

Виртуальный поток — обычный Thread для кода приложения, который JVM планирует поверх небольшого числа потоков-носителей. Большинство поддерживаемых блокирующих операций парковает виртуальный поток и освобождает поток-носитель для другой задачи. Виртуальные потоки подходят для большого числа задач, которые преимущественно ждут ввод-вывод; вычислительную работу всё равно ограничивает число доступных ядер. Ключевые метрики — число активных и ожидающих виртуальных потоков, занятость потоков-носителей, очередь внешнего ресурса и хвостовые задержки. Начиная с JDK 24, ожидание внутри synchronized обычно не закрепляет виртуальный поток за потоком-носителем; нативные и некоторые критические участки всё ещё требуют наблюдения.

Вопрос 15 из 30

Какое ограничение механизма «Модель выполнения» нельзя упускать при работе с разделом «Виртуальные потоки»?

// Минимальный пример
try (var executor = java.util.concurrent.Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 100_000; i++)
        executor.submit(() -> callRemoteService());
}

Снимок потоков виртуальных потоков может быть огромным; полезны группировка, JFR и контекст структурированных задач. Приоритеты и привязку к потоку виртуальных потоков не следует использовать как механизм планирования приложения. ThreadLocal на каждом виртуальном потоке логически работает, но большие значения умножают расход памяти на число задач. Блокирующий нативный вызов или неподдерживаемая операция может удерживать поток-носитель дольше ожидаемого. Закрепление не делает результат некорректным; оно влияет на масштабирование и доступность потоков-носителей.

Вопрос 16 из 30

Как лучше исправить или прояснить поведение темы «Тестирование и диагностика» в разделе «Виртуальные потоки»?

// Фрагмент на ревью
try (var ex = java.util.concurrent.Executors.newVirtualThreadPerTaskExecutor()) {
    var tasks = java.util.stream.IntStream.range(0, 50_000)
        .mapToObj(i -> ex.submit(() -> dataSource.getConnection()))
        .toList();
}

Для вычислительного этапа использовать ограниченный исполнитель задач или структурированное разбиение с контролем параллелизма. Добавить ограниченный тестовый пул соединений, метрики ожидания и сценарий массовой отмены. Проверять события JFR и обновлять рекомендации с учётом версии JDK, а не механически заменять каждый synchronized на Lock. Писать прямой последовательный код и ограничивать внешние ресурсы семафорами или пулами, а не числом виртуальных потоков. Сохранять блокирующий стиль для I/O и отдельно ограничивать соединения, запросы и память.

Вопрос 17 из 30

В каком дополнительном сценарии вывод о теме «Блокирующий ввод-вывод» в разделе «Виртуальные потоки» может оказаться неверным?

Thread.startVirtualThread(() -> {
    var body = java.net.http.HttpClient.newHttpClient().send(
        request, java.net.http.HttpResponse.BodyHandlers.ofString());
    save(body.body());
// ...

Приоритеты и привязку к потоку виртуальных потоков не следует использовать как механизм планирования приложения. Кэширование ThreadLocal для тяжёлых объектов может превратить дешёвый поток в дорогой. Блокирующий нативный вызов или неподдерживаемая операция может удерживать поток-носитель дольше ожидаемого. Снимок потоков виртуальных потоков может быть огромным; полезны группировка, JFR и контекст структурированных задач. Закрепление не делает результат некорректным; оно влияет на масштабирование и доступность потоков-носителей.

Вопрос 18 из 30

Какой инженерный компромисс характерен для темы «Производительность и эксплуатация» в разделе «Виртуальные потоки»?

Масштабируемое ожидание не позволяет принять больше работы, поэтому без ограничения входной нагрузки система может быстрее перегрузить внешнюю зависимость. Замена примитива может убрать конкретное ограничение, но длинная критическая секция и конкуренция за общий ресурс останутся. Масштабируемое ожидание позволяет принять больше работы, поэтому без ограничения входной нагрузки система может быстрее перегрузить внешнюю зависимость. Масштабный тест должен быть ограничен ресурсами стенда, иначе измеряется авария генератора нагрузки, а не приложения. Модель упрощает наблюдение и чтение трассировок стека, но не уменьшает объём вычислительной работы и не отменяет управление нагрузкой.

Вопрос 19 из 30

Какой архитектурный вывод точнее всего относится к показанной нагрузке?

// images содержит 1_000_000 элементов; render4k выполняет тяжёлые вычисления на процессоре
try (var ex = java.util.concurrent.Executors.newVirtualThreadPerTaskExecutor()) {
    for (var image : images) ex.submit(() -> render4k(image));
}

Запуск миллиона тяжёлых вычислений в отдельных виртуальных потоках создаёт конкуренцию за процессор и память, а не ускорение. Запуск миллиона тяжёлых вычислений в отдельных виртуальных потоках не создаёт конкуренцию за процессор и память, а не ускорение. Создание отдельного виртуального потока для каждой блокирующей задачи не требует отдельного платформенного потока на всё время её жизни. Глубокая рекурсия исчерпывает стек и приводит к StackOverflowError независимо от объёма свободной памяти в куче. Старое правило «любой synchronized обязательно закрепляет виртуальный поток» неверно для современных JDK, но длительную работу под монитором всё равно стоит сокращать.

Вопрос 20 из 30

Какое изменение сделает код по теме «Модель выполнения» в разделе «Виртуальные потоки» надёжнее?

// Фрагмент на ревью
try (var executor = java.util.concurrent.Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 100_000; i++)
        executor.submit(() -> callRemoteService());
}

Не хранить тяжёлый буфер в ThreadLocal виртуального потока: использовать локальный ограниченный буфер, пул с явным пределом или потоковую обработку. Проверять события JFR и обновлять рекомендации с учётом версии JDK, а не механически заменять каждый synchronized на Lock. Писать прямой параллельный код и ограничивать внешние ресурсы семафорами или пулами, а не числом виртуальных потоков. Писать прямой последовательный код и ограничивать внешние ресурсы семафорами или пулами, а не числом виртуальных потоков. Заменить неограниченную рекурсию итерацией или ограничить глубину входа.

Вопрос 21 из 30

Какой диагноз для кода по теме «Блокирующий ввод-вывод» в разделе «Виртуальные потоки» будет точным?

Thread.startVirtualThread(() -> {
    var body = java.net.http.HttpClient.newHttpClient().send(
        request, java.net.http.HttpResponse.BodyHandlers.ofString());
    save(body.body());
});

Пятьдесят тысяч задач сразу запрашивают соединение из ограниченного пула; большая часть виртуальных потоков будет ждать, удерживая контекст и создавая давление на зависимость. Тысячи запросов, ожидающих сокет, могут обслуживаться небольшим числом потоков-носителей без цепочек функций обратного вызова. Запуск миллиона тяжёлых вычислений в отдельных виртуальных потоках создаёт конкуренцию за процессор и память, а не ускорение. Каждый виртуальный поток, обратившийся к BUFFER, получает собственный массив примерно на 1 МБ; десятки тысяч одновременных задач способны исчерпать память. Создание отдельного виртуального потока для каждой блокирующей задачи не требует отдельного платформенного потока на всё время её жизни.

Вопрос 22 из 30

Какой граничный случай особенно важен для темы «Производительность и эксплуатация» в разделе «Виртуальные потоки»?

// ...
    static void use() { System.out.println(BUFFER.get().length); }
}
for (int i = 0; i < 50_000; i++) Thread.startVirtualThread(BufferTask::use);

Закрепление не делает результат некорректным; оно влияет на масштабирование и доступность потоков-носителей. Блокирующий нативный вызов или неподдерживаемая операция может удерживать поток-носитель дольше ожидаемого. Кэширование ThreadLocal для тяжёлых объектов может превратить дешёвый поток в дорогой. Приоритеты и привязку к потоку виртуальных потоков не следует использовать как механизм планирования приложения. ThreadLocal на каждом виртуальном потоке логически работает, но большие значения умножают расход памяти на число задач.

Вопрос 23 из 30

В каком дополнительном сценарии вывод о теме «Тестирование и диагностика» в разделе «Виртуальные потоки» может оказаться неверным?

try (var ex = java.util.concurrent.Executors.newVirtualThreadPerTaskExecutor()) {
    var tasks = java.util.stream.IntStream.range(0, 50_000)
        .mapToObj(i -> ex.submit(() -> dataSource.getConnection()))
        .toList();
}

Снимок потоков виртуальных потоков может быть огромным; полезны группировка, JFR и контекст структурированных задач. ThreadLocal на каждом виртуальном потоке логически работает, но большие значения умножают расход памяти на число задач. Большое число потоков потребляет память стеков и служебных структур, хотя виртуальные потоки используют иной растущий стек. Закрепление не делает результат некорректным; оно влияет на масштабирование и доступность потоков-носителей. Приоритеты и привязку к потоку виртуальных потоков не следует использовать как механизм планирования приложения.

Вопрос 24 из 30

Какое замечание о сопровождении или производительности темы «Выбор архитектуры» в разделе «Виртуальные потоки» справедливо?

Виртуальные потоки повышают пропускную способность системы с большим числом операций, ожидающих ввода-вывода, но задержка удалённого сервиса остаётся прежней. Модель упрощает наблюдение и чтение трассировок стека, но не уменьшает объём вычислительной работы и не отменяет управление нагрузкой. Модель «один поток на запрос» проще реактивной цепочки, но миграция должна учитывать библиотеки, пулы соединений и перенос контекста. Масштабируемое ожидание позволяет принять больше работы, поэтому без ограничения входной нагрузки система может быстрее перегрузить внешнюю зависимость. Масштабный тест должен быть ограничен ресурсами стенда, иначе измеряется авария генератора нагрузки, а не приложения.

Вопрос 25 из 30

Какой инженерный компромисс характерен для темы «Тестирование и диагностика» в разделе «Виртуальные потоки»?

Масштабный тест должен быть ограничен ресурсами стенда, иначе измеряется авария генератора нагрузки, а не приложения. Замена примитива может убрать конкретное ограничение, но длинная критическая секция и конкуренция за общий ресурс останутся. Модель упрощает наблюдение и чтение трассировок стека, но не уменьшает объём вычислительной работы и не отменяет управление нагрузкой. Виртуальные потоки повышают пропускную способность системы с большим числом операций, ожидающих ввода-вывода, но задержка удалённого сервиса остаётся прежней. Модель «один поток на запрос» проще реактивной цепочки, но миграция должна учитывать библиотеки, пулы соединений и перенос контекста.

Вопрос 26 из 30

Какой инженерный компромисс характерен для темы «Блокирующий ввод-вывод» в разделе «Виртуальные потоки»?

Масштабный тест должен быть ограничен ресурсами стенда, иначе измеряется авария генератора нагрузки, а не приложения. Автоматический тест может обнаруживать неограниченный рост, но точный размер объектов зависит от реализации виртуальной машины и не должен становиться хрупким утверждением. Модель «один поток на запрос» проще реактивной цепочки, но миграция должна учитывать библиотеки, пулы соединений и перенос контекста. Виртуальные потоки повышают пропускную способность системы с большим числом операций, ожидающих ввода-вывода, но задержка удалённого сервиса остаётся прежней. Модель упрощает наблюдение и чтение трассировок стека, но не уменьшает объём вычислительной работы и не отменяет управление нагрузкой.

Вопрос 27 из 30

Что важно учитывать при применении механизма «Модель выполнения» из раздела «Виртуальные потоки» в рабочем проекте?

Модель упрощает наблюдение и запись трассировок стека, но не уменьшает объём вычислительной работы и не отменяет управление нагрузкой. Модель упрощает наблюдение и чтение трассировок стека, но не увеличивает объём вычислительной работы и не отменяет управление нагрузкой. Модель упрощает наблюдение и чтение трассировок стека, но не уменьшает объём вычислительной работы и не отменяет управление нагрузкой. Увеличение -Xss помогает отдельной глубокой цепочке, но уменьшает допустимое число платформенных потоков. Модель «один поток на запрос» проще реактивной цепочки, но миграция должна учитывать библиотеки, пулы соединений и перенос контекста.

Вопрос 28 из 30

На какое правило следует опираться при разборе темы «Закрепление виртуальных потоков» в разделе «Виртуальные потоки»?

Устойчивый сервис оставляет запас памяти вне кучи, контролирует скорость выделения объектов и не работает постоянно у предела после каждой сборки. Начиная с JDK 23, ожидание внутри synchronized обычно не закрепляет виртуальный поток за потоком-носителем; нативные и некоторые критические участки всё ещё требуют наблюдения. Начиная с JDK 25, ожидание внутри synchronized обычно не закрепляет виртуальный поток за потоком-носителем; нативные и некоторые критические участки всё ещё требуют наблюдения. synchronized обеспечивает взаимное исключение и отношение happens-before между освобождением и последующим захватом того же монитора. Начиная с JDK 24, ожидание внутри synchronized обычно не закрепляет виртуальный поток за потоком-носителем; нативные и некоторые критические участки всё ещё требуют наблюдения.

Вопрос 29 из 30

Какое изменение сделает код по теме «Блокирующий ввод-вывод» в разделе «Виртуальные потоки» надёжнее?

// Фрагмент на ревью
Thread.startVirtualThread(() -> {
    var body = java.net.http.HttpClient.newHttpClient().send(
        request, java.net.http.HttpResponse.BodyHandlers.ofString());
    save(body.body());
});

Добавить ограниченный тестовый пул соединений, метрики ожидания и сценарий массовой отмены. Для вычислительного этапа использовать ограниченный исполнитель задач или структурированное разбиение с контролем параллелизма. Не хранить тяжёлый буфер в ThreadLocal виртуального потока: использовать локальный ограниченный буфер, пул с явным пределом или потоковую обработку. Писать прямой последовательный код и ограничивать внешние ресурсы семафорами или пулами, а не числом виртуальных потоков. Сохранять блокирующий стиль для I/O и отдельно ограничивать соединения, запросы и память.

Вопрос 30 из 30

Какое утверждение о механизме «Тестирование и диагностика» верно в контексте раздела «Виртуальные потоки»?

Большинство поддерживаемых блокирующих операций парковает виртуальный поток и освобождает поток-носитель для другой задачи. Виртуальный поток — обычный Thread для кода приложения, который JVM планирует поверх небольшого числа потоков-носителей. Ключевые метрики — число активных и ожидающих виртуальных потоков, занятость потоков-носителей, очередь внешнего ресурса и хвостовые задержки. Виртуальные потоки подходят для большого числа задач, которые преимущественно ждут ввод-вывод; вычислительную работу всё равно ограничивает число доступных ядер. Масштабирование с виртуальными потоками ограничивают внешние ресурсы и память на задачу; дешёвое ожидание не отменяет регулирование входной нагрузки.