🪄 Магия Spring Boot, которая тихо убивает прод

Spring Boot прекрасен ровно до того момента, пока «оно само работает» не превращается в «оно само сломалось — и непонятно, где». Собрал фичи, которые на собесе звучат как удобство, а в 3 ночи как инцидент.

1️⃣ @Transactional, который держит коннект дольше, чем надо

Метод помечен @Transactional, а внутри запрос в БД, потом HTTP-вызов во внешний сервис, потом ещё один запрос. Всё это время коннект из пула занят. Даунстрим притормозил на 2 секунды → коннект висит 2 секунды → под нагрузкой пул выгребается, и приложение встаёт колом. CPU не загружен, БД не захлёбывается, а реквесты копятся.

Транзакция должна быть короткой и без сетевых вызовов внутри. Внешние интеграции выносим за её границы.

2️⃣ Self-invocation: аннотация, которая молча не работает

@Transactional, @Async, @Cacheable живут через прокси. Зовёшь аннотированный метод из этого же класса → прокси в обход, аннотация не срабатывает.

Лечится выносом в отдельный бин или self-injection. Но сначала надо просто знать, что так бывает.

3️⃣ Open Session In View — включён по умолчанию

spring.jpa.open-in-view=true из коробки. Звучит безобидно, на деле Hibernate-сессия живёт до рендера ответа: ленивые связи подтягиваются уже в слое контроллера, и ты ловишь N+1 там, где сервис давно отработал. Плюс коннект держится дольше нужного. На дев-стенде незаметно, а под нагрузкой привет latency.

Осознанно ставим false и грузим ровно то, что нужно.

4️⃣ HikariCP с дефолтным пулом

maximum-pool-size=10 по умолчанию. Для лёгкого сервиса — ок. Под реальным трафиком — узкое горлышко, о котором узнаёшь не из кода, а из графика глубины пула под нагрузкой. Тюнить надо не «побольше», а по формуле под ядра БД и характер нагрузки. Просто выкрутить в 200 — это обменять одну проблему на дедлоки в базе.

5️⃣ Actuator, открытый наружу

/actuator/env, /configprops, /heapdump — удобно для дебага и шикарно для того, кто найдёт их в проде: креды, конфиги, дампы памяти. Многое прикрыто по умолчанию, но «давайте включим всё, чтобы видеть метрики» и приехали. Открываем точечно, прячем за security, health/metrics держим отдельно от чувствительного.

6️⃣ Ретраи без circuit breaker = retry storm

Даунстрим тормозит → добавляешь 3 ретрая с бэкоффом. Но он тормозит, потому что перегружен. Твой ретрай шлёт второй запрос, третий. Помножь на всех клиентов. За полторы минуты лёгкое замедление превращается в каскадный отказ всей системы.

Ретраи — только с circuit breaker, jitter и лимитом. Иначе ты не лечишь нагрузку, а добиваешь.

🔹 Магия Spring Boot не баг, а разумные дефолты для быстрого старта. Беда в том, что дефолты «чтобы запуститься» и дефолты «чтобы держать прод» — это разные дефолты. Сеньорность тут не в том, чтобы знать всё наизусть, а в привычке спрашивать: «а что эта аннотация делает под капотом и под нагрузкой?»

💬 Какая фича Spring Boot подставила вас в проде в последний раз?

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#CoreJava

✔️ Spring-тест: рассылка ушла клиентам трижды

Подняли 3 реплики в k8s, и клиенты получили одно и то же письмо три раза 👇

📦 Задание — code review

Ежедневная рассылка счетов через @Scheduled.

@Component
@RequiredArgsConstructor
public class BillingScheduler {

    private final InvoiceService invoiceService;

    @Scheduled(cron = "0 0 9 * * *")
    public void sendDailyInvoices() {
        List<Invoice> due = invoiceService.findDueToday();
        due.forEach(invoiceService::sendAndMarkSent);
    }
}

▪️ Объясни

— Почему @Scheduled выполняется на каждой реплике и приводит к дублирующим отправкам.
— Почему «сначала проверим флаг isSent, потом отправим» не спасает от гонки между подами.
— Какие есть решения и их трейд-оффы.

Ставьте → 🔥, если нравится формат. Если нет → 🌚

💬 Решения под спойлер. Сравним, какое будет лучше.

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

#practise

ℹ️ Какой тип индекса выбрать в PostgreSQL

Индекс — это мощный инструмент для ускорения запросов, но не все они одинаково полезны. В PostgreSQL есть несколько типов индексов, и вот как не промахнуться с выбором:

🔹 B-tree (по умолчанию)

→ Лучший выбор для: =, <, >, BETWEEN, ORDER BY.
→ Поддерживает сортировку.
→ Используется в 90% случаев.

CREATE INDEX idx_users_name ON users(name);

🔹 Hash

→ Только для точного сравнения =.
→ Не поддерживает диапазоны, сортировку, LIKE.
→ Редко используется, но может быть быстрее B-tree на =.

CREATE INDEX idx_users_email_hash ON users USING hash(email);

🔹 GIN (Generalized Inverted Index)

→ Для массивов, jsonb, full-text search.
→ Отличен при поиске по вложенным структурам или множеству значений.

CREATE INDEX idx_data_tags ON posts USING gin(tags);

🔹 GiST (Generalized Search Tree)

→ Для геоданных (PostGIS), поиска по диапазонам, tsvector.
→ Более универсален, но медленнее в некоторых кейсах, чем GIN.

CREATE INDEX idx_events_location ON events USING gist(location);

🔹 BRIN (Block Range Index)

