РЕАЛЬНОЕ СОБЕСЕДОВАНИЕ Java разработчик ylab - Junior

18 августа 2025 г. · 92 мин. чтения

Сегодня мы разберем техническое собеседование Java-разработчика, в котором кандидат показывает уверенные базовые знания по Java, коллекциям, многопоточности, SQL, Hibernate и Spring, но периодически путается в деталях и формулировках. Интервьюер мягко направляет, уточняет ключевые моменты и дополняет ответы, превращая беседу не только в оценку уровня, но и в обучающую дискуссию, близкую по атмосфере к менторской сессии.

Вопрос 1. Какой класс является базовым предком всех объектов в Java?

Таймкод: 00:02:40

Ответ собеседника: правильный. Все объекты наследуются от класса Object.

Правильный ответ:
В Java все классы (кроме примитивных типов) напрямую или косвенно наследуются от класса java.lang.Object. Это фундамент корневой иерархии типов в языке.

Ключевые моменты о Object:

Он находится в пакете java.lang и импортируется автоматически.
Если при объявлении класса явно не указать extends, компилятор неявно добавит extends Object.

Основные методы Object, которые определяют базовое поведение всех объектов:

toString()
Возвращает строковое представление объекта. По умолчанию: ИмяКласса@hexHashCode.
Обычно переопределяется для удобного логирования и отладки.
equals(Object obj)
По умолчанию сравнивает ссылки (т.е. идентичность объектов).
Переопределяется для логического сравнения по полям. При переопределении equals важно также переопределить hashCode.
hashCode()
Возвращает числовой хеш-код объекта.
Контракт:
- равные по equals объекты обязаны иметь одинаковый hashCode;
- используется в HashMap, HashSet и других хеш-коллекциях.
getClass()
Возвращает объект Class, описывающий тип объекта (reflection).
clone()
Предназначен для поверхностного копирования объекта.
По умолчанию бросает CloneNotSupportedException, если класс не реализует Cloneable. Используется редко, в продакшене чаще применяют паттерны копирования или отдельные мапперы.
finalize() (устаревший)
Раньше использовался для выполнения действий перед сборкой мусора. Сейчас помечен как deprecated, использовать не рекомендуется.
Методы для многопоточности:
- wait(), notify(), notifyAll() — механизм координации потоков на основе монитора объекта.
  Применяются внутри синхронизированных блоков/методов:
```
synchronized (lock) {
    while (!condition) {
        lock.wait();
    }
}
```

Понимание роли Object важно:

для корректного переопределения equals/hashCode и работы коллекций;
для использования Reflection API;
для разработки многопоточных решений с низкоуровневой синхронизацией;
для осознания корневой модели типов в JVM (включая массивы, которые тоже наследуются от Object).

Вопрос 2. Какие ключевые методы определены в классе Object?

Таймкод: 00:02:46

Ответ собеседника: неполный. Перечислил equals, toString, clone и методы notify/notifyAll/wait, но не совсем точно и не охватил все важные методы.

Правильный ответ:
Класс java.lang.Object задает базовый интерфейс поведения для всех объектов в Java. Важные методы Object нужно знать не просто по списку, а понимать их контракт и влияние на поведение коллекций, многопоточность и модель объектов.

Основные методы:

public String toString()
- Назначение: человекочитаемое строковое представление объекта.
- Реализация по умолчанию: ИмяКласса@hexHashCode.
- Практика:
  - почти всегда переопределяется для удобного логирования и отладки;
  - не должен "ломать" объект, не кидать неожиданные исключения.
- Пример:
```
@Override
public String toString() {
    return "User{id=" + id + ", name='" + name + "'}";
}
```
public boolean equals(Object obj)
- По умолчанию: сравнение по ссылке (this == obj).
- Переопределяется для логического сравнения сущностей по значимым полям.
- Важен контракт:
  - рефлексивность, симметричность, транзитивность, консистентность;
  - x.equals(null) всегда false.
- При переопределении equals обязательно согласовать с hashCode.
- Пример:
```
@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    User user = (User) o;
    return id == user.id;
}
```
public int hashCode()
- Используется в хеш-структурах (HashMap, HashSet, ConcurrentHashMap и т.д.).
- Контракт (критически важно знать):
  - если x.equals(y) == true, то x.hashCode() == y.hashCode();
  - одинаковый хеш не гарантирует равенство, но разные объекты могут иметь один хеш.
- Плохая реализация hashCode ломает работу коллекций (баги, деградация до O(n)).
- Пример:
```
@Override
public int hashCode() {
    return Long.hashCode(id);
}
```
public final Class<?> getClass()
- Возвращает рантайм-тип объекта.
- Используется в рефлексии, логировании, фреймворках.
- Нельзя переопределить.
- Пример:
```
Class<?> clazz = obj.getClass();
```
protected Object clone() throws CloneNotSupportedException
- Предназначен для поверхностного копирования объекта.
- По умолчанию: бросает CloneNotSupportedException, если класс не реализует Cloneable.
- Проблемный API (поверхностная копия, checked-исключение, неудобный контракт), в продакшене обычно предпочитают:
  - конструкторы копирования,
  - статические фабрики,
  - мапперы, библиотечные решения.
- Пример:
```
public class User implements Cloneable {
    @Override
    protected Object clone() throws CloneNotSupportedException {
        return super.clone(); // поверхностная копия
    }
}
```
protected void finalize() throws Throwable (устаревший)
- Исторически: вызывался перед сборкой мусора для очистки ресурсов.
- Проблемы:
  - непредсказуемый момент вызова;
  - может никогда не быть вызван;
  - негативно влияет на GC и производительность.
- Сейчас помечен как deprecated; корректный подход:
  - try-with-resources,
  - явное закрытие ресурсов,
  - Cleaner/PhantomReference в редких случаях.
Методы для межпоточной координации (мониторы):
- public final void wait() throws InterruptedException
- public final void wait(long timeout) throws InterruptedException
- public final void wait(long timeout, int nanos) throws InterruptedException
- public final void notify()
- public final void notifyAll()
Ключевые моменты:
- Работают с монитором объекта.
- Могут вызываться только внутри блока/метода synchronized по этому же объекту, иначе IllegalMonitorStateException.
- wait():
  - отпускание монитора и переход потока в состояние ожидания;
  - обычно вызывается в цикле while с проверкой условия (spurious wakeups).
- notify():
  - будит один случайный поток, ожидающий на данном мониторе.
- notifyAll():
  - будит все ожидающие потоки, они снова соревнуются за монитор.
- Пример:
```
synchronized (lock) {
    while (!condition) {
        lock.wait();
    }
    // условие выполнено
}

synchronized (lock) {
    condition = true;
    lock.notifyAll();
}
```

Почему это важно понимать:

equals/hashCode — основа корректной работы коллекций и кэшей.
toString — диагностика, логирование, читаемость.
wait/notify/notifyAll — фундамент низкоуровневой синхронизации (даже если сейчас чаще используют java.util.concurrent).
getClass и рефлексия — базис работы фреймворков, ORM, DI-контейнеров.

Этот набор методов формирует минимальный контракт поведения любого объектного типа в Java.

Вопрос 3. Что возвращает метод hashCode и как он связан с объектом?

Таймкод: 00:03:15

Ответ собеседника: правильный. Метод возвращает целое число, реализация зависит от класса; значение должно различать объекты на основе значимых полей. Упомянута специфика JPA-сущностей и прокси.

Правильный ответ:
Метод hashCode() возвращает целое число (int), представляющее хеш-код объекта, используемое для эффективного размещения и поиска объектов в хеш-структурах данных (например, HashMap, HashSet, ConcurrentHashMap). Это не "id объекта" и не гарантированно адрес в памяти, а детерминированная функция от внутреннего состояния объекта (в рамках одного запуска JVM, при неизменности этого состояния).

Ключевые аспекты:

Связь hashCode() с equals(): контракт Очень важно понимать не только то, что метод возвращает число, но и строгий контракт:
- Если x.equals(y) == true, то обязательно x.hashCode() == y.hashCode().
- Обратное не обязательно: одинаковые hashCode не гарантируют равенство (допускаются коллизии).
- При каждом вызове hashCode на одном и том же объекте в рамках одной JVM и неизменного состояния результат должен быть стабилен.
- Нарушение контракта ломает структуры данных:
  - объект может "пропасть" из HashSet / HashMap;
  - поиск станет некорректным либо сильно деградирует по производительности.
Как обычно реализуют hashCode Реализация зависит от того, что считается "идентичностью" объекта.
- Для value-объектов (DTO, key-объекты, value-based сущности):
  - хеш строится на основе всех (или ключевых) значимых полей;
- Для mutable-объектов, которые используются как ключи в коллекциях:
  - либо хеш/equals основаны на неизменяемых полях,
  - либо такой объект вообще не должен использоваться как ключ.
Пример корректной реализации:
```
public class User {
    private final long id;
    private final String email;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        User user = (User) o;
        return id == user.id &&
               Objects.equals(email, user.email);
    }

    @Override
    public int hashCode() {
        return Objects.hash(id, email);
    }
}
```
Почему нельзя "просто взять адрес" или случайное число В ранних реализациях JVM (и в некоторых учебных материалах) можно встретить формулировки, что hashCode "основан на адресе объекта". На практике:
- Спецификация Java не требует использовать адрес памяти.
- Современные JVM применяют сжатые ссылки, перемещения объектов (GC, компактификация), поэтому физический адрес нестабилен.
- Реализации hashCode для Object и стандартных классов могут быть оптимизированы и не равны адресам.
- Нельзя использовать случайное число при каждом вызове:
  - нарушит стабильность;
  - сломает поиск в коллекциях.
Особенности для JPA/ORM-сущностей Для сущностей, управляемых ORM (Hibernate и др.) важно быть особенно аккуратным:

Проблемы:
- Прокси-классы;
- Позднее присвоение id (после persist);
- Ленивая загрузка.
Практические рекомендации:
- Не использовать сгенерированный БД id как единственное поле для equals/hashCode, если сущность может участвовать в коллекциях до того, как получит id.
- Лучше использовать:
  - бизнес-ключ (уникальные доменные поля),
  - или стабильную комбинацию полей, доступных до персиста.
- Если используете id:
  - аккуратно документировать и понимать риски;
  - не менять семантику equals/hashCode в течение жизненного цикла объекта.

Пример плохой реализации и ее эффект Плохой пример:

@Override
public int hashCode() {
    return (int) (Math.random() * Integer.MAX_VALUE); // НЕЛЬЗЯ
}

Последствия:

Один и тот же объект попадает в разные бакеты;
Невозможно корректно найти/удалить элемент в HashMap/HashSet.

Плохой пример с изменяемыми полями:

class MutableKey {
    String value;

    @Override
    public int hashCode() {
        return Objects.hash(value);
    }

    @Override
    public boolean equals(Object o) { ... }
}

Map<MutableKey, String> map = new HashMap<>();
MutableKey key = new MutableKey();
key.value = "a";
map.put(key, "test");

key.value = "b"; // хеш изменился

map.get(key); // может вернуть null

Объект больше не находится по новому хешу, он "застрял" в старом бакете.

Типичный паттерн реализации В современных Java-проектах используют утилиту Objects.hash(...) или ручные формулы:
```
@Override
public int hashCode() {
    int result = 17;
    result = 31 * result + (name != null ? name.hashCode() : 0);
    result = 31 * result + age;
    return result;
}
```
Почему так:
- 31 — простое число, оптимизируется JIT (31*x = (x << 5) - x);
- уменьшает количество коллизий для типичных наборов данных.

Резюме:

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

Вопрос 4. Какие правила необходимо соблюдать при реализации метода hashCode?

Таймкод: 00:04:41

Ответ собеседника: неправильный. Перепутал правила equals с правилами hashCode, не сформулировал корректный контракт, частично согласился с подсказками, но полноценного ответа не дал.

Правильный ответ:

Метод hashCode() подчиняется четкому контракту, нарушение которого приводит к некорректной работе HashMap, HashSet, кэшей и других хеш-структур. Важно знать именно формальные правила и практические следствия.

Базовый контракт hashCode:

Согласованность с equals:
- Если x.equals(y) == true, то x.hashCode() == y.hashCode() — всегда.
- Если x.equals(y) == false, hashCode может совпадать (коллизии допустимы), но хорошая реализация минимизирует их.
Стабильность в рамках жизненного цикла объекта:
- При повторных вызовах x.hashCode() в рамках одного запуска JVM и при неизменном "логически значимом состоянии" объекта значение должно быть одинаковым.
- Нельзя делать hashCode, зависящим от:
  - случайных значений (например, Random при каждом вызове),
  - данных, которые произвольно меняются во времени, если объект используется как ключ в мапах или элемент в хеш-сетах.
Совместимость с использованием в коллекциях:
- Если объект используется как ключ в HashMap / элемент HashSet, то поля, участвующие в equals и hashCode, не должны изменяться, пока объект находится в коллекции.
- Если это нарушить:
  - объект окажется "потерян": он будет в структуре, но найти его по ключу уже нельзя.

Расширим эти правила до практических рекомендаций.

Ключевые практики реализации hashCode:

Использовать те же поля, что и в equals
- equals и hashCode должны быть согласованы по набору полей.
- Если поле участвует в equals, оно должно участвовать и в hashCode.
- Несогласованность приводит к неочевидным багам:
  - equals говорит, что объекты равны, а hashCode — разный → нарушен контракт.

Хеш должен быть "достаточно хорошим"

Цель: равномерно распределять значения по хеш-таблице для уменьшения коллизий.
Типичный паттерн:
- начать с ненулевой константы (например, 17),
- умножать на простое число (например, 31) и добавлять хеши полей.

Пример:

public class User {
    private final long id;
    private final String email;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        User user = (User) o;
        return id == user.id &&
               Objects.equals(email, user.email);
    }

    @Override
    public int hashCode() {
        int result = Long.hashCode(id);
        result = 31 * result + (email != null ? email.hashCode() : 0);
        return result;
    }
}

Не использовать нестабильные или технические характеристики:
- Нельзя полагаться на:
  - "адрес в памяти" (он не гарантирован спецификацией, объекты двигает GC),
  - результаты внешних вызовов, которые могут меняться,
  - случайность или время.
- Встроенная реализация Object.hashCode() может быть основана на технических деталях JVM, но для своих классов нужно мыслить в терминах логической идентичности.

Осторожность с изменяемыми объектами

Если объект изменяемый и его поля участвуют в hashCode:
- такой объект нельзя безопасно использовать как ключ в хеш-коллекции после изменения полей.

Пример проблемы:

class MutableKey {
    String value;

    @Override
    public int hashCode() {
        return Objects.hash(value);
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        MutableKey that = (MutableKey) o;
        return Objects.equals(value, that.value);
    }
}

Map<MutableKey, String> map = new HashMap<>();
MutableKey key = new MutableKey();
key.value = "a";
map.put(key, "data");

key.value = "b"; // хеш изменился

// По новому состоянию ключ не находится
map.get(key); // вероятнее всего вернет null

Правильные подходы:
- делать ключи неизменяемыми (immutable),
- или не использовать изменяемые поля в equals/hashCode.

Использование утилит
- В современных версиях Java можно использовать:
```
@Override
public int hashCode() {
    return Objects.hash(id, email);
}
```
- Это упрощает код, но важно понимать, что внутри всё те же принципы.

Резюме (то, что должен сказать кандидат):

Равные по equals объекты обязаны иметь одинаковый hashCode.
Неравные могут иметь одинаковый hashCode, но реализация должна минимизировать коллизии.
hashCode должен быть детерминированным и стабильным при неизменном состоянии объекта.
Поля, участвующие в equals, должны участвовать в hashCode.
Нельзя менять поля, влияющие на hashCode, пока объект является ключом в хэш-коллекции.

Вопрос 5. Зачем нужен метод hashCode, почему недостаточно equals?

Таймкод: 00:06:24

Ответ собеседника: правильный. Объяснил, что hashCode используется для ускорения операций сравнения и работы коллекций: при разных хэшах объекты точно не равны, при совпадении используется equals.

Правильный ответ:

Метод equals сам по себе логически достаточен для определения равенства объектов, но его использование без hashCode делает неэффективной работу хеш-коллекций и структур данных, где требуется быстрый поиск, вставка и удаление.

hashCode нужен как часть механизма хеширования, который обеспечивает амортизированную эффективность операций близкую к O(1) для коллекций, таких как:

HashMap
HashSet
ConcurrentHashMap
LinkedHashMap (на уровне хеш-бакетов)
любые собственные хеш-структуры

Основные причины, почему equals недостаточно:

Стоимость линейного поиска Без hashCode:
- Чтобы найти объект в коллекции, нужно было бы:
  - либо перебирать все элементы и вызывать equals для каждого → O(n),
  - либо использовать дерево или другую структуру, но это уже другая модель (O(log n) и больше памяти/сложности).
- Для больших наборов данных это неприемлемо.
С hashCode:
- Вычисляется хеш-значение.
- По нему определяется "бакет" (индекс в массиве).
- По сути, мы резко сокращаем область поиска.
- equals вызывается только для объектов внутри одного бакета (где хеши совпали или произошла коллизия).
Оптимизация через "грубый фильтр" hashCode работает как быстрый фильтр:
- Если хеши разные → объекты гарантированно не равны, equals можно не вызывать.
- Если хеши одинаковые → возможны два случая:
  - объекты равны (по equals);
  - случилась коллизия, и нужно проверить equals.
Таким образом:
- hashCode() выполняется быстрее, чем серия equals по большим объектам;
- equals() вызывается реже и только там, где это действительно нужно.
Контракт и корректная работа хеш-коллекций Хеш-коллекции полагаются на контракт:
- Равные по equals объекты → одинаковый hashCode.
- Это гарантирует, что:
  - при поиске ключа в HashMap мы попадем в тот же бакет, куда он был положен;
  - при удалении ключа мы сможем его найти;
  - при проверке contains в HashSet будет корректный результат.
Если реализовать только equals, но не hashCode (или реализовать hashCode неверно), возникают эффекты:
- объект есть в HashSet, но contains возвращает false;
- объект есть как ключ в HashMap, но get возвращает null;
- деградация производительности из-за массовых коллизий или неправильного распределения.

Иллюстрация на примере HashMap

Упрощённо алгоритм работы HashMap.get(key):

Вызывается hash = key.hashCode().
Вычисляется индекс: index = hash & (table.length - 1).
В этом бакете просматривается связный список или дерево:
- для каждого элемента:
  - если storedKey.hashCode() == key.hashCode() и storedKey.equals(key) → найден.
Без хорошего hashCode:
- все элементы могут попасть в один бакет → поиск O(n) вместо O(1).

Пример корректного использования:

class User {
    private final long id;
    private final String email;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        User user = (User) o;
        return id == user.id &&
               Objects.equals(email, user.email);
    }

    @Override
    public int hashCode() {
        return Objects.hash(id, email);
    }
}

Map<User, String> map = new HashMap<>();
User u1 = new User(1L, "a@example.com");
map.put(u1, "data");

// По тем же id+email ключ будет найден за O(1) в среднем
System.out.println(map.get(new User(1L, "a@example.com")));

Резюме:

equals определяет семантику равенства.
hashCode обеспечивает эффективную реализацию этой семантики в хеш-структурах.
В связке:
- hashCode — быстрый грубый фильтр и механизм распределения по бакетам,
- equals — точная проверка равенства для кандидатов внутри бакета.
Именно поэтому одного equals недостаточно для производительных коллекций; без hashCode любая хеш-коллекция теряет смысл.

Вопрос 6. Какие основные виды коллекций существуют в Java и как они различаются?

Таймкод: 00:07:01

Ответ собеседника: неполный. Перечислил List, Set, Map, Vector, Stack, Queue, Deque, но частично спутал их роль и актуальность, не структурировал по иерархии и интерфейсам.

Правильный ответ:

В Java Collections Framework важно понимать не просто список классов, а иерархию интерфейсов, их семантику и ключевые реализации. Базовые группы:

Коллекции, основанные на интерфейсе Collection:
- List
- Set
- Queue
- Deque
Отдельно стоящий тип:
- Map (не наследует Collection, но логически относится к коллекциям)

Ниже — структурированное объяснение.

Основные интерфейсы и их семантика:

List Упорядоченная коллекция с индексами, допускает дубликаты.

Ключевые свойства:
- порядок элементов определён (по вставке или по логике реализации);
- доступ по индексу;
- дубликаты разрешены.
Основные реализации:
- ArrayList
  - динамический массив;
  - быстрый доступ по индексу (O(1) амортизированно);
  - неэффективные вставки/удаления из середины (O(n)).
- LinkedList
  - двусвязный список;
  - быстрые вставки/удаления в начале/середине при наличии итератора;
  - медленный произвольный доступ по индексу (O(n)).
- Потокобезопасные варианты:
  - CopyOnWriteArrayList — для сценариев "много читаем, мало пишем";
  - обёртки Collections.synchronizedList(...).
Set Множество: уникальные элементы, отсутствие дубликатов.

Ключевые свойства:
- семантика "есть/нет" по equals/hashCode или по порядку/сравнению;
- порядок не гарантирован (если не указано иное).
Основные реализации:
- HashSet
  - основан на HashMap;
  - быстрая проверка принадлежности (O(1) в среднем);
  - порядок не гарантирован.
- LinkedHashSet
  - сохраняет порядок вставки;
  - предсказуемый порядок обхода.
- TreeSet
  - отсортированное множество;
  - основан на NavigableMap (красно-чёрное дерево);
  - операции O(log n);
  - требует Comparable или Comparator.
Queue Очередь для обработки элементов, обычно по принципу FIFO.

Ключевые свойства:
- операции offer, poll, peek;
- ориентирована на добавление в "хвост" и получение из "головы".
Основные реализации:
- LinkedList (реализует Queue);
- PriorityQueue
  - очередь с приоритетом;
  - элементы упорядочены по приоритету (min-heap);
  - не гарантирует порядок вставки;
- Блокирующие очереди (в пакете java.util.concurrent):
  - ArrayBlockingQueue, LinkedBlockingQueue, PriorityBlockingQueue, DelayQueue, SynchronousQueue и др.
  - используются для многопоточности (producer-consumer и т.п.).
Deque Двусторонняя очередь: добавление и удаление с обоих концов.

Ключевые свойства:
- поддерживает и модель очереди (FIFO), и стек (LIFO);
- методы: addFirst, addLast, pollFirst, pollLast, peekFirst, peekLast.
Основные реализации:
- ArrayDeque
  - эффективная реализация стека и очереди;
  - предпочтительнее Stack и LinkedList для стека.
- LinkedList
  - тоже Deque, но обычно медленнее, больше аллокаций.
Map Отображение "ключ → значение". Не наследует Collection, но является фундаментальной частью коллекций Java.

Ключевые свойства:
- уникальные ключи;
- значение может повторяться;
- поиск по ключу.
Основные реализации:
- HashMap
  - хеш-таблица;
  - O(1) в среднем для get/put;
  - порядок не гарантирован.
- LinkedHashMap
  - сохраняет порядок вставки или доступа;
  - удобно для LRU-кэшей.
- TreeMap
  - отсортирован по ключу (Comparable/Comparator);
  - O(log n) операций;
  - NavigableMap API.
- Специализированные:
  - ConcurrentHashMap — высокопроизводительная потокобезопасная реализация;
  - WeakHashMap — ключи на weak-ссылках (для кешей);
  - IdentityHashMap — сравнение по == вместо equals.
Устаревшие и нежелательные для нового кода:
- Vector
  - синхронизированный динамический массив;
  - морально устарел;
  - для многопоточности лучше Collections.synchronizedList(new ArrayList<>()) или CopyOnWriteArrayList.
- Stack
  - наследуется от Vector;
  - устаревшая модель API;
  - предпочтительно использовать ArrayDeque как стек:
    Deque<Integer> stack = new ArrayDeque<>(); stack.push(1); stack.push(2); Integer val = stack.pop();

Краткое позиционирование (что ожидается на интервью):

Уметь четко назвать:
- List, Set, Queue, Deque, Map — как базовые абстракции.
Понимать их семантику:
- упорядоченность;
- уникальность элементов;
- дубликаты;
- ключ-значение.
Знать стандартные реализации:
- ArrayList, LinkedList, HashSet, LinkedHashSet, TreeSet, HashMap, LinkedHashMap, TreeMap, ArrayDeque, PriorityQueue, ConcurrentHashMap, блокирующие очереди.
Осознавать, что Vector и Stack — исторические и для нового кода обычно не рекомендуются.

Вопрос 7. Как на базовом уровне устроен HashMap внутри?

Таймкод: 00:07:32

Ответ собеседника: правильный. Описал массив бакетов, хранение нод, вычисление индекса по хэшу ключа, обработку коллизий через список и преобразование в дерево при больших цепочках, упомянул стартовую емкость, коэффициент загрузки и расширение.

Правильный ответ:

Внутреннее устройство HashMap — ключевой вопрос, потому что от понимания его работы зависит умение писать корректный и производительный код, особенно при работе с большими объемами данных.

Базовая архитектура:

Основные структуры
- В основе HashMap лежит массив:
```
transient Node<K,V>[] table;
```
- Каждый элемент table[i] — это "бакет" (корзина), который либо пуст, либо содержит:
  - ссылку на:
    - одиночный элемент,
    - или начало цепочки (связный список),
    - или корень дерева (красно-черного дерева) при большом числе коллизий.
Структура Node (упрощенно):
```
static class Node<K,V> implements Map.Entry<K,V> {
    final int hash;
    final K key;
    V value;
    Node<K,V> next;
}
```
Вычисление индекса по ключу Алгоритм размещения элемента:
- Берется hash = key.hashCode().
- Применяется дополнительная обработка (spread), чтобы лучше "распылить" биты:
```
static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
```
  Это уменьшает количество коллизий на верхних битах.
- Индекс бакета вычисляется как:
```
index = (n - 1) & hash
```
  где n — длина массива table. Размер массива всегда степень двойки, что делает операцию модуло дешевой битовой маской.
Обработка коллизий Коллизии неизбежны: разные ключи могут иметь одинаковый индекс бакета.

Механизм:
- Если бакет пуст — элемент кладется туда.
- Если бакет не пуст:
  - Сравниваем хеш и ключ:
    - если найден ключ, равный по equals, то обновляем значение;
    - если нет, добавляем новый элемент в цепочку.
Исторически коллизии обрабатывались только через связные списки:
- поиск в худшем случае — O(n) по длине цепочки.
Начиная с Java 8:
- если число элементов в одном бакете превышает порог TREEIFY_THRESHOLD (обычно 8) и размер всего массива достаточно велик (MIN_TREEIFY_CAPACITY, обычно 64), связный список превращается в сбалансированное красно-черное дерево:
  - поиск в бакете становится O(log n) вместо O(n).
Для дерева используется TreeNode:
```
static final class TreeNode<K,V> extends LinkedHashMap.Entry<K,V> {
    TreeNode<K,V> parent;
    TreeNode<K,V> left;
    TreeNode<K,V> right;
    boolean red;
    // ...
}
```
Коэффициент загрузки (load factor) и ресайз HashMap динамически расширяет внутренний массив при росте количества элементов.

Важные параметры:
- Начальная емкость (initial capacity) по умолчанию: 16.
- Коэффициент загрузки (load factor) по умолчанию: 0.75.
Порог расширения (threshold):
```
threshold = capacity * loadFactor;
```
Например, при capacity=16 и loadFactor=0.75 → threshold = 12.

Когда size (число пар ключ-значение) превышает threshold:
- создается новый массив в 2 раза больше;
- все элементы перераспределяются (rehash / переназначение бакетов):
  - в Java 8 оптимизировано: на основе одного бита хеша решается, останется элемент в том же индексе или уйдет в индекс + старый размер.
Это:
- поддерживает низкий уровень коллизий;
- сохраняет среднюю сложность операций get/put ближе к O(1).
Важные детали, которые стоит знать:
- Ключи:
  - критично корректно реализовать hashCode и equals;
  - неверная реализация ведет к:
    - "потере" ключей,
    - росту коллизий,
    - деградации производительности.
- Null:
  - HashMap допускает один null-ключ;
  - null-ключ всегда кладется в бакет с индексом 0.
- Порядок:
  - HashMap не гарантирует порядок элементов;
  - для сохранения порядка вставки — использовать LinkedHashMap.
- Потокобезопасность:
  - HashMap не потокобезопасен;
  - при конкурентной модификации возможны гонки, потеря данных, в старых версиях JVM — зацикливание списка;
  - для многопоточности использовать ConcurrentHashMap или внешнюю синхронизацию.

Иллюстративный пример (упрощенная логика put/get):

Упрощенный псевдокод put:

V put(K key, V value) {
    int hash = hash(key);
    int i = (table.length - 1) & hash;
    Node<K,V> node = table[i];

    if (node == null) {
        table[i] = newNode(hash, key, value, null);
    } else {
        // проходим по цепочке / дереву
        // если находим существующий ключ -> обновляем value
        // иначе добавляем новый Node в конец или в дерево
    }

    if (++size > threshold)
        resize();
}

Упрощенный get:

V get(Object key) {
    int hash = hash(key);
    int i = (table.length - 1) & hash;
    Node<K,V> node = table[i];

    while (node != null) {
        if (node.hash == hash && (node.key == key || node.key.equals(key))) {
            return node.value;
        }
        node = node.next; // или переход по дереву
    }
    return null;
}

Резюме, которое ожидается:

HashMap основан на массиве бакетов.
Индекс бакета вычисляется по хешу ключа битовой операцией.
Коллизии решаются:
- сначала через связные списки,
- при перегрузке бакета — через красно-черные деревья.
При превышении порога загрузки HashMap расширяется и перераспределяет элементы.
Эффективность и корректность зависят от правильного hashCode/equals и понимания этих механизмов.

Вопрос 8. Можно ли использовать null в качестве ключа в HashMap и какой для него используется hashCode?

Таймкод: 00:09:17

Ответ собеседника: правильный. Сказал, что один null-ключ допустим и для него используется хэш 0.

Правильный ответ:

В HashMap:

Допускается один null-ключ.
Внутренняя реализация обрабатывает null-ключ как специальный кейс:
- При вычислении хеша используется значение 0:
```
static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
```
- Соответственно, null всегда попадает в фиксированный бакет (индекс зависит от размера массива, но с исходным хешем 0).

Ключевые практические моменты:

HashMap в отличие от Hashtable и ConcurrentHashMap разрешает:
- один null-ключ;
- множество null-значений.
Для читаемости и переносимости кода лучше осознанно относиться к использованию null как ключа:
- чаще выбирают явные "sentinel"-значения или обёртки, особенно в сложных доменных моделях;
- помнить, что в других мапах (например, ConcurrentHashMap) null-ключи запрещены, и единообразие API может быть нарушено.

Вопрос 9. Какие типы операций есть в Stream API и что произойдет, если не вызвать терминальную операцию?

Таймкод: 00:09:47

Ответ собеседника: правильный. Разделил операции на промежуточные и терминальные и отметил ленивость стримов: без терминальной операции вычисления не запустятся.

Правильный ответ:

В Java Stream API операции делятся на:

Промежуточные (intermediate operations)
Терминальные (terminal operations)

Ключевая идея: стримы ленивые. Пока не вызвана терминальная операция, никакие промежуточные операции фактически не выполняются, а только накапливаются в виде конвейера.

Промежуточные операции:

Возвращают новый Stream.
Не выполняют обход данных немедленно.
Формируют цепочку преобразований (pipeline).
Могут быть:
- статeless — не зависят от уже обработанных элементов:
  - map, filter, flatMap, peek, distinct (частично), unordered;
- stateful — требуют анализа всего потока:
  - sorted, distinct, limit, skip.

Примеры промежуточных операций:

Stream<Integer> s = list.stream()
    .filter(x -> x > 10)
    .map(x -> x * 2)
    .sorted();

До вызова терминальной операции здесь ничего реально не посчитано.

Терминальные операции:

Запускают выполнение всего конвейера.
Потребляют стрим (после терминальной операции стрим использовать нельзя).
Возвращают не-стрим: значение, Optional, коллекцию, массив, побочный эффект, либо ничего.

Примеры терминальных операций:

Агрегации:
- count(), sum(), average(), min(), max(), reduce(...)
Сбор:
- collect(...) (в List, Set, Map и т.п.)
Поиск/проверки:
- findFirst(), findAny(), allMatch(), anyMatch(), noneMatch()
Итерация:
- forEach(...), forEachOrdered(...)
Прочие:
- toArray()

Пример:

long count = list.stream()
    .filter(x -> x > 10)
    .map(x -> x * 2)
    .count(); // терминальная операция, запускает выполнение

Что произойдет, если не вызвать терминальную операцию:

Стрим сформирует описание конвейера операций, но:
- элементы не будут обработаны,
- лямбды filter/map не выполнятся.
Никакого эффекта (ни побочных, ни вычислительных) не произойдет.

Пример:

list.stream()
    .filter(x -> {
        System.out.println("filter: " + x);
        return x > 10;
    }); // нет терминальной операции

// НИЧЕГО не выведется в консоль

Важно понимать:

Ленивость — основа эффективности Stream API:
- операции сливаются;
- минимизируется количество проходов по данным;
- ранние отсечения (limit, findFirst, anyMatch) могут остановить дальнейшую обработку.

Дублирование терминальных операций требует заново строить стрим:

Stream<String> s = list.stream().filter(x -> x.startsWith("a"));
long c1 = s.count();
long c2 = s.count(); // IllegalStateException — стрим уже потреблен

На уровне ожидаемого ответа достаточно четко разделить:

промежуточные операции — ленивые, возвращают Stream;
терминальные — запускают выполнение, потребляют Stream;
без терминальной операции вычислений не будет.

Вопрос 10. Можно ли переопределить статический метод при наследовании классов?

Таймкод: 00:10:55

Ответ собеседника: неправильный. Заявил, что статический метод можно переопределить, при этом неверно описал поведение и проигнорировал механизм статического связывания.

Правильный ответ:

Статические методы в Java не переопределяются в классическом полиморфном смысле, а скрываются (method hiding).

Ключевые тезисы:

Статический метод не участвует в динамическом полиморфизме
- Виртуальные (нестатические) методы:
  - выбираются по реальному типу объекта во время выполнения (dynamic dispatch).
- Статические методы:
  - привязаны к типу на этапе компиляции (static binding);
  - вызываются по имени класса, а не по объекту.
Поэтому:
- Статический метод нельзя переопределить так, чтобы вызов выбирался по реальному типу объекта.
- Можно объявить в классе-наследнике статический метод с той же сигнатурой — это скрытие (hiding), а не переопределение.

Что такое method hiding для статических методов

Если есть:

class Parent {
    static void foo() {
        System.out.println("Parent.foo");
    }
}

class Child extends Parent {
    static void foo() {
        System.out.println("Child.foo");
    }
}

Тогда поведение:

Parent p = new Parent();
Parent cAsParent = new Child();
Child c = new Child();

Parent.foo();      // Parent.foo
Child.foo();       // Child.foo

p.foo();           // Parent.foo (но так писать не рекомендуется)
c.foo();           // Child.foo
cAsParent.foo();  // Parent.foo (!) статическое связывание по типу ссылки

Важно:

Вызов cAsParent.foo() определяется по типу Parent, а не по фактическому типу Child.
Это принципиальное отличие от обычного полиморфизма виртуальных методов.

Правильное использование
- Статические методы:
  - следует вызывать через имя класса, а не через объект:
    Parent.foo(); Child.foo();
- Наличие одинаковых статических методов в родителе и наследнике:
  - ухудшает читаемость;
  - может приводить к путанице;
  - обычно считается плохой практикой, если нет очень веской причины.
Формальные ограничения:
- Нельзя ослаблять модификаторы доступа при "скрытии":
```
class Parent {
    public static void foo() {}
}
class Child extends Parent {
    // protected static void foo() {} // так нельзя
}
```
- Нельзя менять возвращаемый тип на несовместимый.
- Но даже при соблюдении сигнатуры — это именно hiding, а не override.
Вывод, который нужно озвучить на интервью:
- Статические методы не переопределяются, а скрываются.
- Вызов статического метода определяется по типу ссылки/класса на этапе компиляции.
- Полиморфизм через @Override относится только к нестатическим (экземплярным) методам.

Вопрос 11. В чём семантическая разница между интерфейсом и абстрактным классом?

Таймкод: 00:11:34

Ответ собеседника: правильный. Объяснил, что интерфейс задает абстракцию и контракт методов, которые должны быть реализованы, без лишних технических деталей.

Правильный ответ:

Семантическая (смысловая) разница между интерфейсом и абстрактным классом важнее, чем набор языковых ограничений. Речь не только о синтаксисе, а о том, что именно вы хотите выразить в модели:

Интерфейс — это обещание поведения.
Абстрактный класс — это частичная реализация и разделяемая модель состояния.

Основные отличия по смыслу и назначению:

Контракт vs базовая реализация

Интерфейс:
- Описывает "что объект умеет делать".
- Фокус на внешнем поведении, не на внутреннем состоянии.
- Говорит: "любой, кто реализует этот интерфейс, гарантирует, что у него есть такое поведение".
- Семантически похож на роль, способность, протокол.
  - Примеры:
    - Comparable — объект можно сравнивать.
    - Runnable — объект можно "запустить".
    - AutoCloseable — объект можно корректно закрыть.
Абстрактный класс:
- Описывает "что это за сущность" + содержит часть общей логики для наследников.
- Встраивает общую реализацию, состояние, инварианты.
- Говорит: "все наследники — это разновидности этой сущности".
- Семантически — это базовый тип в иерархии доменной модели.
  - Примеры:
    - InputStream / OutputStream — базовые потоки.
    - AbstractList, AbstractMap — частичные реализации коллекций.

Идентичность и место в иерархии

Интерфейс:
- Не несет "идентичности" типа в смысле "это такой-то вид сущности".
- Один класс может реализовывать несколько интерфейсов → несколько ролей.
- Пример:
  - class UserDto implements Serializable, Comparable<UserDto>, JsonExportable
  - Здесь интерфейсы описывают поведения, а не "родословную".
