Раздел 8. Stream API и функциональный стиль в Java

Глава 5: Контракты. Почему equals, hashCode и иммутабельность — закон

equals/hashCode в операциях distinct, groupingBy, toSet

Stream API не существует в вакууме. Он опирается на фундаментальные контракты Java-объектов, установленные классом Object: equals для логического сравнения, hashCode для хеширования, compareTo для упорядочивания.

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

Рассмотрим класс Book, разработанный без должного внимания к контрактам:

public class Book {
    private final String title;
    private final String author;
    private final int year;
    
    // Конструктор, геттеры
    // equals и hashCode НЕ переопределены!
}

По умолчанию equals и hashCode наследуются от Object, реализуя идентичность по ссылке: два объекта равны только если это один и тот же экземпляр в памяти. Для доменной модели, где логическая эквивалентность определяется содержимым, это поведение некорректно.


groupingBy и распределение по бакетам

Коллектор groupingBy использует HashMap для организации групп. При добавлении элемента вычисляется хеш-код ключа, определяющий бакет (сегмент внутреннего массива HashMap). Если в бакете уже есть элементы, выполняется проверка equals для разрешения коллизий.

Проблема возникает при использовании ключа без корректного hashCode:

// Две логически идентичные книги
Book book1 = new Book("1984", "George Orwell", 1949);
Book book2 = new Book("1984", "George Orwell", 1949);

// Создаём поток с дублированием
List<Book> library = Arrays.asList(book1, book1, book2, book2);

// Группировка по книге как ключу
Map<Book, Long> countByBook = library.stream()
    .collect(groupingBy(Function.identity(), counting()));

System.out.println(countByBook.size());  // Ожидаем 1, получаем...?

Без переопределённого hashCode book1 и book2 имеют разные хеш-коды (по умолчанию System.identityHashCode), вычисляемые из адресов памяти. Они попадают в разные бакеты HashMap. Внутри каждого бакета equals возвращает false, потому что сравнение по ссылке даёт отрицательный результат. Результат: две записи в Map вместо одной, счётчики показывают 2 для каждой "уникальной" книги.

Баг проявляется недетерминированно. При небольшом числе элементов HashMap может поместить оба объекта в один бакет случайно (из-за пересечения хешей по модулю размера таблицы), и equals обнаружит их различность, но коллизия разрешится корректно — повезло. При росте данных таблица расширяется, бакеты становятся уже, вероятность коллизии падает, баг становится стабильным. При смене JVM (разная версия, разная реализация Object.hashCode) хеш-коды меняются, и поведение меняется без изменения кода.


distinct: фильтрация дубликатов без гарантий

Операция distinct() использует LinkedHashSet для отслеживания уникальных элементов. Она полагается на тот же контракт equals/hashCode:

List<Book> uniqueBooks = library.stream()
    .distinct()
    .collect(toList());

Без корректных методов distinct не удаляет логические дубликаты, только ссылочные. Если book1 и book2 — разные объекты с одинаковым содержимым, оба попадут в результат. Память растёт, кэширование не работает.

Особенно опасно это в распределённых системах: объект десериализуется в разных узлах, создавая разные экземпляры в памяти. Без equals/hashCode по значению они воспринимаются как разные сущности.


toSet и потеря элементов

Collectors.toSet() возвращает HashSet, основанный на хеш-таблице. Некорректный hashCode ведёт к дублированию:

Set<Book> bookSet = library.stream()
    .collect(toSet());

System.out.println(bookSet.size());  // Ожидаем 1, получаем 2

HashSet добавляет элемент, если в соответствующем бакете нет равного (по equals). Разные хеш-коды → разные бакеты → оба элемента добавлены. Множество перестаёт быть множеством.

#Java #для_новичков #beginner #stream_api #equals_hashCode

Иммутабельность ключей: бомба замедленного действия

Даже при корректных equals/hashCode опасность подстерегает в изменяемых ключах. Рассмотрим сценарий с составным ключом-автором:

public class Author {
    private String name;  // Не final! Сеттер есть!
    private String country;
    
    // equals и hashCode по всем полям
    @Override public int hashCode() {
        return Objects.hash(name, country);
    }
}

// Группировка книг по автору
Map<Author, List<Book>> byAuthor = library.stream()
    .collect(groupingBy(Book::author));

// Позже в коде...
Author key = byAuthor.keySet().iterator().next();
key.setName("Modified Name");  // Мутация ключа!

// Попытка доступа
List<Book> books = byAuthor.get(key);  // null?!

HashMap хранит ключ в бакете, соответствующем хеш-коду на момент вставки. При изменении полей name или country hashCode объекта меняется, но позиция в таблице — нет. get(key) вычисляет новый хеш, ищет в другом бакете, не находит совпадения, возвращает null. Данные не потеряны физически (объект Author и список Book существуют в памяти), но недоступны через Map.

Это "утечка" памяти логического характера: структура данных разрастается, но поиск перестаёт работать. Баг проявляется далеко от места мутации, диагностика требует глубокого понимания работы хеш-таблиц.


Правильная реализация контрактов

Для Book корректные equals и hashCode должны учитывать все значимые поля:

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    Book book = (Book) o;
    return year == book.year &&
           Objects.equals(title, book.title) &&
           Objects.equals(author, book.author);
}

@Override
public int hashCode() {
    return Objects.hash(title, author, year);
}

Ключевые требования к контракту:
Рефлексивность: x.equals(x) всегда true
Симметричность: x.equals(y) тогда и только тогда, когда y.equals(x)
Транзитивность: если x.equals(y) и y.equals(z), то x.equals(z)
Консистентность: многократные вызовы дают один результат (требует иммутабельности)
Согласованность с hashCode: равные объекты имеют равные хеш-коды
Последнее требование критично для HashMap/HashSet. Нарушение (equals true, но hashCode разный) делает коллекции неработоспособными.


Рекорды как решение

Java Records (14+, стабильно в 16+) автоматически генерируют корректные equals, hashCode, toString по всем компонентам, гарантируя иммутабельность:

public record Book(String title, String author, int year) {}

// Автоматически: final поля, конструктор, геттеры, equals, hashCode, toString

Использование records для ключей groupingBy, элементов distinct, элементов toSet устраняет класс ошибок, связанных с контрактами. Единственное ограничение: компоненты records также должны быть иммутабельными и с корректными контрактами. Если Author в Book — изменяемый класс, проблема сохраняется.


Диагностика в production

При подозрении на нарушение контрактов:
Логирование хеш-кодов: вывести System.identityHashCode(obj) и obj.hashCode() для "одинаковых" объектов. Различие указывает на проблему.
Проверка equals: убедиться, что obj1.equals(obj2) возвращает true для логически эквивалентных объектов.
Анализ мутаций: установить точки останова на сеттеры ключей, используемых в Map.
Использование LinkedHashMap/LinkedHashSet: сохраняют порядок вставки, облегчая отладку.

#Java #для_новичков #beginner #stream_api #equals_hashCode