→ Для огромных таблиц, где данные физически упорядочены.
→ Занимает очень мало места.
→ Не всегда эффективен — зависит от корреляции данных.

CREATE INDEX idx_logs_timestamp ON logs USING brin(timestamp);

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#Enterprise

🔍 Магия openssl

Сертификат на проде истёк, а вы узнали от пользователей? openssl s_client покажет всю цепочку сертификатов, даты истечения и проблемы за одну команду.

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

— Проверка SSL без браузера: работает на любом сервере через SSH.
— Показывает всю цепочку: leaf, intermediate, root.
— Видны даты: Not Before и Not After и можно настроить алертинг до истечения.

🔹 Как использовать
— Проверить сертификат сайта: openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates
— Вся цепочка: openssl s_client -connect example.com:443 -showcerts </dev/null
— Subject и issuer: echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -subject -issuer
— Проверить локальный файл: openssl x509 -in cert.pem -noout -text
— Дней до истечения: echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#Enterprise

ℹ️ Liveness vs Readiness vs Startup: где чаще всего путаются

Три пробы в Kubernetes решают разные задачи, но иногда бывает путаница между ними. Давайте разберемся.

🔹 Liveness — «приложение живое или его пора убить». Зафейлился → под перезапускается. Подходит для дедлоков, зависших потоков, состояний, из которых само не выйдет.

🔹 Readiness — «готово ли принимать трафик прямо сейчас». Зафейлился → под не убивается, просто выпиливается из Service. Вернулся в норму и трафик снова идёт. Это про временную недоступность: упала БД, прогревается кэш, лёг downstream.

🔹 Startup — «приложение ещё стартует». Пока активен startup probe, liveness и readiness отключены. Без него Kubernetes может прибить Spring Boot приложение, которое просто долго поднимается (привет, миграции и прогрев контекста).

Ключевая ошибка: перепутать liveness с readiness. Зафейленный readiness говорит «я живой, но занят не шли мне трафик». Зафейленный liveness — «я сломан, убей и подними заново». Перепутаешь — будешь рестартовать здоровые поды или слать трафик в мёртвые.

В Spring Boot это маппится через health groups:

management:
  endpoint:
    health:
      probes:
        enabled: true
      group:
        liveness:
          include: livenessState
        readiness:
          include: readinessState, db, redis

Если readiness включает проверку БД, под автоматически выпадет из балансировки при обрыве соединения, без единой строчки кастомного кода.

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#CoreJava

😮 Топ-вакансий для джавистов за неделю

Java разработчик — удалёнка — CPS.ai

Middle Backend Developer (Kotlin/Java) — удалёнка — ДжазТим

Ведущий разработчик Java — офис (Москва) — МТС Банк

➡️ Еще больше топовых вакансий — в нашем канале Java jobs

⚠️ Self-invocation: почему аннотации иногда просто не срабатывают

@Transactional, @Async, @Cacheable, @Retryable работают через прокси (JDK dynamic proxy на интерфейсах, CGLIB на классах). Аннотация срабатывает, только когда вызов проходит через прокси, то есть приходит снаружи бина.

Вызов соседнего метода через this идёт мимо прокси и аннотация молча игнорируется:

@Service
public class OrderService {

    public void handle() {
        save();             // this.save() — мимо прокси
    }

    @Transactional
    public void save() {    // транзакции здесь НЕ будет
        ...
    }
}

Сюда же: @Transactional на private, final и static методах не работает — CGLIB не может их переопределить.

🔹 Лечится так:

→ вынести метод в отдельный бин (самый чистый вариант);
→ self-injection (инъекция самого себя и вызов через него);
→ ((OrderService) AopContext.currentProxy()).save() (требует exposeProxy = true);
→ TransactionTemplate для программного управления.

Симптом всегда один «аннотация висит, а эффекта нет». Первым делом проверяй, не self-invocation ли это.

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#CoreJava

📊 UUID vs автоинкремент в качестве первичного ключа

Спор древний, но решается не вкусовщиной, а тем, кто и когда генерирует ключ.

🔹 Автоинкремент хорош, когда:

— Ключ нужен только внутри одной БД
— Важна плотная индексация и предсказуемый порядок вставки (B-tree счастлив)
— Не страшно, что /users/42 выдаёт размер таблицы наружу

🔹 UUID (а лучше UUIDv7) уместен, когда:

— ID нужно сгенерировать на клиенте/в другом сервисе до записи в БД
— Идёт шардирование или слияние данных из нескольких источников
— Последовательный ID — это утечка бизнес-метрики

⚠️ Частая ловушка

Случайный UUIDv4 как кластерный ключ в InnoDB. Вставки идут вразнобой по индексу → фрагментация страниц, распухание, просадка на записи. Именно поэтому появился UUIDv7, он временно-упорядоченный, ложится в индекс почти как автоинкремент, но остаётся глобально уникальным.

Практичный компромисс: автоинкремент как внутренний PK + UUIDv7 как публичный идентификатор в URL и API. Внутри — быстро, наружу — безопасно.

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#CoreJava

✔️ Java-тест: индексация списка в Map

Напишите метод для production-кода 👇

📦 Задание

Реализуйте метод, который строит индекс «email → пользователь»:

public Map<String, User> indexByEmail(List<User> users) {
    // Ваша реализация
}

📋 Требования

— На вход может прийти null или пустой список → вернуть пустую Map.
— В списке встречаются пользователи с одинаковым email → при дубле оставить последнего (и обоснуйте политику).
— email может быть null → такие записи пропускать.
— Порядок итерации сохранять.

Ставьте → 🔥, если нравится формат. Если нет → 🤔

💬 Решения под спойлер. Сравним, какое будет лучше.

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

#practise