Абстрактный класс:
- Формирует жесткую иерархию наследования.
- Класс-наследник семантически "является" этим базовым типом.
- Вы выражаете сильное "is-a":
  - class FileInputStream extends InputStream
  - FileInputStream — это конкретный вид InputStream.

Наследование и композиция возможностей

Интерфейс:
- Множественная реализация:
  - класс может реализовать любое количество интерфейсов;
  - это основной механизм композиции функционала в Java.
- Используется, когда нужно объединить разные абстракции без жёсткой иерархии.
Абстрактный класс:
- Можно наследоваться только от одного (single inheritance).
- Выбирая абстрактный базовый класс, вы "занимаете слот" наследования.
- Применим для случаев, когда:
  - есть общее состояние,
  - есть общие защищённые методы,
  - нужна единая точка контроля инвариантов.

Реализация по умолчанию и эволюция API

С учётом современных версий Java:

Интерфейс:
- Может содержать:
  - default методы — реализация по умолчанию;
  - static методы;
  - private методы (вспомогательные, для default/static).
- Но даже с default методами его главная роль — описывать поведение, а не состояние.
- Default-методы:
  - удобны для эволюции API без ломки существующих реализаций;
  - не должны превращать интерфейс в "полукласс" с тяжёлой логикой и состоянием.
Абстрактный класс:
- Может иметь:
  - поля (состояние),
  - конструктор,
  - как абстрактные, так и конкретные методы.
- Выражает общую реализацию, в том числе сложную, с инкапсуляцией.

Семантические рекомендации по использованию

Использовать интерфейс, когда:
- нужно задать контракт поведения;
- важна возможность реализации разными, не связанными между собой классами;
- вы проектируете API/SDK, где потребители должны свободно подключаться;
- вам нужна множественная "навигация по ролям":
  - например, Loggable, Retriable, Auditable.
Использовать абстрактный класс, когда:
- есть сильная общность реализации между наследниками;
- нужно разделить общий код, состояние и инварианты:
  - шаблонный метод, хуки;
- вы контролируете иерархию и хотите гарантировать единый базовый слой.

Примеры для закрепления

Пример интерфейса как контракта:

public interface Repository<T, ID> {
    T findById(ID id);
    void save(T entity);
    void delete(T entity);
}

Разные реализации могут работать с памятью, БД, сетью, не имея общего предка кроме интерфейса.

Пример абстрактного класса как общей реализации:

public abstract class AbstractRepository<T, ID> implements Repository<T, ID> {
    protected final DataSource ds;

    protected AbstractRepository(DataSource ds) {
        this.ds = ds;
    }

    @Override
    public void save(T entity) {
        // общая логика логирования, транзакций и т.п.
        doSave(entity);
    }

    protected abstract void doSave(T entity);
}

Здесь:

интерфейс Repository — контракт;
AbstractRepository — базовая реализация/инфраструктура.

Резюме (что важно озвучить на интервью):

Интерфейс описывает поведение (контракт), не навязывает реализацию и не задаёт идентичность.
Абстрактный класс задает общую сущность с частичной реализацией и общим состоянием.
Интерфейсы удобно комбинировать (множественное наследование поведения); абстрактный класс — основа иерархии, которую выбирают осознанно.

Вопрос 12. В чём заключается разница по назначению между интерфейсом и абстрактным классом?

Таймкод: 00:11:34

Ответ собеседника: правильный. Пояснил, что интерфейс задаёт контракт (включая возможные маркерные интерфейсы) и поддерживает множественное наследование, а абстрактный класс допускает только одно наследование, может содержать общую реализацию и служит базой для упрощения наследников.

Правильный ответ:

Семантика и назначение:

Интерфейс и абстрактный класс в Java решают разные архитектурные задачи, даже если технически могут пересекаться по возможностям.

Ключевая идея:

Интерфейс — декларация "какое поведение доступно".
Абстрактный класс — база "какой это тип" и "как часть поведения уже реализована".

Интерфейс (назначение):

Описывает контракт:
- набор методов, которые должен поддерживать тип.
- не навязывает модель данных или иерархию.
Представляет роль, способность или протокол взаимодействия:
- можно считать: "если тип реализует этот интерфейс, с ним можно делать X".
Может быть:
- функциональным (один абстрактный метод, например Runnable, Callable<T>),
- маркерным (без методов: Serializable, Cloneable),
- расширяемым: интерфейс может наследовать несколько других интерфейсов.
Используется для:
- ослабления связности;
- проектирования API через зависимости от абстракций;
- возможности множества реализаций, не связанных единым базовым классом.
Множественная реализация:
- один класс может реализовать множество интерфейсов, комбинируя роли:
```
public class Job implements Runnable, AutoCloseable {
    @Override
    public void run() { /* ... */ }

    @Override
    public void close() { /* ... */ }
}
```

Абстрактный класс (назначение):

Определяет базовый тип доменной иерархии:
- говорит: "все наследники — это конкретные виды этой сущности".
Объединяет общую реализацию:
- поля,
- конструкторы,
- защищённые методы,
- частично готовые реализации публичных методов.
Фиксирует инварианты и общий жизненный цикл:
- удобно реализовывать шаблонный метод (template method pattern):
  - базовый класс определяет алгоритм,
  - наследники переопределяют отдельные шаги.
Используется для:
- предотвращения копипаста общей логики,
- централизованного контроля поведения и состояния,
- сильного "is-a" отношения.

Только одно наследование:

выбор абстрактного базового класса — это жёсткое архитектурное решение:

public abstract class BaseController {
    protected final Logger log = LoggerFactory.getLogger(getClass());

    protected void logRequest(String info) {
        log.info("REQ: {}", info);
    }

    public abstract void handle();
}

public class UserController extends BaseController {
    @Override
    public void handle() {
        logRequest("user request");
        // ...
    }
}

Как выбирать на практике:

Выбери интерфейс, если:
- хочешь задать контракт без навязывания реализации;
- ожидаешь множество несвязанных реализаций;
- хочешь облегчить тестирование и мокинг;
- повышаешь модульность и расширяемость (инфраструктура, плагины, адаптеры).
Выбери абстрактный класс, если:
- у всех наследников есть общие поля, логика, инварианты;
- нужна частичная реализация, общий конструктор, общие protected-хуки;
- ты контролируешь иерархию и хочешь централизованно управлять базовым поведением.

Комбинация (частый и правильный подход):

Интерфейс — внешний контракт:

public interface PaymentGateway {
    boolean charge(String userId, long amount);
}

Абстрактный класс — базовая реализация контракта:

public abstract class AbstractPaymentGateway implements PaymentGateway {
    protected final HttpClient client;

    protected AbstractPaymentGateway(HttpClient client) {
        this.client = client;
    }

    protected void logRequest(String payload) { /* ... */ }
}

Такое разделение:

интерфейс — точка расширения и подмена реализаций;
абстрактный класс — шаринг логики между конкретными реализациями.

Итого, кратко по назначению:

Интерфейс — контракт поведения и "роль", лёгкий и независимый.
Абстрактный класс — базовый тип с общим кодом и состоянием, усиливает связность внутри иерархии, но упрощает реализацию наследников.

Вопрос 13. Что в Java отвечает за автоматическую очистку памяти?

Таймкод: 00:13:37

Ответ собеседника: правильный. Указал на сборщик мусора как механизм освобождения неиспользуемой памяти.

Правильный ответ:

В Java за автоматическую очистку памяти отвечает сборщик мусора (Garbage Collector, GC), являющийся частью JVM. Его задача — автоматически находить объекты в куче (heap), которые больше недостижимы из "живых" ссылок, и освобождать занимаемую ими память без участия разработчика.

Ключевые идеи:

Модель управления памятью в Java:
- Память для объектов выделяется в куче с помощью new.
- Освобождение памяти вручную (как в free или явном delete) не выполняется.
- Жизненный цикл объектов:
  - объект жив, пока на него есть цепочка ссылок от корневых точек (GC roots);
  - как только объект становится недостижимым, он считается мусором.
GC Roots и достижимость: Типичные GC roots:
- ссылки из стека активных потоков (локальные переменные, параметры методов);
- статические поля загруженных классов;
- ссылки из JNI;
- некоторые внутренние структуры JVM.
Алгоритм на уровне идей:
- от GC roots запускается обход (mark);
- все достижимые объекты помечаются;
- не помеченные считаются мусором и подлежат очистке (sweep/compact).
Основные алгоритмические принципы: JVM использует несколько семейств алгоритмов (в зависимости от выбранного GC):
- Поколенческий подход (generational GC):
  - память делится на young / old (tenured);
  - большинство объектов "умирает" быстро;
  - молодое поколение очищается чаще и быстрее (Minor GC);
  - объекты, пережившие несколько сборок, переносятся в старшее поколение.
- Маркировка и очистка (mark-sweep), маркировка и компактификация (mark-compact).
- Современные коллекторы:
  - Parallel GC,
  - CMS (устаревший),
  - G1 (Garbage-First),
  - ZGC,
  - Shenandoah. Они оптимизируют паузы, throughput или использование памяти.
Важные практические моменты для разработчика:
- Нет гарантий по времени:
  - нельзя полагаться на момент вызова GC;
  - System.gc() — лишь рекомендация, JVM может проигнорировать.
- Освобождение ресурсов ≠ только память:
  - GC управляет только памятью;
  - файлы, сокеты, соединения, блокировки, пул-коннекты нужно закрывать вручную (try-with-resources, close()).
- finalize():
  - исторически использовался для очистки;
  - непредсказуем, медленный, устаревший и официально deprecated;
  - вместо него использовать:
    - явное управление ресурсами,
    - try-with-resources,
    - Cleaner/референсы в редких случаях.
Типичные ошибки и важные акценты:
- "Утечки памяти" в Java возможны, даже с GC:
  - если объект по-прежнему достижим через ссылки (например, закинули в статическую коллекцию и не удалили), GC не имеет права его удалить.
  - это логические утечки, а не отсутствие free.
- Грамотное управление жизненным циклом объектов, коллекциями, кэшами и ссылками — критично для стабильности и эффективности.

Резюме:

За автоматическое освобождение памяти в Java отвечает сборщик мусора.
Он удаляет объекты, которые стали недостижимы, на основе анализа графа ссылок.
Разработчик не управляет освобождением памяти вручную, но обязан корректно управлять ресурсами и ссылками, чтобы не мешать работе GC.

Вопрос 14. Как определяется, что объект стал мусором и может быть удалён сборщиком мусора?

Таймкод: 00:13:45

Ответ собеседника: правильный. Описал проверку достижимости от корневых ссылок: если объект недостижим из GC roots, он считается мусором.

Правильный ответ:

В современных реализациях Java объект считается мусором не по "количеству ссылок", а по критерию достижимости от специальных корневых объектов (GC Roots). Это принципиально важный момент.

Базовая идея:

Объект пригоден для сборки, если он недостижим из множества GC Roots.
Недостижимость означает: не существует ни одной цепочки ссылок от любого GC root до этого объекта.

GC Roots обычно включают:

Стековые фреймы активных потоков:
- локальные переменные и параметры методов;
Статические поля загруженных классов;
Ссылки из JNI (native-код);
Внутренние структуры JVM:
- объекты, используемые для синхронизации, системные объекты и т.п.

Алгоритм на концептуальном уровне:

Фаза "mark" (маркировка):
- Сборщик мусора начинает обход от GC Roots.
- Все объекты, до которых можно добраться по ссылкам, помечаются как "живые".
Фаза "sweep"/"compact":
- Объекты, которые не были помечены, считаются мусором.
- Их память освобождается.
- В некоторых алгоритмах память дополнительно компактируется (сдвиг объектов для устранения фрагментации).

Почему не используется простой reference counting:

Подход "подсчёт ссылок" плохо работает с циклическими зависимостями:
- два объекта ссылаются друг на друга, но недостижимы извне — их счётчик ссылок не будет нулевым, хотя они — мусор.
Модель достижимости (reachability) корректно обрабатывает циклы:
- если цикл недостижим от GC Roots, вся компонента удаляется.

Типы достижимости (для полноты, важны при работе со ссылками):

Strong reachable:
- обычные ссылки; пока есть сильная достижимость — объект не собирается.
Soft, Weak, Phantom references:
- позволяют более тонко управлять временем жизни объектов (кэши, отслеживание финализации и т.п.), но базовый критерий всё равно строится вокруг достижимости от корней с учетом типа ссылок.

Вывод:

Объект подлежит сборке, когда он становится недостижимым из множества GC Roots.
Наличие циклических ссылок само по себе не мешает сборке, если цикл целиком недостижим извне.
Это делает поведение GC корректным и предсказуемым при сложных графах объектов.

Вопрос 15. Какую роль играет ключевое слово volatile в контексте многопоточности?

Таймкод: 00:14:39

Ответ собеседника: неполный. Говорит про запрет кэширования и чтение актуального значения, но путается в деталях реализации и ограничениях.

Правильный ответ:

Ключевое слово volatile в Java связано не просто с "запретом кэширования", а с моделью памяти Java (Java Memory Model, JMM). Его основная задача — обеспечить:

видимость изменений переменной между потоками;
определённый порядок операций (memory barriers / happens-before отношения).

Важно понимать: volatile не делает операции атомарными в общем случае и не заменяет synchronized или высокоуровневые примитивы из java.util.concurrent.

Основные свойства volatile:

Гарантия видимости (visibility)

Без volatile и без синхронизации каждый поток может кэшировать значение переменной в регистрах или в локальных кеш-линиях и не обновлять его сразу в общую память. В результате один поток может бесконечно видеть устаревшее значение.

С volatile:

чтение volatile переменной всегда возвращает последнее записанное значение (с учётом JMM, через main memory/барьеры);
запись в volatile переменную немедленно становится видима другим потокам, читающим её.

Пример флага остановки потока:

class Worker implements Runnable {
    private volatile boolean running = true;

    @Override
    public void run() {
        while (running) {
            // работа
        }
    }

    public void stop() {
        running = false; // другой поток увидит изменение
    }
}

Без volatile (или другой синхронизации) JIT может закэшировать running и цикл не завершится.

Гарантии упорядочивания (ordering, happens-before)

volatile создаёт упорядочивание операций:

Запись в volatile:
- "выдавливает" (flush) все предыдущие записи в память до этой записи.
Чтение volatile:
- "тянет" (load) все последующие чтения так, что они не будут выполнены "раньше" чтения volatile (с точки зрения другого потока).

Формально:

Запись в volatile переменную "happens-before" последующего чтения этой же переменной в другом потоке.
Это позволяет использовать volatile как лёгкий механизм публикации состояния (publication / visibility), когда не требуется сложная композиция операций.

Что volatile НЕ делает

Критически важно:

Не делает составные операции атомарными:
- count++, x = x + 1, list.add(...) — не становятся потокобезопасными от того, что count или list объявлены как volatile.
- Это несколько шагов: чтение, вычисление, запись — между ними может вмешаться другой поток.

Пример неправильной надежды на volatile:

volatile int counter = 0;

void inc() {
    counter++; // не атомарно!
}

Для атомарного инкремента нужны:

AtomicInteger.incrementAndGet()
или synchronized,
или другие механизмы.
Не синхронизирует блоки кода как synchronized:
- volatile не даёт эксклюзивного доступа, только видимость и частичный порядок.

Ограничения и применимость

Типы:

volatile можно применять к:
- примитивным типам (кроме long и double в старых JVM были нюансы выравнивания, но в современной спецификации чтение/запись volatile long/double атомарны),
- ссылочным типам.
Нельзя сделать volatile "часть объекта":
- volatile относится к самой переменной-ссылке, а не к полям объекта, на который она указывает.

Пример:

class Holder {
    int x;
}

volatile Holder h;

// volatile гарантирует видимость изменений ссылки h,
// но не делает операции с h.x автоматически потокобезопасными.

Когда volatile уместен:

Флаг остановки потока.
Публикация уже сконструированного неизменяемого/эффективно неизменяемого объекта:
```
private volatile Config config;

public void reload() {
    config = loadConfig(); // публикация нового снапшота
}
```
Простые одношаговые записи/чтения, где важна видимость и порядок, но не нужна композиция нескольких операций как единой транзакции.

Связь с double-checked locking

Классический пример, где важно понимать volatile:

class Singleton {
    private static volatile Singleton instance;

