🎁 Задача на дизайн: сервис подарков

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

🔹 Условие

Перед днём рождения коллеги выбирается ответственный, ему скидывают деньги, он что-то покупает, а потом надо решать, что делать со сдачей. Сервис должен:

— Позволять зарегистрированным пользователям скидываться в общую «копилку»
— Хранить средства до момента покупки
— Дать возможность выбрать товары из каталога маркетплейса
— После закрытия копилки — потратить средства на выбранное и вернуть остаток кэшбеком

🔹 Функциональные требования

— Создание и управление «копилкой»
— Пополнение копилки разными пользователями
— Привязка к каталогу и корзине маркетплейса
— Сценарий покупки и списания денег
— Возврат сдачи кэшбеком
— Уведомления участников о статусе

🔹 Нефункциональные требования

— До 200k DAU, всего ~1 млн пользователей
— Запуск MVP в течение квартала
— Масштабируемость под рост аудитории
— Интеграция с существующими сервисами: биллинг, пользователи, каталог, кэшбек, логистика
— SLA: быстрый отклик API (≤200 мс), отказоустойчивость, логирование

💡 Подсказки

— Если нужно уточнить какие-то вопросы: можете писать в комментарии, расширим вводные
— Подумайте о жизненном цикле копилки: создание → пополнение → покупка → возврат остатка → архив
— Разбейте на сущности: User, GiftPool, Contribution, Order, Refund
— Продумайте API: создание копилки, пополнение, список участников, закрытие, возврат
— Учтите рост нагрузки: кеширование, асинхронные процессы (например, списания)
— Не забудьте про безопасность: кто имеет право закрыть копилку и инициировать возврат

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

🐸 Библиотека джависта

#CoreJava

🔍 JPA vs Hibernate vs Spring Data JPA — что есть что?

Используете ORM, но путаетесь в терминах: JPA, Hibernate, Spring Data JPA? Давайте разложим по полочкам.

🔹 JPA (Java Persistence API)

— Это спецификация, а не инструмент.

— Определяет, как описывать сущности (@Entity, @Id, @OneToMany и т.д.).

— Определяет стандартные операции: EntityManager.persist(), find(), remove().

— Не содержит «железа» — только контракт.

👉 JPA = «договор о том, как работать с ORM в Java».

🔹 Hibernate

— Это реализация JPA, самый популярный ORM-фреймворк.

— Реально выполняет работу: маппинг объектов ↔️ таблиц, генерация SQL.

— Добавляет много фич «поверх» JPA (например, кэширование второго уровня, собственные аннотации).

— Можно использовать напрямую, но чаще его подключают как провайдер JPA.

👉 Hibernate = «двигатель», который выполняет то, что описано в JPA.

🔹 Spring Data JPA

— Это надстройка над JPA (и Hibernate под капотом).

— Упрощает жизнь: вместо EntityManager вы пишете интерфейсы UserRepository, а Spring сам генерирует реализацию.

— Позволяет писать запросы прямо в именах методов (findByEmailAndStatus).

— Поддерживает @Query для кастомных запросов.

— Даёт дополнительные удобства: пэйджинг, сортировки, спецификации.

👉 Spring Data JPA = «фасад», который избавляет от рутины и скрывает низкоуровневые детали.

🔹 Когда что использовать

— Если нужен чистый стандарт → JPA + реализация (например, Hibernate).

— Если хотите гибкость и полный контроль → можно работать напрямую с Hibernate.

— Если важна скорость разработки и минимум кода → Spring Data JPA.

🐸 Библиотека джависта

#CoreJava

👀 Внутреннее устройства HashMap

HashMap — один из базовых и в то же время самых хитро устроенных контейнеров в JDK. На поверхности простая структура «ключ–значение», но под капотом она сочетает массивы, списки и даже деревья, чтобы оставаться быстрой в разных сценариях нагрузки.

📦 Базовая структура

HashMap хранит данные в массиве бакетов (Node<K,V>[] table). Каждый бакет — это «корзина» для элементов, чей hashCode после хеширования и применения & (n-1) (где n — длина массива) указывает на конкретный индекс.

🔑 Хэш и распределение

1. Вызов hashCode() у ключа.
2. Дополнительное хеширование (spread), чтобы снизить коллизии из-за плохой реализации hashCode.
3. Индекс бакета = hash & (table.length - 1).

🌊 Коллизии

Если несколько ключей попали в один бакет:

— до Java 8 это всегда был связанный список (linked list),

— начиная с Java 8: при росте числа элементов в бакете больше 8 и достаточном размере таблицы он превращается в сбалансированное красно-чёрное дерево. Это резко ускоряет поиск в «плохих» случаях (с O(n) до O(log n)).

⚡️ Ресайзинг

Когда количество элементов превышает capacity * loadFactor (по умолчанию 0.75), создаётся новый массив в 2 раза больше, все элементы перехешируются и раскладываются по новым бакетам. Это дорогостоящая операция, но благодаря амортизации остаётся приемлемой.

📊 Производительность

— Поиск/вставка/удаление в среднем: O(1).

— В худшем случае (плохой hashCode + коллизии): O(log n) благодаря деревьям.

⚖️ Важные нюансы

— Ключи неупорядочены. Для упорядоченности есть LinkedHashMap.

— HashMap не потокобезопасен. Для многопоточной среды нужен ConcurrentHashMap или синхронизация.

— Хорошо реализованный hashCode и equals критичны, иначе получите «забитые» бакеты и деградацию.

🧮 loadFactor и capacity

— Capacity — размер массива бакетов. По умолчанию 16.

— LoadFactor — коэффициент заполнения. По умолчанию 0.75.

Почему именно 0.75? Это компромисс: выше → меньше памяти, но больше коллизий; ниже → быстрее доступ, но больше памяти уходит впустую. Capacity всегда степень двойки, чтобы можно было вычислять индекс через hash & (n-1) вместо затратного %.

🔄 Итераторы и fail-fast

Если во время обхода карта меняется (кроме iterator.remove()), бросается ConcurrentModificationException. Под капотом это работает через счётчик модификаций (modCount), который проверяется в каждом next().

🌳 Деревья в деталях

Коллизии превращаются в красно-чёрное дерево, если размер списка в бакете > 8 и общее количество бакетов ≥ 64. Обратно в список (untreeify) при падении количества элементов < 6. Это сделано, чтобы не тратить память и CPU на лишнюю балансировку при малых размерах.

🔗 Документация: OpenJDK — HashMap source

Ставьте 🔥, если хотите такой же пост по другим коллекциям.

🐸 Библиотека джависта

#CoreJava

🔍 Просто о сложном: AtomicInteger

В многопоточном коде даже простая операция count++ не является атомарной. Она распадается на три шага:

1. Прочитать значение переменной.
2. Увеличить его.
3. Записать обратно.

Если два потока выполнят это одновременно, получится гонка данных (race condition). Итоговое значение будет меньше ожидаемого.

🔹 Как решает проблему AtomicInteger

AtomicInteger — это класс из пакета java.util.concurrent.atomic, который предоставляет атомарные (неделимые) операции над целыми числами.

Под капотом он использует механизм CAS (Compare-And-Swap), который поддерживается на уровне процессора.

Принцип работы:
— Читаем текущее значение.
— Проверяем, не изменилось ли оно за это время.
— Если совпадает, записываем новое.
— Если нет, повторяем попытку (spin loop).

🔹 Пример использования

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

public void increment() {
count.incrementAndGet(); // атомарное ++
}

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

Здесь incrementAndGet() гарантирует, что два потока не «перетрут» друг друга, а каждый инкремент будет учтён.

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

▪️ get() — получить текущее значение.
▪️ set(int newValue) — установить новое значение.
▪️ incrementAndGet() / getAndIncrement() — инкремент.
▪️ decrementAndGet() — декремент.
▪️ addAndGet(int delta) — прибавить значение.
▪️ compareAndSet(int expect, int update) — вручную применить CAS.

🔹 Подводные камни

— Спин-блокировки

CAS может крутиться в цикле, пока не удастся обновить значение. При высокой конкуренции это нагружает процессор.

— ABA-проблема

Значение могло измениться на «A → B → A». Для простых счётчиков это не критично, но в сложных структурах данных используют AtomicStampedReference.

— Ограниченность

AtomicInteger работает только с int. Для более сложных случаев есть AtomicLong, AtomicReference, LongAdder (оптимизирован для высокой конкуренции).

🔹 Когда использовать

✔️ Подходит:

— Для простых счётчиков, метрик.
— В неблокирующих алгоритмах (lock-free).
— В высоконагруженных сценариях, где synchronized слишком дорог.

❌ Не подходит:

— Для сложных бизнес-операций над несколькими переменными (лучше использовать мьютексы или транзакции).
— При очень высокой конкуренции, может быть лучше взять LongAdder.

🔹 Итог

AtomicInteger — это лёгкий способ избавиться от гонок при работе с числами в многопоточности.

Это не магия, а всего лишь тонкая обёртка над CAS, встроенным в процессоры. Понимание этого механизма помогает писать по-настоящему безопасный и быстрый многопоточный код.

🐸 Библиотека джависта

#CoreJava

⌛ Сохраняйте шпаргалку по лямбдам и стрим апи

🐸 Библиотека джависта

#CoreJava

👀 Внутреннее устройство LinkedList

LinkedList — это классическая реализация двусвязного списка. На поверхности он выглядит как обычная коллекция, реализующая интерфейсы List, Deque и Queue. Но под капотом это структура узлов (Node), которые связаны друг с другом через ссылки на предыдущий и следующий элемент.

📦 Базовая структура

Каждый элемент списка хранится в отдельном объекте Node<E>, который содержит:

▪️ E item — сам элемент
▪️ Node<E> next — ссылка на следующий узел
▪️ Node<E> prev — ссылка на предыдущий узел

У LinkedList есть два поля:

▪️ first — голова списка
▪️ last — хвост списка

Это позволяет быстро добавлять элементы в начало и конец.

⚡️ Добавление и удаление

— Добавление в начало (addFirst) или конец (addLast) → O(1): меняем ссылки у пары узлов.
— Удаление головы или хвоста также → O(1).
— Вставка или удаление в середине требует сначала дойти до нужного узла → O(n).

🌊 Поиск элемента

— По индексу: список не хранит массив, значит придётся идти по ссылкам.
— Оптимизация: если индекс ближе к голове, обход идёт с first, если к хвосту — с last.
Сложность в среднем — O(n/2), то есть линейная.

📊 Производительность

— Доступ по индексу → O(n).
— Добавление/удаление в начало или конец → O(1).
— Вставка/удаление в середину → O(n).
— Итерация по списку → O(n), но эффективно, так как используется последовательный проход по ссылкам.

⚖️ Важные нюансы

— В отличие от ArrayList, в LinkedList нет операций с массивами и «ресайзинга».
— Но расходует больше памяти: каждый узел хранит не только элемент, но и две ссылки (prev/next).
— Итераторы fail-fast: изменение списка во время обхода бросает ConcurrentModificationException.

🔄 Итераторы и Deque

LinkedList реализует Deque, что делает его удобным для очередей и стеков. Offer, poll, peek работают за O(1). Push/pop превращают список в стек.

🧮 Когда использовать

На практике ArrayList почти всегда быстрее по времени и эффективнее по памяти.
LinkedList может быть полезен только в редких случаях, когда нужны очень частые вставки/удаления в середину коллекции (без итерации по коллекции) и не важен доступ по индексу. В остальных случаях выбирайте ArrayList.

