First
1
Second
6

Размер:3

@EqualsAndHashCode // в качестве примера взял аннотацию из lombok
public class First {

}

@EqualsAndHashCode
class Second extends First {

}

HashMap — это массив корзин. Индекс выбираем по hashCode, а столкновения (коллизии) решаем сравнениями через equals.

Алгоритм вставки:

1. Считаем hashCode() и определяем корзину.

2. Если корзина пуста - вставляем.

3. Если в корзине есть элементы:

   • ищем тот же ключ через equals

   • если найден → заменяем значение

   • если нет → добавляем новый элемент (список → дерево при >8 элементов)

4. При заполненности > loadFactor происходит resize.

Зачем нужны бинарные деревья:
Чтобы хранить данные в отсортированном виде и быстро выполнять поиск, вставку и удаление.

Сложность поиска в BST:

• лучший случай (сбалансировано): O(log n)

• худший случай (вырождено в список): O(n)

Сложность вставки:

• лучший случай: O(log n)

• худший случай: O(n)

Serial GC

• Использует один поток для всех фаз GC.

• Подходит для однопоточных приложений и небольших heap.

• Алгоритм: "copying" (в Young Gen) и "mark-sweep-compact" (в Old Gen).

• Параметр: -XX:+UseSerialGC

Parallel GC (Throughput Collector)

• Использует несколько потоков для работы в Young и Old Gen.

• Цель — максимальная пропускная способность, а не минимизация пауз.

• Подходит для серверных приложений без строгих требований к задержкам.

• Параметр: -XX:+UseParallelGC

CMS (Concurrent Mark Sweep) [устарел]

• Работает параллельно с приложением (concurrent), уменьшая stop-the-world паузы.

• Этапы: initial mark, concurrent mark, remark, sweep.

• Не компактизирует память (может привести к фрагментации).

• Устарел начиная с Java 9 и удалён в Java 14

• Параметр: -XX:+UseConcMarkSweepGC

G1 GC (Garbage First)

• Делит heap на множество регионов.

• Каждый регион может быть частью Young или Old Generation.

• Этапы GC включают: Initial Mark, Concurrent Mark, Remark, Cleanup, Copy.

• Работает по принципу "сборка сначала самых мусорных регионов" (Garbage First).

• Использует предсказуемые паузы и старается не превышать MaxGCPauseMillis

• Поддерживает инкрементальную, concurrent и компактизирующую сборку Old Gen.

• G1 ведёт статистику "полезности" регионов и выбирает наиболее эффективные для сборки.

• Параметр: -XX:+UseG1GC

• По умолчанию используется с Java 9+

ZGC (Z Garbage Collector)

• Поддерживает heap до терабайт.

• Работает с паузами менее 10 мс, независимо от размера heap.

• Полностью concurrent (почти все фазы выполняются параллельно с приложением).

• Подходит для latency-чувствительных систем.

• Параметр: -XX:+UseZGC

Shenandoah

• Похож на ZGC, с акцентом на короткие паузы.

• Использует concurrent compacting.

• Поддерживается OpenJDK.

• Параметр: -XX:+UseShenandoahGC

Strong Reference (сильная ссылка)

• Это обычные ссылки, которые мы используем каждый день.

• Пока на объект существует хотя бы одна сильная ссылка - он не подлежит сборке мусора.

• Чтобы объект мог быть собран, все сильные ссылки на него должны быть обнулены.

Object obj = new Object();

Soft Reference (мягкая ссылка)

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

• Используется в кешах, чтобы не загружать память, но сохранить объект, если он ещё полезен.

• Можно получить объект через ref.get(), но если GC уже удалил его - вернётся null.

SoftReference<Object> ref = new SoftReference<>(new Object());

Weak Reference (слабая ссылка)

• Объект может быть собран немедленно, даже если только слабые ссылки на него остались.

• Используется для реализации структур с автоудалением (например, WeakHashMap).

• Часто применяется, когда объект должен быть доступен «до тех пор, пока он кому-то нужен».

WeakReference<Object> ref = new WeakReference<>(new Object());

Phantom Reference (фантомная ссылка)

• Объект уже помечен как удаляемый, но ещё не собран GC.

• Метод get() всегда возвращает null.

• Используется для контроля финализации и освобождения ресурсов вне heap (например, off-heap, native).

• Требует ReferenceQueue, через которую можно узнать, что объект вот-вот будет удалён.

PhantomReference<Object> ref = new PhantomReference<>(new Object(), referenceQueue);

1) CompletableFuture - позволяет запускать асинхронные задачи, комбинировать их, цеплять колбэки и работать без блокировок. Упрощает параллелизм.

2) ConcurrentHashMap - потокобезопасный HashMap. Позволяет многим потокам одновременно читать и обновлять данные без общего большого локa.

3) Phaser - продвинутый синхронизатор, позволяет синхронизировать потоки по фазам (этапам). Гибче, чем CyclicBarrier/CountDownLatch.

4) AtomicInteger - примитив для атомарных операций над int без использования локов (CAS). Нужен для счетчиков, флагов и инкрементов между потоками.

5) ReentrantLock - явная блокировка с расширенными возможностями: tryLock, fairness, condition-переменные. Более гибкая альтернатива synchronized.

Deadlock (взаимная блокировка)

Потоки навсегда блокируют друг друга, каждый ждёт ресурс, удерживаемый другим.
Итог: система стоит, прогресса нет.

Пример:
Поток A держит ресурс 1 и ждёт ресурс 2.
Поток B держит ресурс 2 и ждёт ресурс 1.

Как избегать:

1. Всегда блокировать ресурсы в одном порядке.

2. Использовать таймауты при захвате блокировок (tryLock(timeout)).

3. Минимизировать количество одновременно захватываемых блокировок.