    public static Singleton getInstance() {
        if (instance == null) {            // 1-я проверка (без lock)
            synchronized (Singleton.class) {
                if (instance == null) {    // 2-я проверка (под lock)
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

Без volatile возможно частично сконструированное состояние, видимое другим потоком (из-за reorderings). volatile здесь гарантирует корректную публикацию полностью сконструированного объекта.

Резюме:

volatile обеспечивает:
- видимость изменений между потоками,
- частичный порядок операций (happens-before),
- атомарность для одиночных чтений/записей поддерживаемых типов.
Не обеспечивает:
- атомарность составных операций,
- эксклюзивный доступ, как synchronized.
Используется для простых сценариев синхронизации (флаги, публикация ссылок, конфигурация), во всех сложных случаях лучше использовать synchronized, Lock, Atomic*, ConcurrentHashMap и другие высокоуровневые примитивы.

Вопрос 16. Если три потока по 500 раз инкрементируют общее volatile int-поле, гарантировано ли получение результата 1500?

Таймкод: 00:15:36

Ответ собеседника: неправильный. Сначала утверждает, что для 32-битного int результат будет 1500, игнорируя неатомарность инкремента; необходимость учета неатомарности понимает только после подсказки.

Правильный ответ:

Нет, результат 1500 не гарантирован, даже если поле объявлено как volatile. Причина в том, что инкремент (i++) — неатомарная операция, а volatile не делает её атомарной.

Разберём по сути.

Что делает volatile

volatile дает:

гарантию видимости:
- каждый поток читает актуальное значение переменной из памяти;
частичный порядок операций (happens-before):
- запись в volatile видна другим потокам в корректном порядке.

Но volatile:

не защищает от гонок состояний (data races),
не делает составные операции атомарными.

Почему инкремент неатомарен

Операция counter++ раскладывается на шаги:

прочитать значение counter;
увеличить на 1;
записать новое значение.

Даже при volatile int counter каждый из потоков делает свою последовательность read-modify-write. Между чтением и записью другого потока может вмешаться третий, и некоторые инкременты "потеряются".

Иллюстрация гонки:

Пусть counter = 0.
Поток A читает: 0.
Поток B читает: 0.
Поток A пишет: 1.
Поток B пишет: 1. Итог: два инкремента, результат 1 вместо ожидаемых 2.

С тремя потоками по 500 инкрементов эффект тот же: итоговое значение может быть меньше 1500, и это поведение не детерминировано.

Что нужно, чтобы гарантировать 1500

Корректные варианты:

Использовать синхронизацию:

class Counter {
    private int value = 0;

    public synchronized void inc() {
        value++;
    }

    public synchronized int get() {
        return value;
    }
}

Здесь synchronized делает блок атомарным и обеспечивает видимость.

Использовать атомарные типы (java.util.concurrent.atomic):

class Counter {
    private final AtomicInteger value = new AtomicInteger(0);

    public void inc() {
        value.incrementAndGet(); // атомарный инкремент
    }

    public int get() {
        return value.get();
    }
}

Использовать другие примитивы синхронизации (Lock, LongAdder, и т.п.) в зависимости от профиля нагрузки.

Почему volatile-инкремент — типичный подвох на интервью

Важно уметь чётко сформулировать:

volatile гарантирует видимость, но не атомарность ++.
Для корректного счётчика в многопоточной среде нужны атомарные операции или взаимное исключение.

Резюме:

Ответ: нет, 1500 не гарантировано.
Причина: i++ — неатомарная read-modify-write операция; volatile не решает эту проблему.
Решение: synchronized, AtomicInteger, LongAdder и другие специализированные механизмы.

Вопрос 17. Что такое рефлексия в Java?

Таймкод: 00:17:10

Ответ собеседника: правильный. Описывает рефлексию как механизм, позволяющий во время выполнения получать информацию о состоянии объектов и работать с кодом динамически.

Правильный ответ:

Рефлексия (Reflection) в Java — это механизм, который позволяет программе во время выполнения исследовать и изменять структуру и поведение классов и объектов: получать информацию о типах, полях, методах, конструкторах, аннотациях и, при необходимости, вызывать методы или изменять поля динамически.

Ключевая идея: рефлексия даёт доступ к метаданным о типах и позволяет работать с объектами не зная их конкретных классов на этапе компиляции.

Основные возможности рефлексии:

Исследование типов во время выполнения:
- Получение Class<?>:
  - obj.getClass()
  - SomeClass.class
  - Class.forName("com.example.SomeClass")
- Получение информации о:
  - полях (Field),
  - методах (Method),
  - конструкторах (Constructor),
  - модификаторах (Modifier),
  - аннотациях (Annotation),
  - суперклассах, интерфейсах, generic-параметрах (частично).
Динамическое создание объектов:
- Можно создавать экземпляры классов, имя которых известно только в рантайме:
```
Class<?> clazz = Class.forName("com.example.User");
Object user = clazz.getDeclaredConstructor().newInstance();
```
Доступ к полям, в том числе приватным:
- Чтение/запись значений по имени поля:
```
Field field = clazz.getDeclaredField("name");
field.setAccessible(true); // обход модификатора доступа
field.set(user, "John");
String name = (String) field.get(user);
```
- Это мощный, но опасный инструмент:
  - нарушает инкапсуляцию,
  - усложняет сопровождение и тестирование.
Динамический вызов методов:
- Можно вызывать методы, имя/сигнатура которых известны только во время выполнения:
```
Method m = clazz.getDeclaredMethod("setAge", int.class);
m.setAccessible(true);
m.invoke(user, 30);
```
Работа с аннотациями:
- Рефлексия лежит в основе:
  - DI-контейнеров (Spring),
  - JPA/Hibernate,
  - сериализации/десериализации,
  - REST/JSON-маршалинга,
  - тестовых фреймворков (JUnit),
  - аспектно-ориентированного программирования.
- Пример:
```
if (clazz.isAnnotationPresent(Entity.class)) {
    // регистрируем как JPA-сущность
}
```

Практическая значимость:

Рефлексия — фундамент инфраструктурного и фреймворк-кода.
Позволяет:
- строить универсальные библиотеки и ORM;
- маппить объекты на JSON/XML/SQL без ручного кода;
- реализовывать плагины и расширяемые системы.

Ограничения и недостатки:

Потеря статической типизации на месте использования:
- ошибки проявляются в рантайме (NoSuchMethodException, IllegalAccessException, InvocationTargetException).
Снижение производительности:
- доступ к полям/методам через рефлексию медленнее прямых вызовов;
- часто это не критично, но важно в высоконагруженных участках.
Нарушение инкапсуляции:
- использование setAccessible(true) ломает защиту модификаторов доступа;
- усложняет рефакторинг и поддержку.
Ограничения модульной системы (Java 9+):
- доступ к internals через рефлексию может блокироваться module system,
- нужны --add-opens, явные экспортируемые пакеты и т.п.

Рекомендации:

В прикладном бизнес-коде использовать рефлексию точечно и осознанно.
Основная область — инфраструктура, фреймворки, универсальные библиотеки.
Если можно решить задачу через обычные интерфейсы, дженерики, полиморфизм или шаблоны проектирования — это обычно предпочтительнее.

Таким образом, рефлексия в Java — это мощный механизм динамического анализа и манипуляции типами и объектами во время выполнения, критически важный для экосистемы фреймворков, но требующий аккуратного и ответственного использования.

Вопрос 18. Что означает аббревиатура ACID и в чём суть её свойств для транзакций?

Таймкод: 00:17:39

Ответ собеседника: неполный. Корректно расшифровал атомарность, согласованность, изолированность, долговечность и в целом верно объяснил атомарность и долговечность, но дал размытые и частично неточные формулировки для согласованности и изолированности.

Правильный ответ:

ACID — это набор фундаментальных свойств транзакций в реляционных СУБД (и не только), гарантирующий предсказуемое и корректное поведение данных даже при сбоях и конкурентном доступе.

Расшифровка:

A — Atomicity (Атомарность)
C — Consistency (Согласованность)
I — Isolation (Изолированность)
D — Durability (Долговечность)

Разберём каждое свойство с точки зрения практики и архитектуры.

Атомарность (Atomicity):

Суть:

Транзакция — неделимая единица работы:
- либо выполняются все её операции,
- либо не выполняется ни одна.
Если в середине транзакции произошла ошибка (исключение, конфликт блокировок, отказ узла) — все изменения откатываются (rollback).

Практически:

Гарантия: нет "полуприменённых" изменений.
Пример:
- Перевод денег между счетами:
  - UPDATE accounts SET balance = balance - 100 WHERE id=1;
  - UPDATE accounts SET balance = balance + 100 WHERE id=2;
- Если вторая операция не удалась — первая должна быть отменена.

SQL-пример:

BEGIN;

UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

COMMIT;  -- либо все изменения фиксируются
-- ROLLBACK; -- либо при ошибке откат до начала транзакции

Согласованность (Consistency):

Суть:

После завершения транзакции данные должны удовлетворять всем определённым инвариантам:
- ограничениям целостности (PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK),
- бизнес-правилам, которые система обязана соблюдать.
Транзакция не должна переводить базу из одного корректного состояния в некорректное:
- либо остаёмся в корректном состоянии,
- либо выполняется откат.

Важно:

Consistency в ACID — это не только "консистентность между репликами" (это больше про CAP и eventual consistency), а именно соблюдение целостности данных с точки зрения схемы и инвариантов.
Согласованность — это совместный результат:
- корректного приложения (не нарушающего правил),
- и механизмов БД (ограничения, триггеры, проверки).

Пример:

Есть ограничение: баланс не может быть отрицательным.
```
ALTER TABLE accounts
ADD CONSTRAINT chk_balance_non_negative CHECK (balance >= 0);
```
Если транзакция пытается записать balance = -100, БД отклонит изменения.
Транзакция либо откатывается, либо приводит данные к состоянию, в котором все ограничения соблюдены.

Изолированность (Isolation):

Суть:

Параллельно выполняющиеся транзакции не должны "ломать" друг другу логику.
С точки зрения каждой транзакции система должна выглядеть так, как будто:
- либо она выполняется одна,
- либо другие транзакции выполняются до/после неё (зависит от уровня изоляции).

Изолированность защищает от аномалий:

Dirty read — чтение неподтвержденных изменений другой транзакции.
Non-repeatable read — одно и то же условие в рамках транзакции даёт разные результаты при повторном чтении.
Phantom read — при повторном запросе по условию появляются/исчезают строки.

Уровни изоляции (SQL-ориентированно):

READ UNCOMMITTED:
- допускает dirty reads (почти не используется в нормальных системах).
READ COMMITTED:
- гарантирует отсутствие dirty reads;
- но возможны non-repeatable reads и phantom reads.
REPEATABLE READ:
- отсутствуют dirty/non-repeatable reads;
- возможны phantom reads (в некоторых СУБД снижено за счет механизмов, напр. MVCC).
SERIALIZABLE:
- максимальная изоляция — эквивалент последовательного выполнения транзакций;
- дорогой, влияет на конкуренцию.

Смысл:

Isolation — баланс между корректностью и производительностью.
Для критичных операций (финансы, инварианты) используют более строгие уровни.
Для высоконагруженных систем часто выбирают READ COMMITTED или REPEATABLE READ + дополнительная бизнес-валидация.

Долговечность (Durability):

Суть:

Если транзакция подтверждена (COMMIT завершился успешно), её результат не должен быть потерян:
- ни при падении процесса,
- ни при рестарте сервера,
- ни при сбое ОС (в разумных рамках модели отказоустойчивости и настроек).

Как достигается:

Журнал предзаписи (WAL — Write-Ahead Log):
- изменения сначала фиксируются в надежном журнале на диске;
- только после этого транзакция считается закоммиченной.
Механизмы синхронизации на диск (fsync), репликации, кластеризации.

Практически:

После успешного COMMIT приложение может считать, что данные сохранены.
Детали зависят от настроек durability в конкретной БД (например, в PostgreSQL synchronous_commit, в MySQL innodb_flush_log_at_trx_commit).

Краткий итог (то, что должен уверенно проговорить кандидат):

Atomicity:
- транзакция либо целиком, либо никак.
Consistency:
- транзакция не нарушает инварианты и ограничения; БД переходит из одного корректного состояния в другое.
Isolation:
- параллельные транзакции не мешают друг другу логически; степень защиты зависит от уровня изоляции.
Durability:
- успешно закоммиченные изменения переживают сбои и остаются сохранёнными.

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

Вопрос 19. Какие уровни изоляции транзакций существуют и какой из них является самым высоким?

Таймкод: 00:19:28

Ответ собеседника: правильный. Перечислил READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE и указал SERIALIZABLE как максимальный уровень.

Правильный ответ:

Стандартные уровни изоляции транзакций определены SQL-стандартом и регулируют, какие аномалии конкурентного доступа допускаются. Это баланс между консистентностью и производительностью.

Классические уровни (от наименее строгого к наиболее строгому):

READ UNCOMMITTED
READ COMMITTED
REPEATABLE READ
SERIALIZABLE

Самый высокий уровень изоляции — SERIALIZABLE.

Кратко по каждому уровню и аномалиям, которые они допускают:

READ UNCOMMITTED

Самый слабый уровень.
Допускает:
- dirty reads (грязные чтения) — чтение незакоммиченных данных других транзакций,
- non-repeatable reads,
- phantom reads.
Практически почти не используется в нормальных OLTP-системах.

READ COMMITTED

Наиболее часто используемый уровень по умолчанию (Oracle, PostgreSQL).
Гарантии:
- нет dirty reads: читаем только зафиксированные (committed) данные.
Но допускает:
- non-repeatable reads (повторное чтение той же строки в рамках одной транзакции может дать другое значение, если другая транзакция успела закоммитить изменения),
- phantom reads (множество строк по одному и тому же запросу может меняться).

Пример:

В начале транзакции читаем заказ с суммой 100,
в другой транзакции меняют сумму на 200 и коммитят,
в этой же транзакции при повторном SELECT видим уже 200.

REPEATABLE READ

Более строгий уровень.
Гарантии:
- нет dirty reads,
- нет non-repeatable reads: если строка прочитана, повторное чтение этой же строки в рамках транзакции вернёт то же значение (в классической модели).
Допускает:
- phantom reads (в стандартной трактовке):
  - при повторном запросе по условию могут появляться новые строки, удовлетворяющие условию.
Реализация зависит от СУБД:
- В PostgreSQL (MVCC) REPEATABLE READ фактически даёт снимок (snapshot) на момент старта транзакции и защищает и от фантомов — поведение близко к snapshot isolation.
- В MySQL InnoDB REPEATABLE READ + gap locks могут предотвращать фантомы при определённых настройках.

SERIALIZABLE

Самый строгий уровень.
Гарантия:
- результат параллельного выполнения транзакций эквивалентен некоторому их последовательному (serial) выполнению.
Исключает:
- dirty reads,
- non-repeatable reads,
- phantom reads.
Реализуется через:
- блокировки диапазонов,
- или оптимистичные проверки конфликтов (как в PostgreSQL при Serializable Snapshot Isolation).
Цена:
- возможны рост числа блокировок, конфликтов и откатов;
- снижение пропускной способности под высокой конкуренцией.

Резюме:

Уровни: READ UNCOMMITTED < READ COMMITTED < REPEATABLE READ < SERIALIZABLE.
Самый высокий и строгий уровень — SERIALIZABLE.
В реальных системах выбор уровня — это компромисс:
- READ COMMITTED или REPEATABLE READ для большинства бизнес-операций,
- SERIALIZABLE точечно для критичных инвариантов, где недопустимы фантомы и сложные гонки.

Вопрос 20. Каков результат запроса с LEFT OUTER JOIN по идентификатору города для таблиц людей и городов?

Таймкод: 00:20:21

Ответ собеседника: неправильный. Вместо корректного описания результата LEFT JOIN фактически описал anti-join (людей без соответствующего города). После подсказки согласился, что это обычная склейка по ID, но исходное объяснение было неверным.

Правильный ответ:

LEFT OUTER JOIN (или просто LEFT JOIN) семантически означает:

Взять все строки из левой таблицы.
Для каждой строки найти совпадающие строки из правой таблицы по условию соединения.
Если совпадения есть — присоединить данные правой таблицы.
Если совпадений нет — вернуть строку из левой таблицы, а колонки правой заполнить NULL.

В нашем контексте:

Есть две таблицы, условно:

people(id, name, city_id)
cities(id, name)

Запрос:

SELECT p.id, p.name, c.name AS city_name
FROM people p
LEFT JOIN cities c ON p.city_id = c.id;

Семантика результата:

В результирующем наборе будут:
- все люди из таблицы people (левая таблица),
- к каждому — соответствующий город из cities по city_id = id, если он существует,
- если города с таким id нет, у этого человека будет city_name = NULL (и остальные поля c.* — тоже NULL).

Важно:

LEFT JOIN не отбрасывает людей без города.
LEFT JOIN не возвращает "только тех, у кого нет города" — это уже поведение anti-join, которое достигается, например, через LEFT JOIN ... WHERE c.id IS NULL.
LEFT JOIN гарантирует сохранение кардинальности левой таблицы:
- каждый человек появится в результате хотя бы один раз.
- при нескольких совпадениях городов (в теории, при некорректном моделировании) человек продублируется с разными городами.

Пример для ясности:

Данные:

people:

(1, 'Alice', 10)
(2, 'Bob', 20)
(3, 'Charlie', NULL)
(4, 'Diana', 30)

cities:

(10, 'London')
(20, 'Berlin')

Результат LEFT JOIN:

id |  name    | city_name
---+----------+-----------
1  | Alice    | London
2  | Bob      | Berlin
3  | Charlie  | NULL
4  | Diana    | NULL      -- так как city_id=30 не найден в cities

Для сравнения (анти-join по "люди без города"):

SELECT p.id, p.name
FROM people p
LEFT JOIN cities c ON p.city_id = c.id
WHERE c.id IS NULL;

Вернёт только тех людей, у кого:

либо city_id = NULL,
либо нет совпадающего города в таблице cities.

Резюме (что нужно ответить на интервью):

LEFT OUTER JOIN по city_id вернёт все строки из таблицы людей.
Для людей, у которых есть соответствующий город, подтянет данные города.
Для людей без подходящего города значения полей из таблицы городов будут NULL.

Вопрос 21. В чём разница между WHERE и HAVING при задании условий в SQL-запросе?

Таймкод: 00:23:16

Ответ собеседника: неполный. Фактически только переформулировал вопрос, не объяснив различия по этапам выполнения запроса и роли агрегаций.

Правильный ответ:

Разница между WHERE и HAVING связана с порядком выполнения SQL-запроса и уровнем данных, к которым применяется фильтрация.

Кратко:

WHERE фильтрует строки до агрегации.
HAVING фильтрует группы после агрегации.

Подробнее по шагам.

Логический порядок выполнения запроса (упрощённо):

FROM / JOIN — формируется исходный набор строк.
WHERE — фильтрация отдельных строк.
GROUP BY — группировка оставшихся строк.
HAVING — фильтрация уже сформированных групп.
SELECT — формирование списка выводимых столбцов/выражений.
ORDER BY / LIMIT — сортировка и ограничение результата.

Отсюда следуют ключевые различия:

WHERE

Применяется до GROUP BY, к "сырым" строкам.
Не может использовать агрегатные функции (COUNT, SUM, MAX, MIN, AVG) напрямую:
- это логически бессмысленно, агрегаты считаются по группам, которые ещё не сформированы.
Используется для фильтрации по обычным условиям:
- значения колонок,
- сравнения,
- IN, BETWEEN, LIKE и т.п.

Примеры:

Отобрать только активных пользователей:

SELECT *
FROM users
WHERE is_active = true;

Отобрать заказы только за 2024 год до агрегации:

SELECT user_id, SUM(amount) AS total_amount
FROM orders
WHERE order_date >= DATE '2024-01-01'
  AND order_date < DATE '2025-01-01'
GROUP BY user_id;

HAVING

Применяется после GROUP BY.
Работает с группами строк.
Может использовать агрегатные функции в условиях:
- фильтрация по результатам агрегации.
Используется, когда нужно "отсеять группы", а не отдельные строки.

Примеры:

Выбрать пользователей, у которых сумма заказов за период больше 1000:

SELECT user_id, SUM(amount) AS total_amount
FROM orders
WHERE order_date >= DATE '2024-01-01'
  AND order_date < DATE '2025-01-01'
GROUP BY user_id
HAVING SUM(amount) > 1000;

Здесь:

WHERE ограничивает диапазон данных до группировки;
HAVING выбирает только те группы (user_id), которые удовлетворяют условию по агрегату.

Выбрать города, в которых более 10 пользователей:

SELECT city_id, COUNT(*) AS users_count
FROM users
GROUP BY city_id
HAVING COUNT(*) > 10;

Частые ошибки и нюансы

Нельзя заменить WHERE на HAVING "просто так":
- HAVING обычно дороже логически/по плану выполнения, т.к. применяется после группировки.
HAVING без GROUP BY:
- формально допустим, применяется к "одной группе всех строк":
```
SELECT COUNT(*) AS total_users
FROM users
HAVING COUNT(*) > 100;
```
  Но это частный приём, используется реже.
Хорошая практика:
- Максимум фильтрации выносить в WHERE, чтобы уменьшить объём данных до агрегации.
- HAVING использовать только для условий на агрегаты или когда нужна логика именно на уровне групп.

Резюме для собеседования:

WHERE фильтрует отдельные строки до GROUP BY, агрегаты там использовать нельзя.
HAVING фильтрует группы после GROUP BY и позволяет использовать агрегатные функции в условиях.
Типичный паттерн: WHERE для предварительного отбора, HAVING — для фильтрации по результатам агрегации.

Вопрос 22. В чём различие между WHERE и HAVING при указании условий в SQL-запросе?

Таймкод: 00:23:21

Ответ собеседника: правильный. Объяснил, что WHERE фильтрует строки до группировки, а HAVING применяется после GROUP BY и фильтрует уже агрегированные данные.

Правильный ответ:

Суть различия:

WHERE:
- применяется на этапе фильтрации исходных строк;
- работает до GROUP BY и вычисления агрегатных функций;
- нельзя использовать агрегаты (COUNT, SUM, AVG, MAX, MIN) напрямую в WHERE, так как агрегаты считаются уже после группировки.
HAVING:
- применяется после GROUP BY;
- фильтрует не отдельные строки, а группы;
- как раз предназначен для условий с агрегатными функциями.

Классический пример:

Найти пользователей, у которых суммарная сумма заказов за 2024 год > 1000:

SELECT user_id, SUM(amount) AS total_amount
FROM orders
WHERE order_date >= DATE '2024-01-01'
  AND order_date < DATE '2025-01-01'   -- предварительная фильтрация строк
GROUP BY user_id
HAVING SUM(amount) > 1000;             -- фильтрация по агрегату для групп

Кратко:

WHERE — фильтрация "сырых" данных.
HAVING — фильтрация результатов агрегирования (групп).

Вопрос 23. Что представляют собой NoSQL базы данных и каковы их основные особенности?

Таймкод: 00:23:44

Ответ собеседника: неполный. Упомянул примеры (Redis, MongoDB, Cassandra), отметил key-value и документо-ориентированность, скорость и специализацию, но ответ вышел слишком общим и упрощённым.

Правильный ответ:

NoSQL — это обобщающее название для классов СУБД, которые отходят от классической реляционной модели (строгая схема, таблицы, JOIN, ACID-транзакции "из коробки") ради масштабируемости, гибкости схемы, высокой доступности и оптимизации под конкретные сценарии.

Ключевая идея: не "лучше SQL", а "заточено под конкретные модели данных и нагрузки". Часто ими решают задачи, где:

очень большие объёмы данных (big data),
высокая скорость записи/чтения,
горизонтальное масштабирование,
менее жёсткие требования к транзакционной согласованности.

Основные классы NoSQL-систем:

Key-Value хранилища

Модель:
- ассоциативный массив: key → value (опаковый blob или сериализованная структура).
Особенности:
- очень быстрый доступ по ключу;
- простая модель данных;
- легко шардируются и масштабируются.
Примеры:
- Redis, Memcached, Riak.
Типичные кейсы:
- кеши,
- сессии,
- счётчики, rate limiting,
- временные данные.
Особенности Redis:
- in-memory (с опциями персистентности),
- богатые структуры данных (строки, хэши, списки, множества, сортированные множества, стримы, pub/sub),
- часто используется как инфраструктурный элемент микросервисов.

Документо-ориентированные базы

Модель:
- данные хранятся как документы (чаще JSON/BSON).
- документ — самоописанная структура, поля могут различаться между документами одной коллекции.
Особенности:
- "schema-less" или schema-flexible:
  - можно эволюционировать структуру без миграций таблиц;
- хороши для агрегированных доменных объектов:
  - "пользователь + адреса + настройки" в одном документе.
Примеры:
- MongoDB, Couchbase, CouchDB.
Типичные кейсы:
- системы с быстро меняющейся моделью данных,
- event store, логирование, аналитика,
- контентные/каталожные сервисы (карточки товаров, профили).
Особенности MongoDB:
- индексирование по полям документов,
- агрегирующий фреймворк,
- репликация, шардинг,
- поддержка транзакций на уровне нескольких документов и коллекций (в новых версиях), но компромиссы в производительности.

Колонко-ориентированные (Wide-Column) базы

Модель:
- логика "таблиц" и "строк", но физически данные организованы по колонкам и семействам колонок;
- строки могут иметь разный набор колонок.
Особенности:
- оптимизированы под большие объёмы данных и распределённое хранение;
- эффективны для запросов по ключам и диапазонам;
- горизонтальное масштабирование по кластеру.
Примеры:
- Apache Cassandra, HBase, ScyllaDB.
Типичные кейсы:
- таймсерии, логи, метрики;
- high-write throughput системы;
- гео-распределённые инсталляции с требованиями к отказоустойчивости.
Особенности Cassandra:
- AP по CAP (ориентация на доступность и partition tolerance, с настраиваемой консистентностью),
- модель "write-optimized", log-structured storage,
- запросы проектируются "от чтения": ключи и кластерные колонки под конкретные паттерны чтения.

Графовые базы

Модель:
- вершины (nodes) и ребра (edges) + свойства;
- оптимизированы для сложных связей и навигации по графу.
Особенности:
- эффективны для запросов вида:
  - "друзья друзей",
  - "рекомендации",
  - "поиск путей" и т.п.
Примеры:
- Neo4j, JanusGraph, Amazon Neptune.
Типичные кейсы:
- социальные графы,
- рекомендательные системы,
- графы знаний,
- связи между сущностями (fraud detection, IAM-графы).

Ключевые особенности NoSQL в целом:

Гибкая схема (Schema flexibility)

Нет жёсткой схемы, как в реляционных БД:
- можно добавлять поля без миграций;
- разные записи могут иметь разные наборы полей.
Плюсы:
- быстрая эволюция модели,
- удобство при прототипировании.
Минусы:
- ответственность за целостность переносится в приложение;
- сложнее гарантировать инварианты и согласованность данных.

Масштабирование и доступность

Большинство NoSQL-систем спроектированы для горизонтального масштабирования:
- шардинг данных по нескольким узлам,
- репликация,
- работа в кластерах из десятков/сотен серверов.
Часто делают выбор в духе CAP:
- AP: высокая доступность и устойчивость к разделению сети, с eventual consistency (Cassandra, Riak);
- CP: строгая консистентность, но возможные паузы в доступности (HBase, некоторые режимы MongoDB).

Модель консистентности

В отличие от классических ACID по умолчанию:

Многие NoSQL-системы используют:
- eventual consistency,
- tunable consistency (можно выбрать на уровне операции: read/write quorum и т.п.).
Это даёт:
- высокую производительность и доступность,
- но данные могут временно быть не полностью согласованными между репликами.

Отсутствие универсальных JOIN

Большинство NoSQL не поддерживают "настоящие" JOIN как в реляционных БД.
Вместо этого:
- денормализация данных,
- хранение агрегированных структур (embed документов),
- запросы проектируются под паттерны доступа.
Это требует изменения мышления:
- сначала паттерны чтения/записи,
- потом структура данных.

Практический вывод для разработки:

NoSQL — инструмент, а не "религия":
- выбирать под конкретную задачу.
Реляционная БД лучше, когда:
- сложные транзакции,
- строгая консистентность,
- сложные запросы и JOIN,
- устойчивая, формализованная схема.
NoSQL лучше, когда:
- большие объёмы данных,
- простые ключевые запросы,
- высокая нагрузка на запись/чтение,
- гибкая схема,
- допускается eventual consistency и денормализация.

Простая матрица для интервью:

Redis — in-memory key-value / структуры данных, кеш, очереди, счётчики.
MongoDB — документо-ориентированная, JSON-подобные документы, хороша для агрегатов.
Cassandra — распределённая wide-column, высокая доступность и масштабирование.
Neo4j — графовая, для сложных связей.

Главное, что стоит показать:

понимание категорий NoSQL,
осознанное отношение к их сильным и слабым сторонам,
понимание, что выбор NoSQL/SQL — это инженерный трейд-офф, а не модный тренд.

Вопрос 24. В каких случаях предпочтительнее использовать реляционную базу данных, а в каких — NoSQL?

Таймкод: 00:24:36

Ответ собеседника: правильный. Отметил, что реляционные БД подходят при наличии чётких связей и структурированных сущностей, а NoSQL — для логов, сообщений и событий, где важны масштабирование и простое хранение без сложных связей.

Правильный ответ:

Выбор между реляционной СУБД и NoSQL — это инженерное решение на основе модели данных, требований к консистентности, сложности запросов, масштабирования и операционной нагрузки. Универсального ответа нет; важно понимать сильные стороны каждого подхода и типичные сценарии.

Когда выбирать реляционную базу данных (SQL):

Основные признаки:

Сложные и чётко определённые связи между сущностями:
- многие-ко-многим, каскадные связи, строгие внешние ключи.
- пример: пользователи → заказы → позиции заказов → товары.
Важна строгая консистентность и инварианты:
- баланс не должен уходить в минус;
- уникальность логина/почты;
- целостность ссылок (FOREIGN KEY).
Требуются сложные запросы и аналитика:
- JOIN нескольких таблиц,
- фильтрация по множеству критериев,
- агрегации, подзапросы, окна.
ACID-транзакции — ключевое требование:
- банковские операции,
- биллинг,
- бухгалтерский учёт,
- критичные бизнес-процессы.
Структура данных относительно стабильна:
- схема известна и эволюционирует управляемо через миграции.
Нагрузка хорошо масштабируется вертикально или через разумный шардинг/репликацию:
- не требуется экстремальный write-throughput в сотни тысяч операций в секунду на один логический объект.

Типичные примеры:

Финансовые системы.
CRM/ERP.
Order management, билеты, бронирования.
Любая система, где "ошибка в данных" дороже, чем задержка или сложность масштабирования.

Пример SQL-запроса с типичным использованием связей и агрегаций:

SELECT u.id,
       u.email,
       COUNT(o.id) AS orders_count,
       SUM(o.amount) AS total_amount
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.is_active = TRUE
GROUP BY u.id, u.email
HAVING SUM(o.amount) > 1000;

Когда выбирать NoSQL:

Здесь важно смотреть не на "модно", а на реальные требования.

Хорошие сигналы для NoSQL:

Высокая нагрузка и необходимость горизонтального масштабирования:
- терабайты/петабайты данных,
- десятки/сотни тысяч операций в секунду,
- геораспределенные кластеры.
Гибкая или слабо формализованная схема:
- поля часто меняются,
- разная структура у разных записей,
- нет желания гонять миграции под каждую эволюцию.
Преобладают простые операции:
- key → value,
- "дай документ по id",
- "дай записи по ключу/диапазону".
Допустима eventual consistency:
- система может жить с тем, что данные между репликами синхронизируются не мгновенно.
Данные естественно ложатся в документ/агрегат:
- один документ/запись содержит всё, что нужно для типичного запроса — минимизируем "join'ы на уровне приложения".

Типичные сценарии:

Логи, события, телеметрия, метрики:
- Cassandra, Elasticsearch, time-series БД.
Кеши и высокоскоростные структуры:
- Redis для сессий, токенов, rate limiting, очередей.
Документные данные:
- MongoDB для профилей пользователей, контента, JSON-конфигураций.
Графовые задачи:
- Neo4j и аналоги, когда главное — связи и пути, а не табличная модель.
Каталоги, конфигурации, где денормализация дешевле, чем сложные JOIN.

Примеры паттернов:

Event store / лог событий в NoSQL:
```
{
  "eventId": "uuid",
  "userId": "123",
  "type": "ORDER_CREATED",
  "payload": {...},
  "createdAt": "2025-01-01T10:00:00Z"
}
```
Хранятся в документо-ориентированном хранилище или log-структуре, читаются по ключам/диапазонам.

Кеш в Redis:

GET user:123:profile
SET user:123:profile {...}

Комбинированный подход (часто оптимальный):

Во многих зрелых системах используется не "SQL vs NoSQL", а "SQL и NoSQL":

Реляционная БД:
- источник истины (system of record),
- хранение критичных транзакционных данных.
NoSQL:
- кеши,
- индексы для поиска (Elasticsearch),
- отдельное хранилище логов и метрик,
- материализованные представления для быстрых чтений.

Примеры решений:

Платёжная система:
- PostgreSQL/MySQL для транзакций и балансов.
- Redis для кешей и rate limiting.
- Kafka + NoSQL/объектное хранилище для логов событий.
Интернет-магазин:
- Реляционная БД для заказов, оплат, каталогов (как master data).
- Elasticsearch для поиска по товарам.
- MongoDB или Redis для быстрых витрин, рекомендаций, сессий.

Краткий чек-лист для ответа на собеседовании:

SQL:
- строго структурированные данные,
- сложные связи и запросы,
- строгая консистентность,
- ACID критичен.
NoSQL:
- огромные объемы и горизонтальное масштабирование,
- простые паттерны доступа,
- гибкая схема,
- допускается eventual consistency,
- важны скорость и отказоустойчивость.

Главное — показать, что выбор хранилища — это осознанный трейд-офф под конкретные требования системы, а не догмат.

Вопрос 25. Что такое Hibernate и для чего он используется?

Таймкод: 00:25:39

Ответ собеседника: правильный. Определил Hibernate как ORM-надстройку над JDBC, маппящую объекты на таблицы и упрощающую работу с БД, упомянул нюансы вроде N+1 и кеширования.

Правильный ответ:

Hibernate — это ORM-фреймворк (Object-Relational Mapping) для Java, который решает задачу сопоставления объектной модели приложения с реляционной моделью базы данных. Он работает поверх JDBC и берёт на себя:

маппинг классов на таблицы;
маппинг полей на колонки;
генерацию SQL-запросов;
управление жизненным циклом сущностей;
кэширование;
транзакции и взаимодействие с различными СУБД.

Главная цель: позволить работать с данными на уровне объектов и доменной модели, а не вручную писать и поддерживать большое количество SQL/ JDBC-кода.

Ключевые концепции и возможности Hibernate:

ORM и маппинг сущностей

Классы-сущности помечаются аннотациями (javax.persistence / jakarta.persistence):

@Entity
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false, unique = true)
    private String email;

    @Column(nullable = false)
    private String name;

    // getters/setters
}

Hibernate автоматически:
- маппит User на таблицу users;
- поля на колонки;
- генерирует SQL для INSERT/UPDATE/DELETE/SELECT.

Работа через высокоуровневый API

Вместо ручного JDBC:

Управление сущностями через:
- EntityManager (JPA),
- Session (native Hibernate API),
- Spring Data репозитории.

Пример (JPA-стиль):

@PersistenceContext
private EntityManager em;

public User findUser(Long id) {
    return em.find(User.class, id);
}

public void createUser(String email, String name) {
    User u = new User();
    u.setEmail(email);
    u.setName(name);
    em.persist(u);
}

Hibernate:

сам сгенерирует SQL,
выполнит его через JDBC,
замапит результат обратно в User.

Управление связями между сущностями

Hibernate поддерживает ассоциации:

@OneToOne
@OneToMany
@ManyToOne
@ManyToMany

Пример:

@Entity
public class Order {
    @Id
    @GeneratedValue
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id")
    private User user;

    // ...
}

Особенности:

ленивые и жадные загрузки (LAZY / EAGER);
каскадные операции;
управление целостностью на уровне ORM.

Кеширование

Hibernate предоставляет многоуровневую систему кешей:

Первый уровень (Session/EntityManager):
- всегда включен;
- живет в рамках конкретной сессии/транзакции;
- гарантирует, что одна и та же сущность с тем же ID не будет загружаться дважды в рамках одной сессии.
Второй уровень (L2 cache):
- опционален;
- может быть разделён между сессиями и нодами;
- используется для уменьшения количества обращений к БД;
- интеграция с провайдерами (Ehcache, Infinispan, Hazelcast и др.).
Query Cache:
- кеширование результатов запросов.

Кеши — мощный инструмент, но требуют аккуратной настройки, понимания инвалидации и консистентности.

Транзакционность и интеграция

Hibernate:

интегрируется с JTA, Spring Transaction Management;
позволяет работать с локальными и глобальными транзакциями;
поддерживает разные диалекты SQL под разные СУБД (PostgreSQL, MySQL, Oracle, MSSQL и т.д.);
позволяет менять базу с минимальными изменениями в коде (если не завязаны на специфичный SQL).

Типичные преимущества использования Hibernate

Сокращение шаблонного кода:
- меньше ручного JDBC, маппинга ResultSet → объекты.
Централизация доменной модели:
- работа через сущности и связи;
- меньше разрывов между моделью и хранилищем.
Портируемость:
- диалекты под разные БД.
Богатая экосистема:
- Spring Data JPA,
- аудит, мульти-тенантность,
- фильтры, interceptors, callbacks.

Важные подводные камни (которые стоит знать):

Для зрелого использования Hibernate необходимо понимать:

N+1 problem:
- при LAZY-связях наивный перебор коллекций может приводить к множеству дополнительных запросов.
- решается:
  - JOIN FETCH,
  - EntityGraph,
  - батч-фетчинг, DTO-проекции.
Управление сессией и контекстом персистентности:
- когда сущность managed/detached;
- что такое "dirty checking";
- почему нельзя бездумно держать огромный persistence context.
Ленивые загрузки и LazyInitializationException:
- попытка обратиться к ленивой коллекции вне активной сессии:
  - требует грамотного проектирования границ транзакций,
  - или использования fetch-стратегий/DTO.
Правильная реализация equals/hashCode для сущностей:
- особенно с прокси и отложенным присвоением ID;
- бизнес-ключи vs суррогатные ключи.

Резюме (что важно ответить на собеседовании):

Hibernate — это ORM-фреймворк для Java, работающий поверх JDBC.
Он маппит объекты на таблицы и автоматизирует:
- CRUD-операции,
- работу со связями,
- транзакции,
- кэширование.
Даёт выигрыш в скорости разработки и выразительности доменной модели, но требует понимания его внутренней механики (lazy loading, N+1, кеши, транзакции), чтобы избежать типичных проблем производительности и консистентности.

Вопрос 26. Какие уровни кеширования существуют в Hibernate и как они работают?

Таймкод: 00:26:42

Ответ собеседника: неполный. Упомянул кэш первого и второго уровня, но не смог чётко описать их работу и частично перепутал с механизмами кеширования Spring (Spring Cache, аннотации).

Правильный ответ:

В Hibernate существует несколько уровней кеширования, каждый из которых решает свою задачу и работает на разном уровне абстракции. Базово нужно уверенно знать:

кэш первого уровня (Session / Persistence Context),
кэш второго уровня (SessionFactory-level),
кэш запросов (Query Cache),

и чётко отличать их от внешнего кеширования (например, Spring Cache).

Разберем по уровням.

Кэш первого уровня (L1 Cache, Session Cache)

Основные характеристики:

Всегда включен.
Неотделим от Session (Hibernate) или EntityManager (JPA).
Область видимости: одна сессия / один persistence context.

Семантика:

Когда вы загружаете сущность через session.get() / em.find():
- первый запрос к БД:
  - сущность помещается в L1;
- повторные запросы за ту же сущность (по тому же ID) в рамках той же сессии:
  - вернут объект из кэша, без повторного похода в БД.
L1-кэш также используется для:
- управления идентичностью (одна сущность с данным ID в сессии представлена одним объектом),
- dirty checking (отслеживание изменений и генерация UPDATE при flush).

Пример:

Session session = sessionFactory.openSession();
session.getTransaction().begin();

User u1 = session.get(User.class, 1L);  // SELECT к БД
User u2 = session.get(User.class, 1L);  // из L1-кэша, без SELECT

System.out.println(u1 == u2); // true

session.getTransaction().commit();
session.close();

После закрытия Session / EntityManager кэш первого уровня уничтожается.

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

Кэш второго уровня (L2 Cache, Second Level Cache)

Основные характеристики:

Опционален; включается сознательно.
Область видимости: на уровне SessionFactory (Hibernate) / всего приложения:
- разделяется между разными сессиями в пределах одного инстанса приложения;
- может быть кластеризован (в зависимости от провайдера).
Работает для:
- сущностей,
- коллекций ассоциаций (опционально),
- "нативных" Hibernate структур.

Назначение:

Уменьшение количества обращений к БД для часто читаемых сущностей.
Особенно полезно для:
- справочников,
- редко изменяемых сущностей,
- данных, которые часто читаются многими запросами.

Подключение и провайдеры:

Сам Hibernate не хранит L2-кэш, он интегрируется с внешними провайдерами:
- Ehcache / Ehcache 3,
- Infinispan,
- Hazelcast,
- Caffeine (через адаптеры),
- и др.

Пример конфигурации (понятия):

В persistence.xml / application.properties:
- включаем второй уровень кэша и кэш сущностей;

Аннотации на сущностях:

@Entity
@Cacheable
@org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public class Country {
    @Id
    private Long id;

    private String name;
}

Поведение:

При первом чтении сущности:
- данные берутся из БД и кладутся в L2.
При последующих чтениях в других сессиях:
- если сущность есть в L2 и не протухла — будет взята оттуда без обращения к БД.

Стратегии конкурентного доступа (CacheConcurrencyStrategy):

READ_ONLY:
- только для неизменяемых данных (идеально для справочников).
NONSTRICT_READ_WRITE:
- допускает небольшую рассинхронизацию.
READ_WRITE:
- баланс консистентности и производительности.
TRANSACTIONAL:
- для интеграции с JTA и транзакционно-осознанным кэшем.

Важно:

L2-кэш сложнее, чем L1:
- нужно продумывать, какие сущности кэшировать,
- следить за инвалидацией,
- учитывать влияние на консистентность.

Кэш запросов (Query Cache)

Основные характеристики:

Опционален, включается отдельно.
Используется совместно с L2-кэшем.
Кэширует не сами сущности целиком, а результаты конкретных HQL/JPQL/Criteria-запросов:
- список идентификаторов и/или простых значений.

Работа:

При первом выполнении кэшируемого запроса:
- результат сохраняется в Query Cache.
При повторном выполнении с теми же параметрами:
- результат может быть взят из Query Cache.

Но:

Query Cache зависит от L2-кэша:
- он хранит не полные сущности, а ссылки (ID),
- при выдаче результатов сущности достаются из L2 или БД.
Требует аккуратной конфигурации:
- высокая чувствительность к изменениям данных,
- возможен overhead на инвалидацию.

Пример (Hibernate API):

List<User> users = session.createQuery("FROM User u WHERE u.active = true", User.class)
    .setCacheable(true)
    .list();

Отличие от Spring Cache и прочих внешних кешей

Важно не путать:

Кэш Hibernate:
- встроен в ORM, осведомлён о сущностях, их состоянии, транзакциях;
- работает на уровне JPA/Hibernate.
Spring Cache (@Cacheable, @CacheEvict и т.п.):
- абстракция над разными кеш-провайдерами для произвольных методов;
- не является частью Hibernate, хотя может использовать те же провайдеры (Ehcache, Redis и т.д.);
- оперирует результатами методов, а не контекстом персистентности.

Они могут сосуществовать, но это разные уровни и механики.

Резюме для собеседования:

Уровни кеширования в Hibernate:
- Кэш первого уровня (Session / EntityManager):
  - всегда включен,
  - живет в рамках одной сессии,
  - гарантирует уникальность экземпляров сущностей и уменьшает лишние запросы.
- Кэш второго уровня (на уровне SessionFactory):
  - общий для всех сессий,
  - опционален,
  - требует конфигурации и провайдера,
  - используется для кэширования сущностей и коллекций между транзакциями.
- Кэш запросов (Query Cache):
  - опционален,
  - кэширует результаты запросов (списки ID/значений),
  - работает совместно с L2-кэшем сущностей.
Понимать:
- область видимости каждого уровня,
- когда он очищается,
- как влияет на консистентность и когда его стоит использовать.
Не путать внутренние кэши Hibernate с внешними кеширующими механизмами (Spring Cache, Redis как аппликативный кеш и т.п.).

Вопрос 27. Чем отличается Spring от Spring Boot?

Таймкод: 00:28:18

Ответ собеседника: правильный. Объяснил, что Spring — это основной фреймворк и экосистема модулей, а Spring Boot упрощает работу со Spring за счёт автоконфигурации, стартеров и управляемых версий зависимостей.

Правильный ответ:

Spring и Spring Boot находятся в отношениях "ядро/экосистема" и "надстройка/ускоритель разработки". Ключевое отличие не в функциональности как таковой, а в уровне абстракции и уровне "боевой готовности" приложения.

Spring (Core Framework):

Это фундаментальная платформа для построения Java-приложений.
Ключевые возможности:
- Inversion of Control (IoC) / Dependency Injection (DI):
  - управление жизненным циклом бинов и зависимостями.
- Aspect-Oriented Programming (AOP):
  - кросс-срезы: транзакции, логирование, безопасность.
- Модули:
  - Spring Core / Context,
  - Spring MVC,
  - Spring Data,
  - Spring Security,
  - Spring JDBC, Spring ORM,
  - и многое другое.
Особенности без Boot:
- разработчик сам:
  - выбирает зависимости,
  - настраивает XML/Java-конфигурацию,
  - конфигурирует DataSource, EntityManagerFactory, TransactionManager,
  - поднимает контейнер (веб-сервер) или деплоит в контейнер приложений.
- высокая контролируемость, но много инфраструктурного кода.

Spring Boot:

Это opinionated-надстройка над Spring.
Цель:
- минимизировать рутину настройки,
- дать "production-ready" приложение с минимальным количеством конфигурации.
Ключевые идеи:
1. Автоконфигурация:
  - На основе зависимостей в classpath и настроек (application.yml/properties) Boot сам поднимает и настраивает:
    - веб-сервер (Tomcat/Jetty/Undertow),
    - DataSource,
    - JPA/Hibernate,
    - Spring MVC, Jackson, Validation,
    - Security (по умолчанию тоже).
  - Можно переопределять через явные @Bean или настройки.
2. Стартеры (spring-boot-starter-*):
  - Наборы согласованных зависимостей под конкретные задачи:
    - spring-boot-starter-web
    - spring-boot-starter-data-jpa
    - spring-boot-starter-security
    - spring-boot-starter-actuator
  - Это избавляет от ручного подбора версий и совместимости.
3. Встроенный сервер:
  - Приложение запускается как jar:
    java -jar app.jar
  - Нет необходимости деплоить в отдельный Tomcat/Jetty (WAR, контейнер приложений);
  - Удобно для микросервисной архитектуры и контейнеризации (Docker/Kubernetes).
4. Production-ready фичи:
  - Spring Boot Actuator:
    - метрики,
    - health-check,
    - info, логирование,
    - эндпоинты для мониторинга и управления.
  - Упрощение интеграции с observability-стеком.

Семантическое различие:

Spring:
- фреймворк и экосистема;
- даёт фундаментальные механизмы (DI, AOP, MVC, Data и т.д.);
- требует больше ручной конфигурации и глубокого понимания внутренних механизмов.
Spring Boot:
- способ быстро собрать приложение на Spring:
  - "Spring с батарейками";
  - упрощённая конфигурация, преднастроенные зависимости.
- сам по себе не заменяет Spring, а использует его:
  - под капотом — всё тот же Spring Framework.

Кратко для собеседования:

Spring — это ядро и набор модулей, предоставляющих инфраструктурные возможности.
Spring Boot — это надстройка, которая:
- автоматизирует и стандартизирует конфигурацию Spring-приложений,
- предоставляет стартеры и автоконфигурацию,
- позволяет быстро запускать готовые к продакшну сервисы.
Все "магии" Boot основаны на тех же принципах Spring (DI, конфиг, контекст), просто с более удобным входом и сильным opinionated default.

Вопрос 28. Какие два ключевых архитектурных принципа лежат в основе Spring?

Таймкод: 00:29:24

Ответ собеседника: правильный. Назвал Inversion of Control и Dependency Injection как базовые принципы.

Правильный ответ:

Два ключевых архитектурных принципа, на которых строится Spring:

Inversion of Control (IoC)
Dependency Injection (DI)

Они тесно связаны, но не тождественны.

Inversion of Control (IoC):

Идея:
- Вместо того чтобы объект сам создавал и управял зависимостями, управление этим процессом "переворачивается" и отдаётся внешнему контейнеру.
В классическом императивном стиле:
```
class Service {
    private final Repository repo;

    Service() {
        this.repo = new JdbcRepository(); // жёсткая связка
    }
}
```
Здесь сервис сам решает, какую реализацию использовать — высокая связность, сложность тестирования и подмены реализаций.
При IoC:
- код описывает "что ему нужно", а не "как это создать";
- контейнер (Spring IoC Container/ApplicationContext) управляет:
  - созданием объектов (бинов),
  - их конфигурацией,
  - жизненным циклом,
  - внедрением зависимостей.
Польза:
- ослабление связности,
- тестируемость (подмена реализаций, моки),
- переиспользуемость и конфигурируемость.

Dependency Injection (DI):

Конкретный механизм реализации IoC.
Суть:
- зависимости передаются объекту "снаружи":
  - через конструктор,
  - через сеттер,
  - через поля (в Spring чаще через конструктор/сеттер, поля — как синтаксический сахар).

Пример с DI через конструктор в Spring:

@Component
class JdbcUserRepository implements UserRepository {
    // ...
}

@Component
class UserService {

    private final UserRepository userRepository;

    // конструктор вызывается контейнером Spring,
    // реализация подставляется автоматически
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public User getById(Long id) {
        return userRepository.findById(id);
    }
}

Spring:
- сканирует компоненты,
- создает бин JdbcUserRepository,
- видит, что UserService зависит от UserRepository,
- внедряет подходящую реализацию.

Ключевые моменты, которые важно понимать на практике:

IoC — это принцип: "контейнер управляет вами, а не вы контейнером".
DI — основной паттерн реализации этого принципа в Spring.
Это обеспечивает:
- слабую связанность между компонентами (зависимость от интерфейсов, а не конкретных классов),
- удобное тестирование (можно подменять зависимости),
- масштабируемую архитектуру (легко добавлять новые реализации, конфигурации, профили окружений),
- декларативные возможности (транзакции, безопасность, AOP) поверх DI/IoC.

Таким образом, фундамент Spring — это управляемый контейнер (IoC) и декларативное внедрение зависимостей (DI), на которых строится всё остальное: конфигурирование, модули, автоконфигурация в Spring Boot и интеграция с внешними системами.

Вопрос 29. Зачем использовать внедрение зависимостей (Dependency Injection), а не создавать зависимости напрямую в классе?

Таймкод: 00:30:29

Ответ собеседника: правильный. Указал на снижение связности, удобство поддержки, управление жизненным циклом контейнером, возможность прокси и AOP, облегчение изменений и тестирования.

Правильный ответ:

Внедрение зависимостей (Dependency Injection, DI) — это практический способ реализовать слабую связанность, модульность и тестируемость системы. В отличие от ручного создания зависимостей через new внутри класса, DI позволяет делегировать создание и связывание объектов внешнему контейнеру (например, Spring IoC), что даёт ряд критически важных преимуществ.

Ключевые причины использовать DI вместо "new внутри":

Ослабление связности и зависимость от абстракций

Плохой подход:

class OrderService {
    private final OrderRepository orderRepository = new JdbcOrderRepository();
}

Проблемы:

Жёсткая привязка к конкретной реализации JdbcOrderRepository.
Сложно подменить реализацию (например, на in-memory, JPA, mock, remote).
Любое изменение реализации требует правки кода класса.

С DI:

interface OrderRepository {
    Order findById(Long id);
}

@Component
class JdbcOrderRepository implements OrderRepository { ... }

@Component
class OrderService {
    private final OrderRepository orderRepository;

    public OrderService(OrderRepository orderRepository) {
        this.orderRepository = orderRepository;
    }
}

Преимущества:

OrderService зависит от интерфейса, а не от реализации.
Реализацию можно заменить конфигурацией (другой бин, профиль окружения).
Это фундамент для расширяемости и clean architecture.

Тестируемость и удобство мокинга

При new-внедрении:

Для модульного теста приходится:
- либо цепляться к реальной БД/инфраструктуре,
- либо переписывать код, менять конструкторы.

С DI:

@Test
void testOrderService() {
    OrderRepository mockRepo = Mockito.mock(OrderRepository.class);
    Mockito.when(mockRepo.findById(1L)).thenReturn(new Order(...));

    OrderService service = new OrderService(mockRepo);
    // тестируем в изоляции без реальной БД
}

Итог:

Лёгкие модульные тесты.
Минимум инфраструктурных зависимостей.
Поведение можно детерминированно контролировать.

Централизованное управление жизненным циклом объектов

Контейнер DI:

отвечает за:
- создание бинов,
- инициализацию (включая зависимости),
- уничтожение (грейсфул shutdown, закрытие соединений, пулов),
- обёртывание прокси (транзакции, security, логирование).

Пример:

В Spring транзакции, кеширование, security часто навешиваются декларативно через аннотации:
```
@Transactional
public void processOrder(Long id) { ... }
```
Контейнер оборачивает бин в прокси:
- до/после вызова метода включаются транзакции, логирование, хендлеры.
Если бы зависимости создавались вручную:
- пришлось бы явно управлять всем этим в коде,
- увеличивая boilerplate и вероятность ошибок.

Конфигурируемость и профили окружений

С DI:

Конфигурация зависимостей уходит из бизнес-кода наружу:
- файлы конфигурации,
- профили (dev, test, prod),
- переменные окружения, feature-флаги.

Пример:

В dev использовать in-memory БД, в prod — PostgreSQL:

@Profile("dev")
@Bean
DataSource h2DataSource() { ... }

@Profile("prod")
@Bean
DataSource postgresDataSource() { ... }

OrderService об этом ничего не знает — он просто получает DataSource/Repository от контейнера.

Расширяемость и AOP без модификации бизнес-кода

DI-контейнер позволяет прозрачно внедрять:

логирование,
метрики,
аудит,
кэширование,
ретраи,
security-проверки,
распределённые трассировки.

Через прокси / AOP:

можно оборачивать методы/бины без изменения их реализации;
код бизнес-логики остаётся чистым.

Пример (кеширование):

@Cacheable("users")
public User getUser(Long id) {
    // без DI пришлось бы вручную дергать кеш, ручной контроль
}

Контейнер сам:

проверит кеш,
при необходимости обратится к репозиторию,
положит результат в кеш.

Явные зависимости вместо скрытых

DI стимулирует хороший дизайн:

через конструктор видно, что именно нужно классу:

public OrderService(OrderRepository repo,
                    PaymentService payment,
                    NotificationService notification) { ... }

если зависимостей становится слишком много:
- это сигнал к рефакторингу (слишком "толстый" сервис).

При new-внедрении обычно зависимости "размазываются" и прячутся внутри.

Резюме для собеседования:

DI используется не ради "магии Spring", а для:
- снижения связности,
- облегчения тестирования,
- конфигурируемости и подмены реализаций,
- централизации управления жизненным циклом и инфраструктурой,
- прозрачной интеграции AOP/транзакций/кешей/безопасности.
Создание зависимостей напрямую (new внутри бизнес-класса) делает код жёстко связанным, плохо тестируемым и трудным для эволюции. DI решает именно эти архитектурные проблемы.

Вопрос 30. Какие области видимости (scopes) бинов в Spring ты знаешь и как они работают?

Таймкод: 00:31:43

Ответ собеседника: неполный. Назвал singleton и prototype, упомянул request и session, но неуверенно и без чёткого понимания полного набора и поведения.

Правильный ответ:

В Spring scope определяет жизненный цикл и область видимости бина: кто, когда и как его создаёт и переиспользует. Корректное понимание скоупов важно для thread-safety, работы с веб-контекстом и проектирования архитектуры.

Базовые (core) скоупы Spring:

singleton

Значение по умолчанию.
Один экземпляр бина на весь Spring-контейнер (ApplicationContext).
Создаётся (по умолчанию) при поднятии контекста (eager initialization, можно изменить на lazy).
Все зависимости, которым внедряется этот бин, получают один и тот же экземпляр.

Пример:

@Component
public class AppConfigService {
    // один объект на приложение
}

Особенности:

Должен быть потокобезопасным, если используется в многопоточном окружении.
Основной scope для stateless-сервисов, конфигураций, клиентов к внешним системам, репозиториев и т.п.

prototype

Новый экземпляр бина при каждом запросе к контейнеру:
- при каждом applicationContext.getBean(...);
- при каждом внедрении в другой бин (если не используется проксирование).
Spring создаёт объект, внедряет зависимости и "отпускает":
- дальше управление жизненным циклом на стороне клиента.

Пример:

@Component
@Scope("prototype")
public class TaskContext {
    // новый объект на каждый запрос к контейнеру
}

Особенности и подводные камни:

В отличие от singleton, Spring не управляет полным жизненным циклом (нет автоматического уничтожения).
При внедрении prototype в singleton напрямую:
- prototype создаётся один раз на момент создания singleton.
- Если требуется новый prototype на каждый вызов — нужен:
  - ObjectFactory<T>, Provider<T>,
  - или proxy-скоуп (proxyMode).
Используется редко и осознанно: когда нужен "одноразовый" объект с DI, но жизненный цикл контролирует код.

Веб-скоупы (актуальны в Web / Spring MVC / Spring WebFlux контекстах):

request

Один бин на один HTTP-запрос.
Доступен только в рамках обработки конкретного запроса.
Создаётся в начале запроса, уничтожается по завершении.

Пример:

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class RequestContext {
    // данные, специфичные для запроса (например, traceId)
}

Особенности:

Требует прокси при внедрении в singleton, иначе бин вне запроса не существует.
Удобен для хранения контекста запроса, локализации, метаданных.

session

Один бин на одну HTTP-сессию пользователя.
Живёт столько, сколько жива сессия.

Пример:

@Component
@Scope(value = "session", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class UserSessionData {
    // данные, привязанные к сессии пользователя
}

Особенности:

Также требует прокси при внедрении в singleton.
Подходит для сессионных данных, если вы сознательно используете сессии.

application (web-application scope)

Один бин на весь ServletContext (по сути, на всё веб-приложение).
Похож на singleton, но живёт в границах веб-контейнера.

@Component
@Scope("application")
public class AppWideState {
    // общий для всех запросов и сессий в рамках приложения
}

Расширенные / специфичные скоупы:

websocket

Один бин на WebSocket-сессию (в Spring WebSocket).
Используется для состояния, привязанного к WS-соединению.

@Scope("websocket")
@Component
public class WebSocketSessionContext {
    // состояние на соединение
}

Прокси и смешивание скоупов:

Ключевой нюанс, который важно понимать на уровне опытного разработчика:

Когда бин с более длинным жизненным циклом (например, singleton) зависит от бина с более коротким жизненным циклом (request, session, prototype), прямое внедрение приведет к семантически неверному поведению:
- бин с коротким сроком "зафиксируется" при создании singleton.
Для корректной работы используются:
- scoped proxy (proxyMode = ScopedProxyMode.TARGET_CLASS / INTERFACES),
- фабрики (ObjectFactory, Provider),
- ленивая резолюция из контекста.

Пример с прокси:

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class RequestContext { ... }

@Component
public class SomeService {
    private final RequestContext requestContext;

    public SomeService(RequestContext requestContext) {
        this.requestContext = requestContext; // фактически сюда внедряется прокси
    }
}

Прокси при каждом запросе делегирует к реальному экземпляру RequestContext для текущего HTTP-запроса.

Резюме, которое стоит уверенно озвучить на собеседовании:

Основные скоупы Spring:
- singleton — один на контейнер, по умолчанию.
- prototype — новый экземпляр при каждом запросе к контейнеру.
- request — один на HTTP-запрос.
- session — один на HTTP-сессию.
- application — один на веб-приложение (ServletContext).
- websocket — один на WebSocket-сессию.
Важно понимать:
- область видимости,
- кто управляет жизненным циклом,
- как правильно комбинировать скоупы (scoped proxy, фабрики),
- что singleton — основной рабочий scope для stateless-сервисов,
- а скоупы уровня веба и prototype используются точечно под конкретные задачи.

Вопрос 31. Гарантирует ли скоуп singleton потокобезопасность бина в Spring?

Таймкод: 00:32:51

Ответ собеседника: правильный. Чётко указал, что сам по себе singleton не делает бин потокобезопасным.

Правильный ответ:

Скоуп singleton в Spring гарантирует только то, что в пределах одного ApplicationContext будет создан один экземпляр бина и все зависимости, запрашивающие этот бин, получат ссылку на этот же объект.

Но:

сам по себе singleton никак не гарантирует потокобезопасность;
Spring не добавляет автоматическую синхронизацию, блокировки или другие механизмы защиты.

Ключевые моменты:

Почему singleton не равен thread-safe

В веб-приложении или сервисе singleton-бин, как правило, используется множеством потоков одновременно:
- каждый HTTP-запрос, каждый обработчик задач, каждый worker может обращаться к одному и тому же бинy.
Если бин:
- хранит изменяемое состояние (mutable fields),
- использует небезопасные коллекции,
- изменяет внутренние поля без синхронизации — это приводит к гонкам данных, некорректным значениям, трудноуловимым багам.

Пример потенциально опасного singleton-бина:

@Component
public class UnsafeCounterService {

    private int counter = 0;

    public void increment() {
        counter++; // неатомарно, незащищённо
    }

    public int getCounter() {
        return counter;
    }
}

При конкурирующих вызовах increment() значение будет теряться, хотя бин — singleton.

Как правильно проектировать singleton-бины в Spring

Рекомендации:

Делать singleton-бины по возможности stateless:
- все данные — во входных параметрах методов и локальных переменных;
- не хранить пользовательское или запрос-специфичное состояние в полях.
Если состояние необходимо:
- использовать потокобезопасные структуры данных (ConcurrentHashMap, Atomic*, LongAdder и т.п.);
- явно синхронизировать доступ (но осознанно, учитывая блокировки и производительность);
- или выносить состояние в бины с более узким scope (request, session, prototype) либо в внешние системы (БД, кэши).

Пример корректного stateless-сервиса:

@Component
public class PriceCalculator {

    public BigDecimal calculatePrice(BigDecimal base, BigDecimal discount) {
        return base.subtract(discount); // нет общего изменяемого состояния
    }
}

Когда нужна явная потокобезопасность

Если singleton управляет общим состоянием (например, кэш, пул, регистры), нужно:

использовать:
- ConcurrentHashMap,
- CopyOnWriteArrayList,
- AtomicReference,
- синхронизированные блоки/lock-и,
или делегировать безопасное хранение внешнему компоненту (БД, Redis, message broker и т.п.).

Пример:

@Component
public class SafeCache {

    private final ConcurrentHashMap<String, String> cache = new ConcurrentHashMap<>();

    public String get(String key) {
        return cache.get(key);
    }

    public void put(String key, String value) {
        cache.put(key, value);
    }
}

Резюме:

Скоуп singleton в Spring означает "один экземпляр на контейнер", но не "автоматически потокобезопасен".
Ответ, который ожидается: "нет, потокобезопасность — ответственность разработчика; singleton-бины должны проектироваться как stateless или с явно безопасной работой с состоянием".

Вопрос 32. Будет ли вызываться метод с аннотацией @PreDestroy у бина со скоупом prototype?

Таймкод: 00:33:21

Ответ собеседника: неправильный. Считает, что метод @PreDestroy должен вызываться, но не понимает, когда и как; не учитывает, что для prototype-объектов Spring не управляет фазой уничтожения.

Правильный ответ:

По умолчанию у бина со скоупом prototype метод с аннотацией @PreDestroy не вызывается контейнером Spring.

Ключевой принцип:

Для singleton-бинов Spring:
- создаёт экземпляр,
- управляет полным жизненным циклом (инициализация, уничтожение),
- при остановке контекста вызывает методы:
  - @PreDestroy,
  - DisposableBean.destroy(),
  - кастомные destroy-методы, указанные в конфигурации.
Для prototype-бинов:
- Spring только создает бин и возвращает его вызывающему коду;
- дальнейшая жизнь объекта — ответственность клиента;
- контейнер не отслеживает, когда бин больше не нужен, поэтому:
  - не вызывает @PreDestroy,
  - не выполняет destroy-коллбеки автоматически.

Официальная логика жизненного цикла:

Singleton:
- создание → инициализация → (использование) → уничтожение (destroy callbacks вызываются Spring).
Prototype:
- создание → инициализация → (использование) → уничтожение (ответственность кода, Spring не вызывает destroy).

Практические следствия:

Если в prototype-бине есть ресурсы, требующие явного закрытия:
- соединения,
- потоки,
- файлы,
- хендлеры,
- любые внешние ресурсы,
то вы обязаны:
- либо управлять ими вручную,
- либо использовать другой scope,
- либо внедрить их через singleton/инфраструктурные бины, которые корректно завершаются.

Если всё же нужно корректно завершать prototype-бины:

Можно реализовать явный протокол освобождения ресурсов:
- интерфейс с методом close() / destroy() и вызывать его в коде.
Либо использовать:
- @Lookup / фабрики бинов + управляемые обертки,
- или зарегистрировать DestructionAwareBeanPostProcessor (редко и точечно).

Резюме для собеседования:

Ответ: нет, для prototype-бина Spring не вызывает @PreDestroy автоматически.
Уничтожение prototype-объектов — зона ответственности кода, который их использует.
@PreDestroy и destroy-коллбеки гарантированно работают только для бинов, за уничтожение которых отвечает контейнер (в первую очередь singleton).

Вопрос 33. Для исключений какого типа по умолчанию произойдёт автоматический откат транзакции при использовании @Transactional?

Таймкод: 00:34:33

Ответ собеседника: неправильный. Сомневался между checked и unchecked исключениями и не сформулировал корректное правило.

Правильный ответ:

По умолчанию при использовании аннотации @Transactional (Spring) транзакция автоматически откатывается в следующих случаях:

при выбросе непроверяемых (unchecked) исключений:
- всех, наследующихся от RuntimeException;
- а также при Error.

Для проверяемых (checked) исключений (наследников Exception, но не RuntimeException):

по умолчанию автоматического отката НЕ происходит;
если нужно откатывать транзакцию при checked-исключении, это необходимо явно указать в настройках @Transactional.

Ключевые правила Spring @Transactional по умолчанию:

Откат происходит:
- для RuntimeException и всех его подклассов:
  - IllegalArgumentException,
  - NullPointerException,
  - DataAccessException (и его наследники),
  - и т.п.
- для Error:
  - OutOfMemoryError,
  - StackOverflowError,
  - и т.п. (как крайние случаи, после которых приложение обычно в неустойчивом состоянии).
Откат не происходит автоматически:
- для checked-исключений:
  - IOException,
  - SQLException,
  - TimeoutException,
  - пользовательские checked-исключения, расширяющие Exception, но не RuntimeException.
- В этих случаях транзакция по умолчанию будет зафиксирована (commit), если не указано иное.
Как изменить поведение:

Если нужно откатывать транзакцию при checked-исключениях, это конфигурируется так:

@Transactional(rollbackFor = Exception.class)
public void process() throws Exception {
    // при любом Exception (checked/unchecked) будет rollback
}

Или точечно для конкретного типа:

@Transactional(rollbackFor = {CustomCheckedException.class})
public void process() throws CustomCheckedException {
    // откат при CustomCheckedException
}

Также можно, наоборот, запретить откат для некоторых unchecked-исключений:

@Transactional(noRollbackFor = {IllegalArgumentException.class})
public void process() {
    // при IllegalArgumentException транзакция не откатывается
}

Почему так сделано:

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

Резюме:

По умолчанию @Transactional откатывает транзакцию при RuntimeException и Error.
Checked-исключения не приводят к откату, если явно не настроено rollbackFor.

Вопрос 34. Как на концептуальном уровне работает @Transactional в Spring?

Таймкод: 00:36:23

Ответ собеседника: неполный. Описал транзакции на уровне JDBC (открытие, удержание блокировок, коммит), но не раскрыл ключевой механизм работы @Transactional через прокси и аспектно-ориентированное программирование в Spring.

Правильный ответ:

Концептуально @Transactional в Spring — это декларативное управление транзакциями на основе AOP (аспектно-ориентированного программирования) и прокси. Аннотация сама по себе "ничего не делает", она служит маркером для инфраструктуры Spring, которая оборачивает вызовы методов в транзакционные границы.

Высокоуровневый жизненный цикл выглядит так:

Конфигурация транзакционного менеджера

В приложении настраивается PlatformTransactionManager:

Например:
- DataSourceTransactionManager — для JDBC.
- JpaTransactionManager — для JPA/Hibernate.
- ChainedTransactionManager, JTA и др. — для более сложных сценариев.

Пример для JPA (часто Spring Boot делает это автоматически):

@Bean
public PlatformTransactionManager transactionManager(EntityManagerFactory emf) {
    return new JpaTransactionManager(emf);
}

Создание прокси вокруг бина с @Transactional

Когда Spring видит бин с методами, аннотированными @Transactional:

создаётся прокси-объект вместо прямого экземпляра бина:
- JDK dynamic proxy (если есть интерфейс),
- или CGLIB proxy (класс-наследник), если интерфейса нет или настроено соответствующим образом.
Прокси перехватывает вызовы методов и решает:
- нужно ли открывать/закрывать транзакцию,
- как настроить propagation, read-only, timeout и т.п.

Важно:

Транзакционность применяется при вызове метода через прокси.
Внутренний self-call (метод того же класса вызывает свой @Transactional-метод напрямую) прокси не задевает → аннотация в таком случае не сработает без дополнительных подходов.

Вызов метода: как работает обёртка

Когда клиент вызывает:

orderService.processOrder(orderId);

и метод помечен @Transactional, прокси делает примерно следующее (упрощённо):

Проверяет, есть ли уже активная транзакция.
Смотрит настройки @Transactional:
- propagation (например, REQUIRED, REQUIRES_NEW),
- readOnly,
- rollback правила.
Если нужно — открывает новую транзакцию через PlatformTransactionManager:
- для JDBC: setAutoCommit(false),
- для JPA: открытие/привязка EntityManager к текущему потоку,
- настройка контекста (Session, EntityManager, Connection).
Вызывает реальный метод бина.
Анализирует результат:
- если метод завершился успешно:
  - выполняет commit;
- если произошло исключение:
  - сверяет тип исключения с правилами отката:
    - по умолчанию rollback для RuntimeException и Error;
    - для checked-исключений — только если указано rollbackFor;
  - при необходимости делает rollback.
Освобождает ресурсы:
- отвязывает транзакцию/EntityManager/Connection от потока,
- возвращает соединения в пул.

Механика на уровне JDBC / Hibernate

Под капотом (внутри транзакционного менеджера):

Для JDBC:
- начинается транзакция на Connection:
  - conn.setAutoCommit(false);
- все операции INSERT/UPDATE/DELETE/SELECT идут в рамках этого соединения;
- при коммите → conn.commit(),
- при откате → conn.rollback().
Для JPA/Hibernate:
- создаётся или привязывается EntityManager к текущему потоку;
- Hibernate начинает транзакцию (beginTransaction()),
- операции с сущностями накапливаются в persistence context,
- при коммите:
  - происходит flush изменений → SQL,
  - commit на уровне JDBC;
- при откате:
  - rollback на JDBC-транзакции,
  - сброс состояния persistence context.

Важные практические моменты

Что нужно знать на уровне архитектуры:

Транзакция привязана к потоку:
- Spring использует ThreadLocal-контекст для хранения текущей транзакции.
- В асинхронных вызовах (@Async, реактивное программирование) требуется другая модель — обычный @Transactional на императивный способ не "протечет" в другой поток.
Внутренние вызовы методов:
- this.someTransactionalMethod() внутри того же класса минует прокси:
  - аннотация не срабатывает;
- решения:
  - выносить транзакционные методы в отдельный бин,
  - или использовать AopContext/self-injection (осознанно).
Read-only транзакции:
- @Transactional(readOnly = true):
  - может оптимизировать поведение ORM (Hibernate может отключать dirty checking),
  - на уровне JDBC не всегда блокирует запись, но это сигнал о намерениях.
Propagation:
- Определяет поведение, если уже есть активная транзакция:
  - REQUIRED (по умолчанию): использовать текущую или создать новую;
  - REQUIRES_NEW: приостановить текущую, создать новую;
  - MANDATORY, SUPPORTS, NOT_SUPPORTED, NEVER, NESTED.

Краткий концептуальный ответ (что ожидается услышать):

@Transactional — декларативная обёртка вокруг вызова метода, реализованная через прокси и AOP.
При входе в метод:
- прокси (через PlatformTransactionManager) открывает или использует существующую транзакцию.
При успешном завершении:
- транзакция коммитится.
При исключении (по правилам rollback):
- транзакция откатывается.
Механика прозрачна для бизнес-кода:
- код описывает "границы" транзакции и правила,
- инфраструктура Spring управляет соединениями, EntityManager'ами и commit/rollback.

Вопрос 35. Как можно разделить монолитный интернет-магазин на микросервисы?

Таймкод: 00:37:40

Ответ собеседника: правильный. Предложил выделить сервисы для авторизации и пользователей, каталога товаров, платежей, заказов и доставки, исходя из функционального разбиения домена.

Правильный ответ:

Разделение монолитного интернет-магазина на микросервисы должно основываться не на технических слоях (controller/service/repository), а на доменных областях (bounded contexts) и бизнес-возможностях (business capabilities). Ключевая цель — чтобы каждый сервис отвечал за чётко определённую часть предметной области, имел собственные данные и мог развиваться независимо.

Ниже — типичный и осмысленный вариант декомпозиции с краткими акцентами.

Основные принципы:

Один микросервис — одна явная бизнес-функция / bounded context.
Собственная база данных у каждого сервиса:
- никаких общих схем "на всех";
- коммуникация между сервисами — через API/события, а не через общие таблицы.
Слабая связанность, явные контракты, асинхронное взаимодействие там, где возможно.
Избегать "микро-монолита", где один сервис всё равно знает обо всех.

Примерная декомпозиция интернет-магазина:

Identity / Auth / User Management

Отвечает за:

регистрацию, аутентификацию (login, logout),
управление учётными записями,
роли/права доступа,
токены (JWT, session, refresh).

Особенности:

Своя база пользователей.
Остальные сервисы доверяют ему через:
- токены,
- внутренний Auth API,
- интеграцию с gateway / OAuth2 / OpenID Connect.

Catalog Service (Продукты и категории)

Отвечает за:

товары, категории, атрибуты,
цены (если нет отдельного Pricing),
доступность товара для отображения.

Особенности:

Собственная модель данных:
- товары, категории, SEO, описания, изображения (часто через внешнее хранилище).
Только владелец правды о товарах.
Остальные сервисы (Cart, Orders) не лезут в его БД, а ходят за данными по API или используют закэшированные/реплицированные представления.

Inventory Service (Склад и остатки)

Часто выносят отдельно от каталога.

Отвечает за:

учёт остатков по складам,
резервы при оформлении заказов,
списание при оплате/отгрузке.

Особенности:

Высокие требования к целостности.
Может использовать оптимистичные/пессимистичные блокировки, события для синхронизации.

Cart Service (Корзина)

Отвечает за:

корзины пользователей,
добавление/удаление товаров,
промо-логика на уровне корзины (частично).

Особенности:

Данные могут быть менее "критичными", часто живут в:
- Redis,
- отдельном быстром хранилище.
Не должен напрямую зависеть от внутренней схемы Catalog:
- брать слепок данных о товаре на момент добавления (название, цена) или ID и подтягивать актуальное при оформлении.

Order Service (Заказы)

Отвечает за:

создание заказа из корзины,
статусный автомат (created, pending payment, paid, shipped, canceled, refunded),
связь с пользователем, адресом, позициями заказа.

Особенности:

Собственная база заказов.
Интеграция:
- с Payment (для статуса оплаты),
- с Inventory (резерв/списание),
- с Delivery/Shipping (статусы доставки).
Чёткий жизненный цикл и события:
- OrderCreated, OrderPaid, OrderShipped, OrderCancelled.

Payment Service (Платежи)

Отвечает за:

интеграции с платёжными провайдерами,
инициацию платежей,
обработку callback’ов,
хранение статусов платежей (authorized, captured, failed, refunded).

Особенности:

Изолировать платежную логику и интеграции.
Не хранить критичные платёжные данные в других сервисах.
При успешной оплате — публиковать событие (OrderPaid), а не лезть в базу заказов напрямую.

Shipping / Delivery Service (Доставка)

Отвечает за:

расчёт стоимости и сроков доставки,
выбор служб доставки,
трекинг отправлений,
статусы доставки.

Особенности:

Интегрируется с Order Service через события и/или API.
Может общаться с внешними службами доставки.

Notification Service (Уведомления)

Отвечает за:

E-mail, SMS, push, мессенджеры.
Шаблоны уведомлений (Order Created, Paid, Shipped, Password Reset и т.п.).

Особенности:

Получает события от других сервисов:
- не вшивать отправку писем прямо в Order/Payment.
Масштабируется и изменяется независимо.

Promo / Pricing / Recommendation (опционально)

Отдельные сервисы для:

промокоды, скидки, акции,
динамическое ценообразование,
рекомендации товаров.

Могут быть вынесены позже, когда логика усложнится.

Ключевые архитектурные моменты:

Собственные хранилища

Каждый сервис владеет своими таблицами/коллекциями.
Никаких cross-service JOIN по БД.
Для аналитики:
- использовать отдельный Data Warehouse / DWH и ETL/CDC.

Взаимодействие между сервисами

Синхронные запросы:
- REST/gRPC для запросов, где нужен немедленный ответ.
Асинхронные события:
- Kafka/RabbitMQ/NATS для доменных событий (OrderCreated, PaymentSucceeded, etc.);
- позволяет развязать сервисы и облегчить эволюцию.

Границы ответственности

Каждый сервис:
- владеет своей бизнес-логикой,
- сам обеспечивает целостность в своих границах,
- не знает о внутренностях чужих БД.

Эволюционный подход

Не делить "всё и сразу".
Начать с монолита + модульная архитектура:
- чёткие модули: auth, catalog, orders, payments.
Затем выделять микросервисы по зрелым bounded contexts:
- Order, Payment, Catalog и т.д.
Обязательно:
- мониторинг, логирование, трассировка, централизованная конфигурация, сервис-дискавери, API-gateway.

Резюме (кратко, как ожидали бы услышать):

Разбивать по доменным контекстам, а не по техническим слоям.
Типичные сервисы: Auth/User, Catalog, Inventory, Cart, Order, Payment, Shipping, Notification.
Каждый сервис:
- со своей БД,
- с чётким контрактом,
- взаимодействует через API/события.
Делать это эволюционно, с учётом операционных и бизнес-требований, а не "ради микросервисов".

Вопрос 36. Для исключений какого типа по умолчанию выполняется автоматический откат транзакции при использовании @Transactional?

Таймкод: 00:34:33

Ответ собеседника: неправильный. Долго колебался между checked и unchecked исключениями и не дал точного ответа.

Правильный ответ:

По умолчанию при использовании @Transactional в Spring транзакция автоматически откатывается в двух случаях:

при выбросе любого непроверяемого (unchecked) исключения:
- всех наследников RuntimeException;
при выбросе Error.

Для проверяемых (checked) исключений, то есть наследников Exception, не являющихся RuntimeException, автоматический откат транзакции по умолчанию НЕ выполняется.

Ключевые моменты:

Правило по умолчанию:

Откат (rollback) выполняется:
- для RuntimeException и всех его подклассов:
  - NullPointerException, IllegalArgumentException, IllegalStateException,
  - DataAccessException (и производные),
  - любые ваши CustomRuntimeException, и т.п.
- для Error:
  - OutOfMemoryError, StackOverflowError и др. (хотя в реальности после них жить системе часто уже проблематично).
Откат НЕ выполняется автоматически:
- для checked-исключений:
  - IOException, SQLException, TimeoutException,
  - любых ваших CustomCheckedException extends Exception.

Как изменить поведение явно:

Если вам нужно, чтобы транзакция откатывалась и при checked-исключении:

@Transactional(rollbackFor = Exception.class)
public void process() throws Exception {
    // при любом Exception произойдёт rollback
}

Или точечно:

@Transactional(rollbackFor = {CustomCheckedException.class})
public void process() throws CustomCheckedException {
    // rollback при CustomCheckedException
}

Если, наоборот, вы не хотите откатывать транзакцию при некоторых unchecked-исключениях:

@Transactional(noRollbackFor = {IllegalArgumentException.class})
public void process() {
    // при IllegalArgumentException транзакция НЕ откатывается
}

Почему так спроектировано:

Непроверяемые (RuntimeException) обычно означают программную ошибку или критическую ситуацию, при которой логично откатить все изменения.
Checked-исключения считаются ожидаемыми ситуационными ошибками, для которых разработчик может явно решить:
- откатывать транзакцию,
- обрабатывать и продолжать,
- трансформировать в RuntimeException и т.п.

Резюме:

Правильный ответ: по умолчанию откат выполняется для unchecked (RuntimeException) и Error, но не для checked-исключений.

Вопрос 37. Как в общем виде работает механизм @Transactional при выполнении метода?

Таймкод: 00:36:23

Ответ собеседника: неполный. Описывает только транзакции на уровне JDBC (открытие, блокировки, коммит), но не объясняет, что @Transactional реализован через прокси и аспектно-ориентированное программирование в Spring.

Правильный ответ:

Механизм @Transactional в Spring — это декларативное управление транзакциями на базе:

транзакционного менеджера (PlatformTransactionManager),
динамических прокси,
аспектно-ориентированного программирования (AOP).

Ключевая идея: вы объявляете границы транзакции аннотацией, а инфраструктура Spring прозрачно оборачивает вызов метода в логику начала/коммита/отката транзакции.

Общий принцип работы по шагам:

Настройка транзакционного менеджера

В контексте должен быть настроен PlatformTransactionManager:

для JDBC: DataSourceTransactionManager;
для JPA/Hibernate: JpaTransactionManager;
для JTA или распределённых транзакций — соответствующий менеджер.

Spring Boot обычно конфигурирует его автоматически.

Создание прокси вокруг бина

Когда Spring видит бин с методами, аннотированными @Transactional:

вместо прямого экземпляра класса регистрируется прокси:
- JDK dynamic proxy (если бин представлен через интерфейс),
- или CGLIB-прокси (наследник класса), если используется проксирование по классу.
Этот прокси перехватывает вызовы методов и перед выполнением реального метода добавляет транзакционную логику.

Важно:

Транзакция срабатывает только при вызове через прокси.
Внутренние вызовы методов (self-invocation), например this.otherTransactionalMethod(), не проходят через прокси → @Transactional там не отработает.

Логика выполнения @Transactional-метода

Когда внешний код вызывает:

service.doWork();

и doWork() помечен @Transactional, происходит примерно следующее (упрощённо):

Прокси перехватывает вызов.
На основе параметров аннотации и текущего контекста:
- проверяет, есть ли уже активная транзакция;
- применяет правила propagation (например, REQUIRED, REQUIRES_NEW и т.д.);
Если нужно начать новую транзакцию:
- вызывает transactionManager.getTransaction(...):
  - для JDBC: выключает auto-commit, привязывает Connection к текущему потоку;
  - для JPA: создаёт/привязывает EntityManager, открывает транзакцию.
Вызывает реальный метод бина внутри открытой транзакции.
После завершения метода:
- если метод завершился без исключения:
  - выполняется commit транзакции;
- если было выброшено исключение:
  - проверяется тип исключения и настройки:
    - по умолчанию rollback для RuntimeException и Error,
    - для checked-исключений — rollback только если указан rollbackFor;
  - при подходящем исключении вызывается rollback.
После коммита/отката:
- транзакционный контекст отвязывается от потока;
- соединения возвращаются в пул;
- EntityManager/Session закрывается или возвращается в пул (зависит от режима).

Связь с JDBC / JPA / Hibernate

@Transactional — уровень Spring. Под ним:

для JDBC:
- управляет Connection (auto-commit=false, commit/rollback);
для JPA/Hibernate:
- управляет EntityManager/Session и соответствующей JDBC-транзакцией;
- обеспечивает корректный flush перед коммитом.

Важные нюансы, которые нужно знать:

Self-invocation:
- вызов транзакционного метода из другого метода того же класса не проходит через прокси;
- @Transactional в этом случае не сработает.
- Решения: вынос в отдельный бин, self-инъекция прокси и т.п.
Привязка к потоку:
- контекст транзакции хранится в ThreadLocal;
- в асинхронных/реактивных сценариях нужен другой подход (обычный @Transactional не "переезжает" между потоками автоматически).
readOnly и propagation:
- readOnly = true — подсказка для ORM и иногда для драйверов;
- propagation определяет поведение при вложенных вызовах.

Краткое резюме (формулировка для интервью):

@Transactional реализуется через AOP-прокси вокруг бина.
При входе в аннотированный метод прокси через PlatformTransactionManager открывает или использует существующую транзакцию.
При успешном завершении метода — коммит, при соответствующем исключении — rollback.
Логика транзакций отделена от бизнес-кода и задаётся декларативно, но важно понимать нюансы прокси, propagation, правил rollback и границ транзакции.

Вопрос 38. На какие микросервисы имеет смысл разделить монолитный интернет-магазин?

Таймкод: 00:37:42

Ответ собеседника: правильный. Предложил выделить сервисы для авторизации и пользователей, каталога товаров, платежей и заказов/доставки, демонстрируя осмысленное доменное разбиение.

Правильный ответ:

Разделение монолита интернет-магазина на микросервисы должно опираться на доменные области (bounded contexts) и бизнес-функции, а не на технические слои (controller/service/repository). Правильная декомпозиция минимизирует связность, локализует изменения и позволяет масштабировать критичные части независимо.

Ниже — типичное и обоснованное разбиение.

Основные принципы разбиения:

Каждый сервис отвечает за законченную бизнес-функцию.
У каждого сервиса — своя база данных (schema per service).
Нет общих таблиц и прямых cross-service JOIN.
Взаимодействие через API и/или события.
Декомпозировать эволюционно, начиная с явных bounded contexts.

Рекомендуемое разбиение интернет-магазина:

Auth / Identity Service

Зона ответственности:

Регистрация, логин/логаут.
Хранение пользователей и их учетных данных.
Выдача токенов (JWT/OAuth2/OpenID Connect).
Управление ролями и правами.

Особенности:

Источник истины по аутентификации.
Остальные сервисы доверяют ему по токенам / introspection.

User Profile Service (опционально, если отделить от Auth)

Зона ответственности:

Профиль пользователя (имя, телефон, адреса, настройки).
Может быть отделен от Auth, чтобы не смешивать учетные данные и бизнес-данные.

Catalog Service

Зона ответственности:

Товары, категории, атрибуты, изображения.
Базовые цены (если нет выделенного Pricing).
Видимость товара (активен/нет, в продаже/нет).

Особенности:

Только этот сервис знает структуру и правила каталога.
Остальные берут данные о товарах через API/кеш/реплику, а не напрямую из БД.

Inventory Service

Зона ответственности:

Остатки на складах.
Резервирование товара под заказ.
Списание при оплате/отгрузке.

Особенности:

Критичен для целостности.
Можно реализовать через события:
- OrderCreated → резерв;
- OrderCancelled → снять резерв;
- OrderPaid → окончательное списание.

Cart Service

Зона ответственности:

Корзина пользователя:
- список позиций,
- количества,
- возможные промо.
Логика обновления корзины.

Особенности:

Данные могут быть в Redis/NoSQL.
Часто не требует жёстких транзакций между сервисами.
При оформлении заказа Cart → Order (слепок на момент создания).

Order Service

Зона ответственности:

Создание заказов из корзины.
Жизненный цикл заказа:
- created → pending payment → paid → shipped → completed / cancelled.
Хранение позиций заказа, суммы, статусов.

Особенности:

Интеграция с Payment, Inventory, Shipping через API/события.
Самостоятельно владеет состоянием заказа, не лезет в чужие БД.

Payment Service

Зона ответственности:

Интеграция с платёжными провайдерами.
Инициация платежей, обработка callback’ов.
Учёт статуса платежей:
- authorized, captured, failed, refunded.

Особенности:

Не обновляет заказы напрямую в БД Orders.
Публикует события:
- PaymentSucceeded → Order Service меняет статус на paid.
- PaymentFailed → Order Service → отмена/ожидание.

Shipping / Delivery Service

Зона ответственности:

Расчет доставки (стоимость/сроки).
Интеграция с курьерскими службами.
Статусы отправлений:
- подготовлен, передан в службу, в пути, доставлен.

Особенности:

Работает с заказами через идентификаторы, не через их таблицу.
Публикует события о статусах доставки.

Notification Service

Зона ответственности:

Отправка email/SMS/push/мессенджеров.
Шаблоны уведомлений:
- регистрация,
- подтверждение заказа,
- оплата,
- отправка, доставка.

Особенности:

Подписывается на события (OrderCreated, PaymentSucceeded, и т.п.).
Не содержит бизнес-логики заказа, только коммуникации.

Promo / Pricing / Recommendation (по мере усложнения домена)

Promo Service:
- Купоны, скидки, акции.
Pricing Service:
- Динамическое ценообразование.
Recommendation Service:
- Рекомендации на основе поведения пользователя.

Ключевые архитектурные акценты:

Своя БД у каждого сервиса:
- Пример: Orders в PostgreSQL, Cart в Redis, Catalog в MongoDB/SQL — в зависимости от задач.
Взаимодействие:
- Синхронно: REST/gRPC для запросов, требующих немедленного ответа.
- Асинхронно: через брокер сообщений (Kafka/RabbitMQ/NATS) для событий домена.
Целостность:
- Не распределённые ACID-транзакции, а саги/оркестрация/хореография:
  - создание заказа, резерв товара, оплата, подтверждение.
Эволюция:
- сначала выделять крупные, чётко различимые контексты (Auth, Catalog, Orders, Payments),
- потом при росте нагрузки и сложности дробить дальше.

Такой подход показывает зрелое понимание:

разделение по бизнес-домену,
независимость данных и логики,
использование событий / API вместо общих таблиц,
эволюционный переход от монолита к микросервисам.

Вопрос 1. Какой класс является базовым предком всех объектов в Java?​

Вопрос 2. Какие ключевые методы определены в классе Object?​

Вопрос 3. Что возвращает метод hashCode и как он связан с объектом?​

Вопрос 4. Какие правила необходимо соблюдать при реализации метода hashCode?​

Вопрос 5. Зачем нужен метод hashCode, почему недостаточно equals?​

Вопрос 6. Какие основные виды коллекций существуют в Java и как они различаются?​

Вопрос 7. Как на базовом уровне устроен HashMap внутри?​

Вопрос 8. Можно ли использовать null в качестве ключа в HashMap и какой для него используется hashCode?​

Вопрос 9. Какие типы операций есть в Stream API и что произойдет, если не вызвать терминальную операцию?​

Вопрос 10. Можно ли переопределить статический метод при наследовании классов?​

Вопрос 11. В чём семантическая разница между интерфейсом и абстрактным классом?​

Вопрос 12. В чём заключается разница по назначению между интерфейсом и абстрактным классом?​

Вопрос 13. Что в Java отвечает за автоматическую очистку памяти?​

Вопрос 14. Как определяется, что объект стал мусором и может быть удалён сборщиком мусора?​

Вопрос 15. Какую роль играет ключевое слово volatile в контексте многопоточности?​

Вопрос 16. Если три потока по 500 раз инкрементируют общее volatile int-поле, гарантировано ли получение результата 1500?​

Вопрос 17. Что такое рефлексия в Java?​

Вопрос 18. Что означает аббревиатура ACID и в чём суть её свойств для транзакций?​

Вопрос 19. Какие уровни изоляции транзакций существуют и какой из них является самым высоким?​

Вопрос 20. Каков результат запроса с LEFT OUTER JOIN по идентификатору города для таблиц людей и городов?​

Вопрос 21. В чём разница между WHERE и HAVING при задании условий в SQL-запросе?​

Вопрос 22. В чём различие между WHERE и HAVING при указании условий в SQL-запросе?​

Вопрос 23. Что представляют собой NoSQL базы данных и каковы их основные особенности?​

Вопрос 24. В каких случаях предпочтительнее использовать реляционную базу данных, а в каких — NoSQL?​

Вопрос 25. Что такое Hibernate и для чего он используется?​

Вопрос 26. Какие уровни кеширования существуют в Hibernate и как они работают?​

Вопрос 27. Чем отличается Spring от Spring Boot?​

Вопрос 28. Какие два ключевых архитектурных принципа лежат в основе Spring?​

Вопрос 29. Зачем использовать внедрение зависимостей (Dependency Injection), а не создавать зависимости напрямую в классе?​

Вопрос 30. Какие области видимости (scopes) бинов в Spring ты знаешь и как они работают?​

Вопрос 31. Гарантирует ли скоуп singleton потокобезопасность бина в Spring?​

Вопрос 32. Будет ли вызываться метод с аннотацией @PreDestroy у бина со скоупом prototype?​

Вопрос 33. Для исключений какого типа по умолчанию произойдёт автоматический откат транзакции при использовании @Transactional?​

Вопрос 34. Как на концептуальном уровне работает @Transactional в Spring?​

Вопрос 35. Как можно разделить монолитный интернет-магазин на микросервисы?​

Вопрос 36. Для исключений какого типа по умолчанию выполняется автоматический откат транзакции при использовании @Transactional?​

Вопрос 37. Как в общем виде работает механизм @Transactional при выполнении метода?​

Вопрос 38. На какие микросервисы имеет смысл разделить монолитный интернет-магазин?​

Вопрос 1. Какой класс является базовым предком всех объектов в Java?

Вопрос 2. Какие ключевые методы определены в классе Object?

Вопрос 3. Что возвращает метод hashCode и как он связан с объектом?

Вопрос 4. Какие правила необходимо соблюдать при реализации метода hashCode?

Вопрос 5. Зачем нужен метод hashCode, почему недостаточно equals?

Вопрос 6. Какие основные виды коллекций существуют в Java и как они различаются?

Вопрос 7. Как на базовом уровне устроен HashMap внутри?

Вопрос 8. Можно ли использовать null в качестве ключа в HashMap и какой для него используется hashCode?

Вопрос 9. Какие типы операций есть в Stream API и что произойдет, если не вызвать терминальную операцию?

Вопрос 10. Можно ли переопределить статический метод при наследовании классов?

Вопрос 11. В чём семантическая разница между интерфейсом и абстрактным классом?

Вопрос 12. В чём заключается разница по назначению между интерфейсом и абстрактным классом?

Вопрос 13. Что в Java отвечает за автоматическую очистку памяти?

Вопрос 14. Как определяется, что объект стал мусором и может быть удалён сборщиком мусора?

Вопрос 15. Какую роль играет ключевое слово volatile в контексте многопоточности?

Вопрос 16. Если три потока по 500 раз инкрементируют общее volatile int-поле, гарантировано ли получение результата 1500?

Вопрос 17. Что такое рефлексия в Java?

Вопрос 18. Что означает аббревиатура ACID и в чём суть её свойств для транзакций?

Вопрос 19. Какие уровни изоляции транзакций существуют и какой из них является самым высоким?

Вопрос 20. Каков результат запроса с LEFT OUTER JOIN по идентификатору города для таблиц людей и городов?

Вопрос 21. В чём разница между WHERE и HAVING при задании условий в SQL-запросе?

Вопрос 22. В чём различие между WHERE и HAVING при указании условий в SQL-запросе?

Вопрос 23. Что представляют собой NoSQL базы данных и каковы их основные особенности?

Вопрос 24. В каких случаях предпочтительнее использовать реляционную базу данных, а в каких — NoSQL?

Вопрос 25. Что такое Hibernate и для чего он используется?

Вопрос 26. Какие уровни кеширования существуют в Hibernate и как они работают?

Вопрос 27. Чем отличается Spring от Spring Boot?

Вопрос 28. Какие два ключевых архитектурных принципа лежат в основе Spring?

Вопрос 29. Зачем использовать внедрение зависимостей (Dependency Injection), а не создавать зависимости напрямую в классе?

Вопрос 30. Какие области видимости (scopes) бинов в Spring ты знаешь и как они работают?

Вопрос 31. Гарантирует ли скоуп singleton потокобезопасность бина в Spring?

Вопрос 32. Будет ли вызываться метод с аннотацией @PreDestroy у бина со скоупом prototype?

Вопрос 33. Для исключений какого типа по умолчанию произойдёт автоматический откат транзакции при использовании @Transactional?

Вопрос 34. Как на концептуальном уровне работает @Transactional в Spring?

Вопрос 35. Как можно разделить монолитный интернет-магазин на микросервисы?

Вопрос 36. Для исключений какого типа по умолчанию выполняется автоматический откат транзакции при использовании @Transactional?

Вопрос 37. Как в общем виде работает механизм @Transactional при выполнении метода?

Вопрос 38. На какие микросервисы имеет смысл разделить монолитный интернет-магазин?