Почему изменяемые ключи в Map могут привести к ошибкам?

Почему изменяемые (mutable) ключи в Map приводят к ошибкам?

Это классический баг в Java, который очень сложно найти. Расскажу детально о механике, почему это опасно и как избежать.

Основная проблема: hashCode() меняется

// ПРОБЛЕМА: Map использует hashCode() для поиска

public class MutableKeyProblem {
    
    static class User {
        String email;
        
        User(String email) {
            this.email = email;
        }
        
        @Override
        public int hashCode() {
            return email.hashCode();  // Зависит от email!
        }
        
        @Override
        public boolean equals(Object obj) {
            if (!(obj instanceof User)) return false;
            User other = (User) obj;
            return this.email.equals(other.email);
        }
    }
    
    public static void main(String[] args) {
        Map<User, String> users = new HashMap<>();
        
        User user = new User("alice@example.com");
        users.put(user, "Alice");
        
        System.out.println("Before mutation:");
        System.out.println("users.get(user) = " + users.get(user));  // ✓ Alice
        System.out.println("Map contains: " + users);
        
        // МУТИРУЕМ ключ
        user.email = "bob@example.com";
        
        System.out.println("\nAfter mutation:");
        System.out.println("users.get(user) = " + users.get(user));  // ❌ null!
        System.out.println("user.hashCode() = " + user.hashCode());
        System.out.println("Map still contains: " + users);
        
        // ПОЧЕМУ?
        // 1. user.hashCode() изменился при смене email
        // 2. HashMap ищет в другом bucket'е
        // 3. Хотя данные в Map остались, их невозможно найти
    }
}

// OUTPUT:
// Before mutation:
// users.get(user) = Alice
// Map contains: {User@f4d5=Alice}
// 
// After mutation:
// users.get(user) = null
// user.hashCode() = 1234567  // Другое значение!
// Map still contains: {User@f4d5=Alice}

Как HashMap находит значения (внутренний механизм)

// ВНУТРИ HashMap:

public V get(Object key) {
    // Шаг 1: вычисляет hash код
    int hash = hash(key.hashCode());
    
    // Шаг 2: находит bucket по индексу (hash % table.length)
    int index = hash & (table.length - 1);
    
    // Шаг 3: ищет в цепочке (в старой Java) или красно-чёрном дереве
    Entry<K,V> entry = table[index];
    while (entry != null) {
        if (entry.hash == hash && entry.key.equals(key)) {
            return entry.value;  // ✓ Нашли!
        }
        entry = entry.next;
    }
    
    return null;  // Не нашли
}

// ПРОБЛЕМА с mutable ключами:
// 1. При put() key находится в bucket 5
// 2. Мутируем key (меняем hashCode)
// 3. При get() key ищется в bucket 12
// 4. HashCode не совпадает → не находится

User user = new User("alice");
int bucket1 = user.hashCode() % 16;  // bucket 5
map.put(user, "Alice");

user.email = "bob";
int bucket2 = user.hashCode() % 16;  // bucket 12 (другой!)
map.get(user);  // Ищет в bucket 12, но data в bucket 5 → не находит

Реальный пример: Collection becomes corrupted

public class CorruptedMapExample {
    
    static class Product implements Comparable<Product> {
        int id;
        String name;
        
        Product(int id, String name) {
            this.id = id;
            this.name = name;
        }
        
        @Override
        public int hashCode() {
            return Objects.hash(id, name);  // Зависит от id и name
        }
        
        @Override
        public boolean equals(Object obj) {
            if (!(obj instanceof Product)) return false;
            Product other = (Product) obj;
            return this.id == other.id && this.name.equals(other.name);
        }
        
        @Override
        public int compareTo(Product other) {
            return Integer.compare(this.id, other.id);
        }
    }
    
    public static void main(String[] args) {
        Map<Product, Integer> inventory = new HashMap<>();
        
        Product laptop = new Product(1, "Laptop");
        inventory.put(laptop, 10);  // 10 шт в наличии
        
        // Изменяем имя продукта
        laptop.name = "Gaming Laptop";
        
        // ПРОБЛЕМА: поиск не работает
        System.out.println(inventory.get(laptop));  // null
        System.out.println(inventory.size());  // 1
        System.out.println(inventory);  // {Product(1,Laptop)=10}
        
        // Из пользовательского кода неясно, что ключ там есть!
        // Может привести к логическим ошибкам
        
        // Сценарий: проверяем наличие товара
        if (!inventory.containsKey(laptop)) {
            // НЕПРАВИЛЬНО! inventory содержит laptop
            // Но из-за мутации не находится
            inventory.put(laptop, 15);  // Добавляем ещё один запись!
        }
        
        System.out.println("\nAfter put:");
        System.out.println(inventory);  // Два разных запроса о Gaming Laptop!
    }
}

Пример с TreeMap (тоже опасно)

public class MutableKeyInTreeMap {
    
    static class Person implements Comparable<Person> {
        String name;
        int age;
        
        Person(String name, int age) {
            this.name = name;
            this.age = age;
        }
        
        @Override
        public int compareTo(Person other) {
            return this.name.compareTo(other.name);  // Порядок от name
        }
        
        @Override
        public String toString() {
            return name + "(" + age + ")";
        }
    }
    
    public static void main(String[] args) {
        TreeMap<Person, String> people = new TreeMap<>();
        
        Person person = new Person("Alice", 25);
        people.put(person, "Engineer");  // Вставляется в правильное место
        
        System.out.println("Before mutation: " + people);
        
        // Мутируем ключ
        person.name = "Zoe";  // Изменяем значение, от которого зависит compareTo
        
        System.out.println("After mutation: " + people);
        System.out.println("Tree structure нарушена!");
        
        // Попытка получить значение
        System.out.println("people.get(person) = " + people.get(person));  // null
        
        // ПРОБЛЕМА: Red-Black дерево нарушено
        // Элемент находится в неправильном месте дерева
    }
}

Правильное решение: Immutable ключи

// ✅ ПРАВИЛЬНО: Immutable (неизменяемый) ключ

public final class ImmutableUser {
    private final String email;  // final
    private final String name;   // final
    
    public ImmutableUser(String email, String name) {
        this.email = email;
        this.name = name;
    }
    
    public String getEmail() {
        return email;  // Только getter, нет setter
    }
    
    public String getName() {
        return name;
    }
    
    @Override
    public int hashCode() {
        return Objects.hash(email, name);
    }
    
    @Override
    public boolean equals(Object obj) {
        if (!(obj instanceof ImmutableUser)) return false;
        ImmutableUser other = (ImmutableUser) obj;
        return this.email.equals(other.email) && this.name.equals(other.name);
    }
    
    // Если нужна модификация, создаём новый объект
    public ImmutableUser withEmail(String newEmail) {
        return new ImmutableUser(newEmail, this.name);
    }
}

// Использование:
public static void main(String[] args) {
    Map<ImmutableUser, String> users = new HashMap<>();
    
    ImmutableUser user = new ImmutableUser("alice@example.com", "Alice");
    users.put(user, "Engineer");
    
    System.out.println(users.get(user));  // ✓ Engineer
    
    // Чтобы изменить email, создаём новый объект
    ImmutableUser updatedUser = user.withEmail("bob@example.com");
    // updatedUser — другой объект
    // users.get(updatedUser) вернёт null (правильное поведение)
}

Альтернатива: Копировать ключи при put/get

public class SafeMapWrapper<K, V> {
    private Map<K, V> map = new HashMap<>();
    
    // Если K поддерживает Cloneable, копируем при добавлении
    public V put(K key, V value) {
        // Внимание: это сложно и не всегда работает
        // Лучше просто использовать immutable ключи
        return map.put(key, value);
    }
    
    public V get(K key) {
        return map.get(key);
    }
}

Проверка: когда ключ safe?

public class KeySafetyChecklist {
    
    // ✓ SAFE: Immutable классы
    class SafeKey1 {
        private final String value;
        private final int id;
        SafeKey1(String value, int id) {
            this.value = value;
            this.id = id;
        }
    }
    
    // ✓ SAFE: встроенные immutable типы
    Map<String, String> map1 = new HashMap<>();  // String immutable
    Map<Integer, String> map2 = new HashMap<>();  // Integer immutable
    Map<UUID, String> map3 = new HashMap<>();    // UUID immutable
    
    // ❌ UNSAFE: mutable ключи
    class UnsafeKey {
        String name;  // public и mutable
        int[] data;   // array, mutable
        List<String> tags;  // collection, mutable
        
        @Override
        public int hashCode() {
            return Objects.hash(name, Arrays.hashCode(data));
        }
    }
    
    // ❌ UNSAFE: Map как ключ
    Map<Map<String, String>, String> badMap = new HashMap<>();
    // Map mutable, hashCode меняется
    
    // ❌ UNSAFE: Date как ключ (хотя не final)
    Map<java.util.Date, String> badDate = new HashMap<>();
    // Date mutable
}

Практические выводы

public class BestPractices {
    
    // ПРАВИЛО 1: Ключи должны быть immutable
    // ✓ String, Integer, Long, UUID, BigDecimal
    // ✓ Собственные final классы
    // ❌ List, Map, Set, Date, StringBuilder
    
    // ПРАВИЛО 2: hashCode должен основываться только на immutable полях
    static class BadExample {
        String name;  // mutable
        int age;      // mutable
        
        @Override
        public int hashCode() {
            // ❌ Зависит от изменяемых полей
            return Objects.hash(name, age);
        }
    }
    
    static class GoodExample {
        final String email;  // immutable
        final UUID id;       // immutable
        String displayName;  // НЕ используется в hashCode
        
        @Override
        public int hashCode() {
            // ✓ Только от immutable полей
            return Objects.hash(email, id);
        }
    }
    
    // ПРАВИЛО 3: equals и hashCode должны быть согласованы
    // Если a.equals(b), то a.hashCode() == b.hashCode() ВСЕГДА
    
    // ПРАВИЛО 4: Используй final для полей в ключах
    static class SafeKey {
        private final String value;  // ✓ final
        private final int id;         // ✓ final
        
        SafeKey(String value, int id) {
            this.value = value;
            this.id = id;
        }
    }
}

Выводы

Почему mutable ключи опасны:

1. hashCode() меняется — элемент переходит в другой bucket
2. Поиск не работает — get() ищет в неправильном месте
3. TreeMap разрушается — Red-Black дерево нарушается
4. Тяжело найти баг — Map содержит данные, но они невидимы
5. Потеря данных — возможны дублирующиеся записи

Решение:

• ✓ Используй immutable классы как ключи (String, Integer, UUID)
• ✓ Создавай собственные final классы с final полями
• ✓ hashCode/equals от immutable полей только
• ✓ Если нужна модификация, создавай новый объект (builder pattern)

Это один из самых коварных багов в Java, потому что компилятор не предупредит и тесты могут пройти.