Блокировки и конкурентные коллекции — бесплатный тест онлайн

Вопрос 1 из 30

Какое утверждение о механизме «Условия ожидания» верно в контексте раздела «Блокировки и конкурентные коллекции»?

Condition.await надо вызывать в цикле, повторно проверяющем предикат, потому что возможны ложные пробуждения и конкуренция. Atomic-классы дают атомарные операции над одним значением и compare-and-set, но не защищают произвольный составной инвариант. Для блокировок нужны тесты таймаутов, отмены, исключений внутри критической секции и инвариантов под конкуренцией. Lock позволяет tryLock, прерываемое ожидание и несколько Condition, но требует unlock в finally. Конкуренция за блокировку, длина критической секции и ложное совместное использование памяти важнее названия примитива синхронизации.

Вопрос 2 из 30

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

var used = new java.util.concurrent.atomic.AtomicInteger();
var limit = new java.util.concurrent.atomic.AtomicInteger(10);
if (used.get() < limit.get()) used.incrementAndGet();

Одна глобальная блокировка вокруг независимых ключей превращает ConcurrentHashMap в последовательный компонент. Проверка used < limit и последующий incrementAndGet не образуют одну атомарную операцию; несколько потоков могут одновременно пройти проверку и превысить limit. Если debit() выбросит исключение, completed останется false и finally не освободит lock; следующий поток может зависнуть навсегда. Если risky() выбросит исключение, блокировка останется захваченной и последующие потоки могут зависнуть. Последовательность containsKey затем put не атомарна и может дважды создать дорогой объект.

Вопрос 3 из 30

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

Явная блокировка даёт больше управления, но повышает риск забыть освобождение и усложняет анализ путей выполнения. Condition разделяет очереди ожидания по смыслу, но ошибочная связь предиката и блокировки создаёт редкие зависания. Стресс-тесты находят редкие чередования, а формальный разбор владельца состояния нужен для доказательства корректности. Condition разделяет очереди ожидания по смыслу, но ошибочная связь предиката и блокировки не создаёт редкие зависания. Атомарность по ключу снижает блокировки, но операции сразу над несколькими ключами требуют отдельного протокола.

Вопрос 4 из 30

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

// Фрагмент на ревью
if (!cache.containsKey(key)) {
    cache.put(key, loadExpensive(key));
}
return cache.get(key);

Обернуть await в while (queue.isEmpty()) и менять состояние под той же блокировкой. Сузить область защиты до ключа или сегмента и измерить 95-й и 99-й процентили времени ожидания. Объединить связанные поля в неизменяемый снимок внутри AtomicReference и обновлять его циклом compare-and-set либо использовать блокировку. Использовать computeIfAbsent с короткой, не рекурсивной и безопасной функцией. Поместить unlock в finally сразу после успешного lock.

Вопрос 5 из 30

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

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

Вопрос 6 из 30

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

Lock позволяет tryLock, прерываемое ожидание и несколько Condition, но требует unlock в finally. Для блокировок нужны тесты таймаутов, отмены, исключений внутри критической секции и инвариантов под конкуренцией. Condition.await надо вызывать в цикле, повторно проверяющем предикат, потому что возможны ложные пробуждения и конкуренция. ConcurrentHashMap поддерживает конкурентные операции и атомарные compute/merge для одного ключа. Конкуренция за блокировку, длина критической секции и ложное совместное использование памяти важнее названия примитива синхронизации.

Вопрос 7 из 30

Как поведёт себя фрагмент по теме «Условия ожидания» при разборе раздела «Блокировки и конкурентные коллекции»?

lock.lock();
try {
    if (queue.isEmpty()) notEmpty.await();
    return queue.removeFirst();
} finally { lock.unlock(); }

Последовательность containsKey затем put не атомарна и может дважды создать дорогой объект. Если debit() выбросит исключение, completed останется false и finally не освободит lock; следующий поток может зависнуть навсегда. Если risky() выбросит исключение, блокировка останется захваченной и последующие потоки могут зависнуть. Одна глобальная блокировка вокруг независимых ключей превращает ConcurrentHashMap в последовательный компонент. После signal поток может проснуться, когда очередь снова пуста, и removeFirst завершится ошибкой.

Вопрос 8 из 30

Какое утверждение о механизме «Атомарные операции» верно в контексте раздела «Блокировки и конкурентные коллекции»?

Atomic-классы дают атомарные операции над одним индексом и compare-and-set, но не защищают произвольный составной инвариант. Condition.await надо вызывать в цикле, повторно проверяющем предикат, потому что возможны ложные пробуждения и конкуренция. Atomic-классы дают атомарные операции над одним значением и compare-and-set, но не защищают произвольный составной инвариант. exceptionally восстанавливает значение после ошибки, handle видит и результат, и исключение, whenComplete обычно наблюдает без замены. Частые операции рефлексии стоит кэшировать только после измерения и без удержания загрузчика классов дольше жизненного цикла приложения или плагина.

Вопрос 9 из 30

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

synchronized (globalLock) {
    cache.computeIfAbsent(userId, this::load);
}

Одна глобальная блокировка вокруг независимых ключей превращает ConcurrentHashMap в последовательный компонент. Одна глобальная блокировка вокруг независимых ключей превращает ConcurrentHashMap в параллельный компонент. Одна глобальная блокировка вокруг независимых ключей превращает ConcurrentTreeMap в последовательный компонент. Если risky() выбросит исключение, блокировка останется захваченной и последующие потоки могут зависнуть. Два потока могут прочитать одно value и записать одинаковый увеличенный результат, потеряв одно обновление.

Вопрос 10 из 30

Что важно учитывать при применении механизма «Тестирование и диагностика» из раздела «Блокировки и конкурентные коллекции» в рабочем проекте?

Стресс-тесты находят редкие чередования, а формальный разбор владельца состояния нужен для доказательства корректности. Оптимизация оправданна после профилирования: неблокирующая структура может проиграть простой блокировке при низкой конкуренции. Condition разделяет очереди ожидания по смыслу, но ошибочная связь предиката и блокировки создаёт редкие зависания. Явная блокировка даёт больше управления, но повышает риск забыть освобождение и усложняет анализ путей выполнения. Неблокирующее обновление хорошо масштабируется при малом конфликте, но при сильной конкуренции циклы compare-and-set тратят процессор.

Вопрос 11 из 30

Что нужно отдельно проверить на границе контракта «Производительность и эксплуатация» в разделе «Блокировки и конкурентные коллекции»?

// Минимальный пример
synchronized (globalLock) {
    cache.computeIfAbsent(userId, this::load);
}

signal будит один ожидающий поток, signalAll — всех; выбор зависит от того, какие предикаты могли стать истинными. Снимок потоков показывает владельца и ожидающих, но не объясняет предметный предикат, из-за которого ожидание стало вечным. ReentrantLock не гарантирует справедливость по умолчанию; fair-режим уменьшает голодание ценой пропускной способности. Больше блокировок повышает параллелизм, но усложняет порядок захвата и риск взаимной блокировки. Итераторы слабосогласованные: они не выбрасывают ConcurrentModificationException и могут отражать лишь часть текущих изменений.

Вопрос 12 из 30

Какой граничный случай особенно важен для темы «Явные блокировки» в разделе «Блокировки и конкурентные коллекции»?

// Минимальный пример
var lock = new java.util.concurrent.locks.ReentrantLock();
lock.lock();
risky();
lock.unlock();

Отсутствие сбоя в тысяче запусков не доказывает отсутствие гонки; полезны jcstress, анализ happens-before и профилирование. Увеличение кучи уменьшает частоту сборок, но может продлить некоторые циклы и скрыть утечку до более позднего момента. ReentrantLock не гарантирует справедливость по умолчанию; fair-режим уменьшает голодание ценой пропускной способности. CompletionException может оборачивать исходную ошибку; при диагностике надо раскрывать cause. thenApplyAsync без явно переданного исполнителя обычно использует общий пул ForkJoinPool, что нежелательно для блокирующей работы.

Вопрос 13 из 30

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

// Минимальный пример
if (!cache.containsKey(key)) {
    cache.put(key, loadExpensive(key));
}
return cache.get(key);

Больше блокировок повышает параллелизм, но усложняет порядок захвата и риск взаимной блокировки. Атомарность по ключу снижает блокировки, но операции сразу над несколькими ключами требуют отдельного протокола. ReentrantLock не гарантирует справедливость по умолчанию; fair-режим уменьшает голодание ценой пропускной способности. weakCompareAndSet может допускать ложный отказ и требует цикла повторения. Итераторы слабосогласованные: они не выбрасывают ConcurrentModificationException и могут отражать лишь часть текущих изменений.

Вопрос 14 из 30

Что следует изменить в разделе «Блокировки и конкурентные коллекции», чтобы сохранить замысел и соблюсти контракт «Условия ожидания»?

// Фрагмент на ревью
lock.lock();
try {
    if (queue.isEmpty()) notEmpty.await();
    return queue.removeFirst();
} finally { lock.unlock(); }

Поместить unlock в finally сразу после успешного lock. Обернуть await в while (queue.isEmpty()) и менять состояние под той же блокировкой. Вызывать lock.unlock() безусловно в finally, а затем добавить тест с управляемым исключением и ограниченным ожиданием второго потока. Сузить область защиты до ключа или сегмента и измерить 95-й и 99-й процентили времени ожидания. Использовать computeIfAbsent с короткой, не рекурсивной и безопасной функцией.

Вопрос 15 из 30

Что следует изменить в разделе «Блокировки и конкурентные коллекции», чтобы сохранить замысел и соблюсти контракт «Производительность и эксплуатация»?

// Фрагмент на ревью
synchronized (globalLock) {
    cache.computeIfAbsent(userId, this::load);
}

Обернуть await в while (queue.isEmpty()) и менять состояние под той же блокировкой. Сузить область защиты до ключа или сегмента и измерить 96-й и 99-й процентили времени ожидания. Использовать computeIfAbsent с короткой, не рекурсивной и безопасной функцией. Сузить область защиты до ключа или сегмента и измерить 95-й и 99-й процентили времени ожидания. Сузить область защиты до ключа или сегмента и измерить 94-й и 99-й процентили времени ожидания.

Вопрос 16 из 30

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

Condition разделяет очереди ожидания по смыслу, но ошибочная связь предиката и блокировки создаёт редкие зависания. Atomic-классы дают атомарные операции над одним значением и compare-and-set, но не защищают произвольный составной инвариант. ConcurrentHashMap поддерживает конкурентные операции и атомарные compute/merge для одного ключа. ReentrantLock не гарантирует справедливость по умолчанию; fair-режим уменьшает голодание ценой пропускной способности. ConcurrentTreeMap поддерживает конкурентные операции и атомарные compute/merge для одного ключа.

Вопрос 17 из 30

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

lock.lock();
boolean completed = false;
try {
    balance -= debit(); // debit может бросить исключение
    completed = true;
} finally {
    if (completed) lock.unlock();
}

Проверка used < limit и последующий incrementAndGet не образуют одну атомарную операцию; несколько потоков могут одновременно пройти проверку и превысить limit. Если debit() выбросит исключение, completed останется true и finally не освободит lock; следующий поток может зависнуть навсегда. Если risky() выбросит исключение, блокировка останется захваченной и последующие потоки могут зависнуть. После signal поток может проснуться, когда очередь снова пуста, и removeFirst завершится ошибкой. Если debit() выбросит исключение, completed останется false и finally не освободит lock; следующий поток может зависнуть навсегда.

Вопрос 18 из 30

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

// Фрагмент на ревью
var lock = new java.util.concurrent.locks.ReentrantLock();
lock.lock();
risky();
lock.unlock();

Поместить unlock в finally сразу после успешного lock. Вызывать lock.unlock() безусловно в finally, а затем добавить тест с управляемым исключением и ограниченным ожиданием второго потока. Объединить связанные поля в неизменяемый снимок внутри AtomicReference и обновлять его циклом compare-and-set либо использовать блокировку. Сузить область защиты до ключа или сегмента и измерить 95-й и 99-й процентили времени ожидания. Обернуть await в while (queue.isEmpty()) и менять состояние под той же блокировкой.

Вопрос 19 из 30

Какое правило Java действует для темы «Тестирование и диагностика» в разделе «Блокировки и конкурентные коллекции»?

Конкуренция за блокировку, длина критической секции и ложное совместное использование памяти важнее названия примитива синхронизации. ConcurrentHashMap поддерживает конкурентные операции и атомарные compute/merge для одного ключа. Для блокировок нужны тесты таймаутов, отмены, исключений внутри критической секции и инвариантов под конкуренцией. Lock позволяет tryLock, прерываемое ожидание и несколько Condition, но требует unlock в finally. Atomic-классы дают атомарные операции над одним значением и compare-and-set, но не защищают произвольный составной инвариант.

Вопрос 20 из 30

Какое изменение сделает код по теме «Атомарные операции» в разделе «Блокировки и конкурентные коллекции» надёжнее?

// Фрагмент на ревью
var used = new java.util.concurrent.atomic.AtomicInteger();
var limit = new java.util.concurrent.atomic.AtomicInteger(10);
if (used.get() < limit.get()) used.incrementAndGet();

Объединить связанные поля в ненеизменяемый снимок внутри AtomicReference и обновлять его циклом compare-and-set либо использовать блокировку. Использовать computeIfAbsent с короткой, не рекурсивной и безопасной функцией. Объединить связанные поля в неизменяемый снимок внутри AtomicReference и обновлять его циклом compare-and-set либо использовать блокировку. Вызывать lock.unlock() безусловно в finally, а затем добавить тест с управляемым исключением и ограниченным ожиданием второго потока. Объединить связанные поля в изменяемый снимок внутри AtomicReference и обновлять его циклом compare-and-set либо использовать блокировку.

Вопрос 21 из 30

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

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

Вопрос 22 из 30

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

Модель упрощает наблюдение и чтение трассировок стека, но не уменьшает объём вычислительной работы и не отменяет управление нагрузкой. Стресс-тесты находят редкие чередования, а формальный разбор владельца состояния нужен для доказательства корректности. Единая запасная ветвь повышает доступность, но может скрыть деградацию, если не добавить метрику и ограничение области восстановления. Масштабируемое ожидание позволяет принять больше работы, поэтому без ограничения входной нагрузки система может быстрее перегрузить внешнюю зависимость. Неблокирующее обновление хорошо масштабируется при малом конфликте, но при сильной конкуренции циклы compare-and-set тратят процессор.

Вопрос 23 из 30

Что произойдёт с кодом по теме «Явные блокировки» в разделе «Блокировки и конкурентные коллекции»?

var lock = new java.util.concurrent.locks.ReentrantLock();
lock.lock();
risky();
lock.unlock();

Если debit() выбросит исключение, completed останется false и finally не освободит lock; следующий поток может зависнуть навсегда. Если risky() выбросит исключение, блокировка останется захваченной и последующие потоки могут зависнуть. После signal поток может проснуться, когда очередь снова пуста, и removeFirst завершится ошибкой. cancel(true) только запрашивает прерывание; задача остановится, если корректно реагирует на interrupt. Одна глобальная блокировка вокруг независимых ключей превращает ConcurrentHashMap в последовательный компонент.

Вопрос 24 из 30

Какое правило Java действует для темы «Явные блокировки» в разделе «Блокировки и конкурентные коллекции»?

Future.get блокирует до результата и передаёт ошибку задачи внутри ExecutionException. Lock позволяет tryLock, прерываемое ожидание и несколько Condition, но требует unlock в finally. Condition.await надо вызывать в цикле, повторно проверяющем предикат, потому что возможны ложные пробуждения и конкуренция. Lock позволяет tryLock, прерываемое ожидание и несколько Condition, но не требует unlock в finally. Lock не позволяет tryLock, прерываемое ожидание и несколько Condition, но требует unlock в finally.

Вопрос 25 из 30

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

// Фрагмент на ревью
lock.lock();
boolean completed = false;
try {
    balance -= debit(); // debit может бросить исключение
    completed = true;
} finally {
    if (completed) lock.unlock();
}

