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

#DevLife

⚡️ Multi-Level Caching в Spring Boot

Производительность enterprise-систем часто упирается в кэширование. Но один только Redis — не всегда оптимально: сетевые вызовы вносят задержки, а локальные кэши не делятся данными между инстансами. Решение — связка in-memory и распределённого кэша.

📝 Промпт:

Generate a Spring Boot 3 configuration with multi-level caching (L1 + L2).

— Integrate Caffeine as in-memory (L1) cache for ultra-fast lookups.
— Integrate Redis as distributed (L2) cache for cross-instance consistency.
— Configure CacheManager that combines Caffeine (short-lived) and Redis (longer TTL) transparently.
— Implement annotation-based caching with @Cacheable, @CachePut, and @CacheEvict.
— Add fallback to DB if both caches miss, with metrics for hit/miss ratios.
— Ensure proper serialization (Jackson or Kryo) for complex entities in Redis.
— Provide cache invalidation strategies (per entity, per tenant, global).

💡 Расширения:

— Добавьте Near-cache pattern для высоконагруженных сервисов.
— Интегрируйте с Spring Data Redis Streams для event-driven invalidation.
— Настройте Prometheus + Grafana dashboards для мониторинга кэш-слоя.

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

#Enterprise

💰 Java и лицензии

Oracle активно напоминает компаниям о необходимости платить за использование Java.

— Кто-то считает это справедливым: язык, экосистема, поддержка стоят денег.

— Другие утверждают, что Oracle душит Java и правильный путь — полностью уходить в OpenJDK и его дистрибутивы (Adoptium, Azul, Amazon Corretto).

💬 Что думаете?

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

#DevLife

🔥 Задача на алгоритмы: оптимизация расписания задач

Иногда даже повседневные задачи превращаются в отличный повод вспомнить алгоритмы и потренировать мозг. Особенно если представить, что это часть сервиса планирования нагрузок или распределения вычислений в распределённой системе.

🔹 Условие

— У вас есть N задач, каждая с временем выполнения t[i].
— Есть K воркеров (потоков, серверов), которые могут выполнять задачи параллельно, но каждый воркер может брать только одну задачу за раз.

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

💡 Пример:

t = [3, 7, 2, 5, 4]
K = 2

— если раздать задачи просто по очереди, один воркер закончит через 14 секунд, другой — через 7.
— а если распределить умнее (например, [7,3] и [5,4,2]), итоговое время — 10 секунд.

🔹 Уточнения

— N может достигать 10⁴

— K до 100

— Допустимо небольшое отклонение от оптимума (например, ≤5%)

— Требуется O(N log N) или лучше

— Можно предусмотреть балансировку “на лету” при поступлении новых задач

🔹 Вопрос

Какой алгоритм примените для минимизации времени выполнения?

Подумайте о вариантах:

— жадный

— динамическое программирование

— приближённые решения (если N велико)

🔹 Подсказки

— Это классическая NP-трудная задача разбиения множества (Partition Problem)

— На практике часто решается жадным алгоритмом LPT (Longest Processing Time first)

👇🏻 Скелет решения предложили в комментах.

💬 Делитесь своими решениями: какой алгоритм выбрали бы для продакшена, а какой — для интервью?

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

#CoreJava

❓ Нужно ли изучать JDBC, если уже работаешь с ORM?

Наш подписчик спрашивает:

Работаю джуном на проекте на Spring Boot и Hibernate. ORM вроде понятен — есть аннотации, Entity, Repository, всё работает «из коробки». Но недавно на собеседовании спросили, как работает JDBC под капотом, что такое PreparedStatement, и я понял, что знаю это очень поверхностно.

Возникает вопрос — стоит ли вообще углубляться в JDBC, если в проектах всё делается через ORM? Или это знания “для галочки”?

🔹 Что думаете?

Нужно ли джуну копать в сторону JDBC и понимать, как Hibernate общается с базой? Или достаточно знать ORM-уровень и двигаться дальше — в кэширование, оптимизацию запросов и т.п.?

💬 Делитесь опытом:

— В каких кейсах применяете JDBC
— Насколько часто ORM «прячут» ошибки, которые проще понять через нативный SQL
— Что посоветуете джунам: когда стоит спуститься на уровень JDBC и зачем это вообще нужно

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

#DevLife

👑 Магия IntelliJ IDEA: Recent Locations

Когда в проекте сотни файлов и десятки классов — навигация превращается в хаос. А вы знали, что IDEA помнит все места, где вы недавно были?

🔹 Что делает

— Показывает список недавних мест в коде (не просто открытых файлов)
— Можно искать по содержимому, не только по имени
— Можно найти только изменённые фрагменты

🔹 Зачем это нужно

— Молниеносно возвращает к недавнему месту редактирования
— Полезно при ревью, багфиксе или исследовании сложных фрагментов
— Работает лучше, чем "Recent Files", ведь учитывает даже переходы внутри одного файла

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

— Нажмите Ctrl+Shift+E (Windows/Linux) или ⌘+Shift+E (macOS)
— Появится список последних мест где вы были. Можно также искать лишь изменённые фрагменты (повторно нажмите то же сочетание)
— Начните вводить фрагмент кода или имени и IDEA сама сузит поиск

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

#Enterprise

❓ Как работает ConcurrentHashMap?

ConcurrentHashMap использует сегментирование / распространённые блокировки (в новых версиях — на уровне бакета), что позволяет нескольким потокам читать и писать без полной блокировки карты. Операции get делаются без блокировки, put и remove используют ограниченную блокировку (или CAS) лишь на отдельных сегментах или узлах.

В отличие от Collections.synchronizedMap(...), который блокирует весь объект на каждую операцию, ConcurrentHashMap даёт более высокую конкурентность и масштабируемость.

🐸 Библиотека собеса по Java

#concurrency

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

#DevLife

🎯 Как быстро настроить Zero-Downtime деплой Spring Boot-приложения с помощью Docker + Traefik

Обновлять сервис без остановки — не роскошь, а необходимость. Ни пользователи, ни ваши коллеги не должны видеть "502 Bad Gateway", пока вы выкатываете новую версию.

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

1️⃣ Готовим Dockerfile

FROM eclipse-temurin:21-jdk
WORKDIR /app
COPY target/myapp.jar app.jar
ENTRYPOINT ["java","-jar","/app/app.jar"]

Собираем образ:

docker build -t myapp:1.0.0 .

2️⃣ Добавляем Traefik как reverse proxy

Создаём docker-compose.yml:

version: '3.8'

services:
  traefik:
    image: traefik:v3.1
    command:
      - "--providers.docker=true"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  myapp_v1:
    image: myapp:1.0.0
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.myapp.rule=Host(`myapp.local`)"
      - "traefik.http.services.myapp.loadbalancer.server.port=8080"

Запускаем:

docker compose up -d

Traefik автоматически поднимет роутер и начнёт проксировать трафик.

3️⃣ Выкатываем новую версию без даунтайма

Создаём новый образ:

docker build -t myapp:1.1.0 .

Добавляем в docker-compose.yml рядом:

  myapp_v2:
    image: myapp:1.1.0
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.myapp.rule=Host(`myapp.local`)"
      - "traefik.http.services.myapp.loadbalancer.server.port=8080"

Теперь Traefik балансирует между двумя версиями — 1.0.0 и 1.1.0.
Можно спокойно проверить, что новая версия работает корректно.

4️⃣ Плавно отключаем старую

Если всё ок — выключаем старый контейнер:

docker compose stop myapp_v1
docker compose rm -f myapp_v1

Traefik мгновенно перестроит маршрут — без обрывов соединений.
Ни один пользователь не заметит переключения.

5️⃣ Добавляем health-checks для надёжности

В application.yml:

management:
  endpoints:
    web:
      exposure:
        include: health

И в Docker-compose:

healthcheck:
  test: ["CMD", "curl", "-f", "https://localhost:8080/actuator/health"]
  interval: 10s
  timeout: 3s
  retries: 3

Traefik будет держать в балансе только живые инстансы.
Всё просто и надёжно.

💡 Что мы получили:

— Обновления без простоев
— Автоматическую балансировку
— Self-healing через health-checks
— Легко масштабируемую инфраструктуру для staging/prod

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

#Enterprise

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

CopyOnWriteArrayList — это потокобезопасная коллекция из пакета java.util.concurrent, которая реализует интерфейсы List и RandomAccess. Она часто воспринимается как «волшебная таблетка» для многопоточности, но под капотом это хитрая стратегия: каждое изменение списка создаёт копию массива.

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

Внутри CopyOnWriteArrayList хранит данные в обычном массиве transient volatile Object[] array.

— Все операции чтения (get, iterator, contains) идут напрямую по этому массиву и не требуют синхронизации.

— При модификациях (add, remove, set) создаётся новый массив с учётом изменений, и ссылка array указывает на него.

За счёт этого чтения не блокируются, а итераторы всегда видят снимок состояния (snapshot) на момент создания.

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

— add(E e): берётся текущий массив, копируется в новый на +1 элемент, в конец добавляется e.

— remove(Object o): копия массива создаётся без указанного элемента.

— set(int index, E element): создаётся копия массива, в которой меняется один элемент.

Сложность таких операций — O(n), ведь нужно копировать массив.

🌊 Итераторы

— Итератор у CopyOnWriteArrayList не fail-fast, в отличие от ArrayList и LinkedList.

— Он работает по «снимку» массива, который существовал в момент вызова iterator().

— Изменения, сделанные другими потоками, в процессе обхода не видны.

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

— Чтение (get, contains, iteration) → O(1) / O(n) для поиска очень быстро, так как обращение к массиву.

— Запись (add, remove, set) → O(n), так как требуется копировать массив.

— Итерация → O(n), но без блокировок и с высокой стабильностью в многопоточной среде.

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

— CopyOnWriteArrayList идеален для сценариев «много чтений, мало записей».

— Память расходуется щедро: каждый апдейт порождает новую копию массива.

— Если записи происходят часто, использование становится неоправданным.

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

— Подписчики/слушатели событий (например, listeners в UI или логгере).

— Кэш статических данных, где обновления редки.

— Конфигурации, которые меняются редко, а читаются часто.

В большинстве остальных случаев лучше использовать другие структуры (ConcurrentHashMap, Collections.synchronizedList, CopyOnWriteArraySet).

🔗 Документация: официальная JavaDoc (Java 17)

Ставьте 🔥, если хотите такой же пост по другим коллекциям. Пишите в комменты, какую коллекцию разобрать следующей.

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

#CoreJava

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

#DevLife

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

#DevLife

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

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

#CoreJava