Чем IdentityHashMap отличается от обычной HashMap?
Сколько элементов будет в мапе?

Map<String, String> map = new IdentityHashMap<>();
String s1 = "Java";
String s2 = new String("Java");
map.put(s1, "first");
map.put(s2, "second");
System.out.println(map.size());

🔍 Ответ на задачу про IdentityHashMap: Когда ссылки важнее значений 🔗

- HashMap использует equals() и hashCode() для сравнения ключей. Для "Java" и new String("Java") equals вернет true, поэтому в HashMap была бы 1 запись.

- IdentityHashMap использует оператор ==. Так как s1 и s2 — это разные объекты в памяти, мапа считает их разными ключами.

Вывод:
Размер мапы будет 2.

⚡️ Не перепутайте:
IdentityHashMap — редкий зверь. Она полезна, например, при сериализации графа объектов, чтобы не зациклиться, если два узла имеют одинаковое содержимое, но являются разными объектами.

#java #collections #hashmap #identityhashmap #internals #интервью #java_interview_tasks

Почему частый вызов MyEnum.values() в цикле — это плохая идея?
Что происходит "под капотом" при каждом вызове Color.values()?

enum Color { RED, GREEN, BLUE }

🔍 Ответ на задачу про Enum.values(): Скрытые аллокации 📦
Спецификация Java требует, чтобы массив, возвращаемый values(), был изменяемым (вы можете заменить в нем элементы, хотя это и плохая практика). Чтобы пользователи не могли испортить внутреннее состояние перечисления, компилятор генерирует код, который создает копию массива при каждом вызове values().

Вывод:
Каждый вызов values() — это новая аллокация памяти. В высокопроизводительном коде лучше кешировать этот массив: private static final Color[] VALUES = Color.values().

⚡️ Не перепутайте:
Если вам нужно просто получить количество элементов, используйте кешированное значение или Java 21 Enum.entries.

#java #enum #performance #jvm #memory #интервью #java_interview_tasks

Можно ли удалять элементы из списка во время обхода?
Какой код НЕ выбросит ConcurrentModificationException?

List<String> list = new ArrayList<>(Arrays.asList("A", "B", "C"));
// Вариант A
for (String s : list) {
        if (s.equals("A")) list.remove(s);
}
// Вариант B
Iterator<String> it = list.iterator();
while (it.hasNext()) {
        if (it.next().equals("A")) it.remove();
}

🔍 Ответ на задачу про Iterator.remove(): Чистим коллекцию правильно 🧹
- Вариант A (for-each) использует итератор неявно. Если мы вызываем list.remove() напрямую, итератор об этом не знает и при следующей проверке modCount выбросит ConcurrentModificationException.
- Вариант B использует iterator.remove(). Этот метод специально спроектирован для безопасного удаления текущего элемента во время итерации.

Вывод:
Верный вариант — B. (Хотя есть исключение: в ArrayList удаление предпоследнего элемента через list.remove() в for-each может не вызвать ошибку из-за бага/особенности проверки hasNext(), но полагаться на это нельзя).

⚡️ Не перепутайте:
В Java 8+ самый простой и безопасный способ: list.removeIf(s -> s.equals("A")).

#java #collections #iterator #bug #clean_code #интервью #java_interview_tasks

Как заставить мапу помнить, к каким элементам обращались чаще всего?
Что выведет этот код?

Map<Integer, String> map = new LinkedHashMap<>(16, 0.75f, true);
map.put(1, "A");
map.put(2, "B");
map.put(3, "C");
map.get(2); // Обращаемся к элементу 2
System.out.println(map.keySet());

🔍 Ответ на задачу про LinkedHashMap: Порядок имеет значение 🔄
У LinkedHashMap есть специальный конструктор, где третий аргумент accessOrder включает режим "порядка доступа". Если он равен true, то при каждом get() или put() элемент перемещается в конец списка. Это идеальная основа для реализации LRU-кеша (Least Recently Used).

Вывод:
Так как мы обратились к ключу 2, он переместился в конец. Порядок станет: 1, 3, 2.

⚡️ Не перепутайте:
По умолчанию LinkedHashMap сохраняет порядок вставки (accessOrder = false).

#java #collections #linkedhashmap #lru #cache #интервью #java_interview_tasks

Что будет, если вызвать приватный метод из родительского класса?
Что напечатает new Child().test()?

class Parent {
    public void test() { print(); }
    private void print() { System.out.print("Parent"); }
}
class Child extends Parent {
    public void print() { System.out.print("Child"); }
}

🔍 Ответ на задачу про Наследование: Приватные методы не переопределяются 🛡
Приватные методы в Java не участвуют в полиморфизме. Они принадлежат только тому классу, в котором объявлены, и не могут быть переопределены (override). Когда метод test() вызывается у объекта Child, он ищется в Parent. Внутри test() вызывается print(), который в Parent помечен как private. Java связывает этот вызов статически именно с методом в Parent.

Вывод:
Напечатается "Parent". Метод print() в Child — это просто новый метод, который никак не связан с приватным методом родителя.

⚡️ Не перепутайте:
Если вы хотите, чтобы метод переопределялся, он должен быть как минимум protected.

#java #oop #inheritance #polymorphism #basics #интервью #java_interview_tasks

Почему статические методы ведут себя не так, как обычные?
Что выведет код?

class A {
    static void staticMethod() { System.out.print("A"); }
}
class B extends A {
    static void staticMethod() { System.out.print("B"); }
}
A obj = new B();
obj.staticMethod();

🔍 Ответ на задачу про Static:

Статические методы привязаны к классу, а не к объекту. В Java нет полиморфизма для статики. Это называется method hiding. Какой метод вызовется, определяется типом переменной во время компиляции, а не типом объекта во время выполнения.

Вывод:
Так как переменная obj имеет тип A, вызовется A.staticMethod(). Результат: "A".

⚡️ Не перепутайте:
Никогда не вызывайте статические методы через экземпляры объектов (obj.method()). Всегда пишите ClassName.method(), чтобы не вводить в заблуждение.

#java #static #inheritance #basics #clean_code #интервью #java_interview_tasks

Гарантирует ли final, что другой поток увидит значение поля?
Может ли другой поток увидеть p.x == 0, если объект p был создан как p = new Point(5)?

class Point {
    final int x;
    Point(int val) { this.x = val; ... }
}

🔍 Ответ на задачу про Final поля: Безопасная публикация 🏗

Согласно JMM, поля final обеспечивают "гарантию заморозки". Если объект был правильно сконструирован (ссылка this не утекла во время работы конструктора), то любой поток, увидевший ссылку на этот объект, гарантированно увидит корректные значения всех его final полей.

Вывод:
При условии отсутствия "утечки" this в конструкторе , после создания объекта другой тред увидеть не может ничего кроме 5. Это одна из основ создания Immutable объектов в Java.

⚡️ Не перепутайте:
Обычные (не final) поля без синхронизации могут быть видны другим потокам в их дефолтном состоянии (например, 0 или null), даже если конструктор уже отработал.

#java #concurrency #jmm #final #multithreading #интервью #java_interview_tasks