Передать отдельный исполнитель задач и завершать его в finally; для ограничений времени использовать управляемые средства. Сузить область защиты до ключа или сегмента и измерить 95-й и 99-й процентили времени ожидания. Поместить unlock в finally сразу после успешного lock. Обернуть await в while (queue.isEmpty()) и менять состояние под той же блокировкой. Вызывать lock.unlock() безусловно в finally, а затем добавить тест с управляемым исключением и ограниченным ожиданием второго потока.

Вопрос 26 из 30

Какое важное ограничение есть у такого снимка потоков при расследовании зависания?

"consumer-17" #84 WAITING
  at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(...)
  at Queue.take(Queue.java:47)

"producer-3" #19 RUNNABLE
  at Queue.publish(Queue.java:81)

RUNNABLE означает, что поток непрерывно выполнялся на процессоре всё время расследования. Состояние WAITING означает, что поток обязательно находится во взаимной блокировке. Снимок показывает владельцев и ожидающих, но не объясняет предметное условие и историю событий, из-за которых ожидание стало вечным. По одному снимку всегда можно доказать точную последовательность всех предыдущих операций. ConditionObject.await не отображается в снимках потоков.

Вопрос 27 из 30

Что произойдёт с кодом по теме «Конкурентная карта ConcurrentHashMap» в разделе «Блокировки и конкурентные коллекции»?

if (!cache.containsKey(key)) {
    cache.put(key, loadExpensive(key));
}
return cache.get(key);

Одна глобальная блокировка вокруг независимых ключей превращает ConcurrentHashMap в последовательный компонент. Последовательность containsKey затем put не атомарна и может дважды создать дорогой объект. После signal поток может проснуться, когда очередь снова пуста, и removeFirst завершится ошибкой. Проверка used < limit и последующий incrementAndGet не образуют одну атомарную операцию; несколько потоков могут одновременно пройти проверку и превысить limit. Если risky() выбросит исключение, блокировка останется захваченной и последующие потоки могут зависнуть.

Вопрос 28 из 30

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

Атомарность по ключу снижает блокировки, но операции сразу над несколькими ключами требуют отдельного протокола. Явная блокировка даёт больше управления, но повышает риск забыть освобождение и усложняет анализ путей выполнения. Неблокирующее обновление хорошо масштабируется при малом конфликте, но при сильной конкуренции циклы compare-and-set тратят процессор. Оптимизация оправданна после профилирования: неблокирующая структура может проиграть простой блокировке при низкой конкуренции. Стресс-тесты находят редкие чередования, а формальный разбор владельца состояния нужен для доказательства корректности.

Вопрос 29 из 30

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

// ...
try {
    if (queue.isEmpty()) notEmpty.await();
    return queue.removeFirst();
} finally { lock.unlock(); }

ReentrantLock не гарантирует справедливость по умолчанию; fair-режим уменьшает голодание ценой пропускной способности. Снимок потоков показывает владельца и ожидающих, но не объясняет предметный предикат, из-за которого ожидание стало вечным. Блокирующий нативный вызов или неподдерживаемая операция может удерживать поток-носитель дольше ожидаемого. signal будит один ожидающий поток, signalAll — всех; выбор зависит от того, какие предикаты могли стать истинными. Больше блокировок повышает параллелизм, но усложняет порядок захвата и риск взаимной блокировки.

Вопрос 30 из 30

Что нужно отдельно проверить на границе контракта «Атомарные операции» в разделе «Блокировки и конкурентные коллекции»?

// Минимальный пример
var used = new java.util.concurrent.atomic.AtomicInteger();
var limit = new java.util.concurrent.atomic.AtomicInteger(10);
if (used.get() < limit.get()) used.incrementAndGet();

Вызов System.gc не разрывает ссылки и не исправляет логическую утечку. weakCompareAndSet может избегать ложный отказ и требует цикла повторения. weakCompareAndSet может допускать ложный отказ и требует цикла повторения. isDone истинно и для успешной, и для упавшей, и для отменённой задачи. weakCompareAndSet может допускать ложный отказ и не требует цикла повторения.