🔗 Документация: OpenJDK — LinkedList source | Официальная JavaDoc (Java 17)

Ставьте 🔥, если хотите такой же пост по другим коллекциям, например CopyOnWriteArrayList.

🐸 Библиотека джависта

#CoreJava

🧩 final vs finally vs finalize()

Казалось бы, три похожих ключевых слова → final, finally, finalize(). А смысл принципиально разный. Давайте разберёмся.

🔹 final

Модификатор, который делает сущность неизменяемой:

▪️ final переменная → нельзя переприсвоить.
▪️ final метод → нельзя переопределить.
▪️ final класс → нельзя наследовать.

Используется для обеспечения immutability и контрактов в коде.

🔹 finally

Блок в try-catch, который выполняется всегда (даже если выброшено исключение).

Гарантирует освобождение ресурсов:

try {
FileReader reader = new FileReader("data.txt");
} catch (IOException e) {
e.printStackTrace();
} finally {
System.out.println("Закрываем ресурсы");
}

🔹 finalize()

Метод класса Object, вызываемый GC перед удалением объекта. Используется редко, считается устаревшим (deprecated с Java 9, удалён в Java 18).

Минус: непредсказуемое время вызова.

Современная альтернатива: try-with-resources или явная очистка.

💡 Вывод

final → контроль изменяемости.
finally → контроль завершения.
finalize() → контроль очистки (но не используйте).

🐸 Библиотека джависта

#CoreJava

🔍 Просто о сложном: Spring Boot

Spring Boot — это не «новый фреймворк», а надстройка над Spring, которая убирает рутину и ускоряет разработку.

В обычном Spring нужно было вручную конфигурировать всё: от DataSource до DispatcherServlet. В Boot это делается автоматически через автоконфигурацию.

🔹 Как работает автоконфигурация

Spring Boot сканирует зависимости и classpath, а затем подключает нужные бины:

— Если у вас есть spring-boot-starter-data-jpa, Boot автоматически создаст EntityManagerFactory, DataSource, транзакционный менеджер.

— Если добавлен spring-boot-starter-web, он поднимет встроенный Tomcat/Jetty и зарегистрирует контроллеры. И так далее.

Магия кроется в аннотации @EnableAutoConfiguration (включается через @SpringBootApplication). Она загружает META-INF/spring.factories → список классов-конфигов → каждый проверяет условия @ConditionalOnClass, @ConditionalOnMissingBean и решает: активироваться или нет.

💡 Почему это работает так гладко

Потому что в Boot сотни готовых конфигураций «на все случаи жизни».

Фактически, это огромная библиотека «если увидишь X — настрой Y».

👀 Подводный слой магии

— Черный ящик

Легко забыть, что именно сконфигурировал Boot. Иногда приходится «копать» в автоконфигурацию, чтобы понять, какой бин реально используется.

— Избыточные зависимости

Подключив Starter, можно случайно притащить половину экосистемы Spring. Это увеличивает время старта и усложняет дебаг.

— Конфликт настроек

Собственная конфигурация может пересечься с автоконфигурацией.

⚡️ Хорошая практика

— Не доверяйте «чёрному ящику»: при старте приложения смотрите Spring Boot Actuator и логи автоконфигурации.

— Знайте про --debug при старте: он показывает, какие автоконфигурации включены или отключены.

— В продакшене лучше контролировать, какие именно стартеры вы тянете. Иногда spring-boot-starter-web приносит в проект в три раза больше, чем реально нужно.

🎯 Итог

Spring Boot — это ускоритель, но не магия. Его сила в автоконфигурациях, а слабость в том, что легко потерять контроль.

Понимание того, как работает @EnableAutoConfiguration и условия @Conditional, отличает разработчика, который «просто пишет на Boot», от того, кто реально управляет приложением.

🐸 Библиотека джависта

#CoreJava