Livelock (ожившая блокировка)

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

Пример:
Два потока уступают друг другу ресурс, отказываются и пытаются снова, но синхронно, и бесконечно.

Как избегать:

1. Добавлять рандомные задержки или экспоненциальный бэкофф при повторных попытках.

2. Использовать явные таймауты и прекращать попытки через определённое время.

3. Пересматривать алгоритм кооперации, чтобы не блокировать друг друга непрерывно.

Мой запрос выглядит так:

SELECT
    c.name AS company_name,
    SUM(p.price) AS product_sum
FROM client c
JOIN product p ON c.id = p.client_id
WHERE c.is_active
GROUP BY c.id, c.name
HAVING SUM(p.price) > 0
ORDER BY product_sum DESC;

Время применения

• WHERE - фильтрация до группировки (на уровне отдельных строк)

• HAVING - фильтрация после группировки (на уровне групп)

С чем работают

• WHERE - работает с отдельными записями и обычными полями

• HAVING - работает с результатами агрегатных функций (SUM, COUNT, AVG и т.д.)

Использование с GROUP BY

• WHERE - может использоваться без GROUP BY

• HAVING - используется вместе с GROUP BY

EXPLAIN PLAN — это план выполнения SQL-запроса, показывающий, какие операции СУБД будет выполнять (сканирование таблицы, использование индекса, типы join’ов и т.д.). Он нужен для понимания того, где находятся узкие места и что можно оптимизировать — например, добавить индекс, поменять тип соединения или переписать запрос.

Есть прекрасная табличка из официальной:

Здесь можно сразу предложить несколько вариантов по аналогии с транзакциями

1. Сделать self inject и вызвать метод через него

2. Использовать applicationContext.getBean(CacheClass.class);

Для @Transaction это было 100% сработало бы, но в Cacheable есть подводный камень.

Ни один из верхних вариантов не сработает. Подумай еще, как можно это решить?

@Service
@EnableCaching
public class CacheClass implements ApplicationRunner {

    @Autowired
    @Lazy
    private CacheClass self;
    
    @Override
    public void run(ApplicationArguments args) throws Exception {
        System.out.println(self.test(1));
        Thread.sleep(1000);
        System.out.println(self.test(2));
        Thread.sleep(1000);
        System.out.println(self.test(1));
    }

    @Cacheable(cacheNames = "test", key = "#integer")
    public String test(int integer) {
        return LocalDateTime.now().toString();
    }
}

Паттернов очень много, поэтому я приведу вам эту картинку:

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

Этот паттерн выручал меня не один раз)

SQL бд:

1. Сложные запросы и JOIN — когда нужны агрегации и связи между таблицами

2. Транзакции ACID — банковские операции, финансовые системы

3. Структурированные данные — четкая схема, предсказуемая структура

4. Целостность данных — внешние ключи, constraints

5. Отчетность и аналитика — сложные SQL-запросы

Подходят для: банковские системы (транзакции), медицинские записи (целостность данных), интернет-магазины (заказы, inventory)

NoSQL бд:

1. Большие объемы данных — Big Data, логгирование

2. Горизонтальное масштабирование — распределенные системы

3. Гибкая схема — часто меняющаяся структура данных

4. Высокая производительность записи — IoT, сенсоры, clickstream

5. Неструктурированные данные — JSON, документы, графы

Подходят для: проекты, где работают с документами, где нужно обрабатывать огромные объемы данных(например я знаю, что в VK Video используют cassandra в качестве БД), структура данных часто меняется

Я пойду по порядку:

1. Я бы сделал gate-way шлюз для авторизации и аутентификации пользователя(OAuth, Keycloak)

2. Асинхронная модель(архитектура событий) - SOAP-система нестабильная, выдает ответ +-40 сек, SLA ≤ 2 минут - асинхронный подход максимально оправдан. Клиенту не нужно ждать - даёте taskId и он проверяет статус

3. Микросервисная архитектура, я выделил несколько сервисов:

   • Main-service - только бизнес-логика: создание задач, хранение статуса, оркестрация.

   • Adapter-service - работа с внешней системой, ретраи, circuit breaker.

   • Timeout-service - только таймеры и SLA. (Я бы использовал delay queue для отслеживания таймера)

   • Gate-way service - авторизация, аутентификация, переадресация пользователей

4. В Adapter-service нужны ретраи, circuit breaker, fallback

5. Main-service обрабатывает всю логику, также он прослушивает ответ от adapter-service и timeout-service + main хранит информацию о сообщениях(outbox таблица)

6. Timeout-service можно реализовать с помощью delay queue для отслеживания таймера

7. Мы будем использовать kafka + outbox + de-dup таблица, чтобы гарантировать доставку и обработку 1 раз.

   • Outbox гарантирует доставку события.

   • Идентификаторы сообщений — защита от дублей в потребителе.

   • Kafka — выдержит твой TPS с огромным запасом.
     

8. Для отслеживания состояний можно использовать distributed tracing

9. Архивный топик (fan-out topic) - мы отбрасываем сообщения в отдельный топик, который на данный момент никто не слушает, чтобы была возможность к нему подключиться и прослушать все сообщения, даже, если kafka уже удалила их из другого топика.(Это можно сделать, если в будущем видится добавление сервисов обработки и есть на это доп ресурсы)

10. Если в дальнейшем видится рост клиентов, можно использовать Kafka Streams для работы с большими данными

Минусы такого подхода:

• сложнее логирование

• сложнее трассировка

• нагрузка на инфраструктуру

• сложнее тестирование

Плюсы такого подхода:

• масштабируемость

• гибкость / расширяемость

• отказоустойчивость

• высокая пропускная способность

Примерная схема взаимодействия сервисов: