JV Java · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Лёгкий ·

equals, hashCode и сравнение объектов

Проверяет основу темы «equals, hashCode и сравнение объектов» через чтение кода, предсказание результата и выбор корректной конструкции. Вопросы перемешаны: встречаются трассировка, ошибка компиляции, выбор правки, граничный сценарий и оценка инженерного компромисса. Базовая версия — Java 25 LTS; если версия не названа отдельно, используются устойчивые правила, совместимые с Java 21.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 20 вопросов отведено 55 минут. В каждом вопросе верен только один вариант; близкие ответы различаются стадией ошибки, порядком действий или границей контракта. После завершения вы увидите общий результат, результаты по 4 тематическим шкалам и объяснения.

Вопрос 1 из 20

Как точнее оценить пользу и цену решения по теме «Хеш-код» в разделе «equals, hashCode и сравнение объектов»?

Короткая реализация equals удобна, но неверно выбранная идентичность приводит к потере элементов в множестве и неожиданной замене ключей. Составной Comparator делает порядок детерминированным, но каждый дополнительный критерий увеличивает стоимость сравнения. Хеширование ускоряет средний поиск, но цена вычисления hashCode и распределение значений важны для горячего пути. Хеширование ускоряет средний поиск, но цена вычисления toString и распределение значений важны для горячего пути. Хеширование замедляет средний поиск, но цена вычисления hashCode и распределение значений важны для горячего пути.

Вопрос 2 из 20

Какой диагноз для кода по теме «Хеш-код» в разделе «equals, hashCode и сравнение объектов» будет точным?

class Key { int code;
  public boolean equals(Object o) { return o instanceof Key k && code == k.code; }
  public int hashCode() { return code; }
}
var key = new Key(); key.code = 1;
var map = new java.util.HashMap<Key,String>(); map.put(key,"v");
key.code = 2;
System.out.println(map.get(key));

После изменения key.code объект может стать недоступен через TreeMap по той же ссылке, потому что лежит в старой корзине. computeIfAbsent создаёт список один раз для ключа и добавляет значение в уже существующий список. Comparator только по длине считает строки «ab» и «cd» эквивалентными, поэтому TreeSet оставляет один элемент. После изменения key.code объект может стать недоступен через HashMap по той же ссылке, потому что лежит в старой корзине. Comparator по rank считает две записи с rank = 10 эквивалентными, поэтому TreeSet оставляет один элемент, несмотря на разные id.

Вопрос 3 из 20

Каков точный результат выполнения или компиляции фрагмента из раздела «equals, hashCode и сравнение объектов» по теме «Компараторы»?

var set = new java.util.TreeSet<String>(java.util.Comparator.comparingInt(String::length));
set.add("ab");
set.add("cd");
System.out.println(set.size());

Comparator только по длине считает строки «ab» и «cd» эквивалентными, поэтому TreeSet оставляет один элемент. Comparator только по длине считает строки «ab» и «cd» эквивалентными, поэтому HashSet оставляет один элемент. Если Comparator сравнивает только абсолютные значения, числа -3 и 3 считаются эквивалентными и одно из них не добавляется. Класс-запись record сравнивает все компоненты: объекты с одинаковым id, но разным name не равны, поэтому программа печатает false. Comparator по rank считает две записи с rank = 10 эквивалентными, поэтому TreeSet оставляет один элемент, несмотря на разные id.

Вопрос 4 из 20

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

record Item(int id, int rank) {}
var byRank = java.util.Comparator.comparingInt(Item::rank);
var set = new java.util.TreeSet<>(byRank);
set.add(new Item(1, 10));
set.add(new Item(2, 10));
System.out.println(set.size());

Два равных значения добавляются один раз, поэтому размер HashSet равен 1. Comparator по rank считает две записи с rank = 10 эквивалентными, поэтому TreeSet оставляет один элемент, несмотря на разные id. Comparator по rank считает две записи с rank = 11 эквивалентными, поэтому TreeSet оставляет один элемент, несмотря на разные id. Comparator только по длине считает строки «ab» и «cd» эквивалентными, поэтому TreeSet оставляет один элемент. Comparator по rank считает две записи с rank = 9 эквивалентными, поэтому TreeSet оставляет один элемент, несмотря на разные id.

Вопрос 5 из 20

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

// Фрагмент на ревью
var set = new java.util.TreeSet<String>(java.util.Comparator.comparingInt(String::length));
set.add("ab");
set.add("cd");
System.out.println(set.size());

Использовать неизменяемые ключи или исключить изменяемые поля из equals/hashCode. Обеспечить стабильные equals и hashCode у элементов и не менять поля, участвующие в равенстве, пока объект находится в множестве. Добавить вторичный критерий по исходному значению, если оба элемента должны сосуществовать. Выбрать устойчивые значимые поля и документировать, представляет ли класс сущность или значение. Добавить вторичный критерий thenComparing, если разные значения должны сохраняться.

Вопрос 6 из 20

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

Хеширование ускоряет средний поиск, но цена вычисления hashCode и распределение значений важны для горячего пути. Составной Comparator делает порядок детерминированным, но каждый дополнительный критерий увеличивает стоимость сравнения. Set выражает уникальность в модели, но выбор реализации определяет порядок, стоимость операций и требования к элементам. Comparator, не согласованный с equals, допустим, но его влияние на уникальность TreeSet надо сделать явным в контракте. Составной Comparator делает порядок детерминированным, но каждый дополнительный критерий уменьшает стоимость сравнения.

Вопрос 7 из 20

Какое утверждение о механизме «Хеш-код» верно в контексте раздела «equals, hashCode и сравнение объектов»?

Равные по == объекты обязаны иметь одинаковый hashCode, но одинаковый hashCode не делает объекты равными. Равные по equals объекты обязаны иметь одинаковый hashCode, но одинаковый hashCode не делает объекты равными. equals должен быть рефлексивным, симметричным, транзитивным, согласованным и возвращать false для null. Set хранит уникальные элементы согласно equals и hashCode либо результату Comparator для сортированного множества. TreeSet использует Comparator и для порядка, и для эквивалентности: compare(a, b) == 0 означает один элемент для множества.

Вопрос 8 из 20

Какая правка точнее всего устраняет причину проблемы по теме «Равенство» в разделе «equals, hashCode и сравнение объектов»?

// Фрагмент на ревью
record User(int id, String name) {}
var a = new User(1, "Ann");
var b = new User(1, "Bob");
System.out.println(a.equals(b));

Добавить вторичный критерий thenComparing, если разные значения должны сохраняться. Выбрать устойчивые значимые поля и документировать, представляет ли класс сущность или значение. Использовать неизменяемые ключи или исключить изменяемые поля из equals/hashCode. Обеспечить стабильные equals и hashCode у элементов и не менять поля, участвующие в равенстве, пока объект находится в множестве. Добавить вторичный критерий thenComparingInt(Item::id), если одинаковый rank не должен объединять разные элементы.

Вопрос 9 из 20

Почему после изменения rank поиск в TreeSet может перестать находить тот же объект?

final class Item {
    final int id;
    int rank;
    Item(int id, int rank) { this.id = id; this.rank = rank; }
}

var byRank = java.util.Comparator.comparingInt((Item x) -> x.rank);
var set = new java.util.TreeSet<Item>(byRank);
var item = new Item(1, 10);
set.add(item);
item.rank = 50;
System.out.println(set.contains(item));

contains сравнивает элементы только через equals и полностью игнорирует переданный Comparator. TreeSet автоматически удаляет элемент сразу после изменения поля, участвующего в сравнении. После изменения rank дерево не перестраивается: порядок Comparator нарушен, и поиск может не найти объект. Сбой вызван полем id: объявление final запрещает TreeSet повторно сравнивать объект. TreeSet сохраняет копию объекта, поэтому после изменения rank поиск идёт по старому экземпляру.

Вопрос 10 из 20

Что нужно отдельно проверить на границе контракта «Компараторы» в разделе «equals, hashCode и сравнение объектов»?

// Минимальный пример
var set = new java.util.TreeSet<String>(java.util.Comparator.comparingInt(String::length));
set.add("ab");
set.add("cd");
System.out.println(set.size());

HashSet не обещает порядок обхода, LinkedHashSet сохраняет порядок вставки, TreeSet — сортировку. Плохой hashCode ухудшает производительность, но корректность сохраняется, пока соблюдён контракт с equals. Comparator может быть не согласован с equals, но тогда поведение сортированных коллекций не требует особой осторожности. Comparator может быть не согласован с ==, но тогда поведение сортированных коллекций требует особой осторожности. Comparator может быть не согласован с equals, но тогда поведение сортированных коллекций требует особой осторожности.

Вопрос 11 из 20

Какое ограничение механизма «Равенство» нельзя упускать при работе с разделом «equals, hashCode и сравнение объектов»?

Comparator может быть не согласован с equals, но тогда поведение сортированных коллекций требует особой осторожности. Изменение поля, участвующего в Comparator, после вставки нарушает внутренний порядок и поиск. Наследование классов-значений часто ломает симметрию == между базовым и расширенным типом. Наследование классов-значений часто ломает симметрию equals между базовым и расширенным типом. equals у массива не сравнивает элементы; для этого нужны Arrays.equals или deepEquals.

Вопрос 12 из 20

Что следует изменить в разделе «equals, hashCode и сравнение объектов», чтобы сохранить замысел и соблюсти контракт «Хеш-код»?

// Фрагмент на ревью
class Key { int code;
  public boolean equals(Object o) { return o instanceof Key k && code == k.code; }
  public int hashCode() { return code; }
}
var key = new Key(); key.code = 1;
var map = new java.util.HashMap<Key,String>(); map.put(key,"v");
key.code = 2;
System.out.println(map.get(key));

Использовать неизменяемые ключи или исключить изменяемые поля из ==/hashCode. Использовать неизменяемые ключи или исключить изменяемые поля из equals/toString. Использовать неизменяемые ключи или исключить изменяемые поля из equals/hashCode. Выбрать устойчивые значимые поля и документировать, представляет ли класс сущность или значение. Использовать computeIfAbsent для инициализации изменяемого накопителя, не возвращая null из функции отображения.

Вопрос 13 из 20

Какое утверждение о механизме «Компараторы» верно в контексте раздела «equals, hashCode и сравнение объектов»?

TreeSet использует Comparator и для порядка, и для эквивалентности: compare(a, b) == 0 означает один элемент для множества. Comparator задаёт полный порядок и должен быть согласованным; нулевой результат означает эквивалентность для TreeSet и HashMap. Comparator задаёт полный порядок и должен быть согласованным; нулевой результат означает эквивалентность для HashSet и TreeMap. equals должен быть рефлексивным, симметричным, транзитивным, согласованным и возвращать false для null. Comparator задаёт полный порядок и должен быть согласованным; нулевой результат означает эквивалентность для TreeSet и TreeMap.

Вопрос 14 из 20

Какой диагноз для кода по теме «Равенство» в разделе «equals, hashCode и сравнение объектов» будет точным?

record User(int id, String name) {}
var a = new User(1, "Ann");
var b = new User(1, "Bob");
System.out.println(a.equals(b));

Класс-чтение record сравнивает все компоненты: объекты с одинаковым id, но разным name не равны, поэтому программа печатает false. Класс-запись record сравнивает все компоненты: объекты с одинаковым id, но разным name не равны, поэтому программа печатает true. Первое сравнение ложно, второе истинно: объекты разные, содержимое одинаковое. Класс-запись record сравнивает все компоненты: объекты с одинаковым id, но разным name не равны, поэтому программа печатает false. Comparator по rank считает две записи с rank = 10 эквивалентными, поэтому TreeSet оставляет один элемент, несмотря на разные id.

Вопрос 15 из 20

Что важно учитывать при применении механизма «Контракты коллекций» из раздела «equals, hashCode и сравнение объектов» в рабочем проекте?

Чем уже ограничение, тем больше операций доступно внутри метода, но тем меньше типов смогут его вызвать. Comparator, не согласованный с ==, допустим, но его влияние на уникальность TreeSet надо сделать явным в контракте. Составной Comparator делает порядок детерминированным, но каждый дополнительный критерий увеличивает стоимость сравнения. Comparator, не согласованный с equals, допустим, но его влияние на уникальность HashSet надо сделать явным в контракте. Comparator, не согласованный с equals, допустим, но его влияние на уникальность TreeSet надо сделать явным в контракте.

Вопрос 16 из 20

Какое замечание о сопровождении или производительности темы «Равенство» в разделе «equals, hashCode и сравнение объектов» справедливо?

Comparator, не согласованный с equals, допустим, но его влияние на уникальность TreeSet надо сделать явным в контракте. Хеширование ускоряет средний поиск, но цена вычисления hashCode и распределение значений важны для горячего пути. Короткая реализация == удобна, но неверно выбранная идентичность приводит к потере элементов в множестве и неожиданной замене ключей. Короткая реализация equals удобна, но неверно выбранная идентичность приводит к потере элементов в множестве и неожиданной замене ключей. Содержательное равенство делает объект-значение удобным ключом, но требует согласованного hashCode и ясного выбора значимых полей.

Вопрос 17 из 20

Что следует изменить в разделе «equals, hashCode и сравнение объектов», чтобы сохранить замысел и соблюсти контракт «Контракты коллекций»?

// Фрагмент на ревью
record Item(int id, int rank) {}
var byRank = java.util.Comparator.comparingInt(Item::rank);
var set = new java.util.TreeSet<>(byRank);
set.add(new Item(1, 10));
set.add(new Item(2, 10));
System.out.println(set.size());

Обеспечить стабильные equals и hashCode у элементов и не менять поля, участвующие в равенстве, пока объект находится в множестве. Добавить вторичный критерий thenComparingInt(Item::id), если одинаковый rank не должен объединять разные элементы. Использовать неизменяемые ключи или исключить изменяемые поля из equals/hashCode. Добавить вторичный критерий по исходному значению, если оба элемента должны сосуществовать. Выбрать устойчивые значимые поля и документировать, представляет ли класс сущность или значение.

Вопрос 18 из 20

Какое ограничение механизма «Хеш-код» нельзя упускать при работе с разделом «equals, hashCode и сравнение объектов»?

Плохой hashCode ухудшает производительность, но корректность сохраняется, пока соблюдён контракт с ==. Comparator может быть не согласован с equals, но тогда поведение сортированных коллекций требует особой осторожности. Плохой hashCode ухудшает производительность, но корректность сохраняется, пока соблюдён контракт с equals. HashMap допускает один null-ключ, но не является потокобезопасным для совместных изменений. Плохой toString ухудшает производительность, но корректность сохраняется, пока соблюдён контракт с equals.

Вопрос 19 из 20

На какое правило следует опираться при разборе темы «Контракты коллекций» в разделе «equals, hashCode и сравнение объектов»?

TreeSet использует Comparator и для порядка, и для эквивалентности: compare(a, b) == 1 означает один элемент для множества. Массив имеет фиксированную длину, хранит элементы одного совместимого типа и является ковариантным для ссылочных типов. TreeSet использует Comparator и для порядка, и для эквивалентности: compare(a, b) == 0 означает один элемент для множества. equals должен быть рефлексивным, симметричным, транзитивным, согласованным и возвращать false для null. TreeSet использует Comparator и для порядка, и для эквивалентности: compare(a, b) == -1 означает один элемент для множества.

Вопрос 20 из 20

Какое правило Java действует для темы «Равенство» в разделе «equals, hashCode и сравнение объектов»?

TreeSet использует Comparator и для порядка, и для эквивалентности: compare(a, b) == 0 означает один элемент для множества. equals должен быть рефлексивным, симметричным, транзитивным, согласованным и возвращать false для null. == должен быть рефлексивным, симметричным, транзитивным, согласованным и возвращать false для null. Comparator задаёт полный порядок и должен быть согласованным; нулевой результат означает эквивалентность для TreeSet и TreeMap. equals сравнивает содержание согласно контракту класса, а == для ссылок проверяет идентичность объектов.

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу