🔐 Spring Security: хватит бояться, пора настраивать

Все мы рано или поздно упираемся в Spring Security и обычно это выглядит как «добавил стартер, всё сломалось, ничего не понятно».

В новой статье на Хабре практика с самого нуля:

▪️ поднимаем проект на Spring Boot + PostgreSQL в Docker Compose
▪️ смотрим, что Security делает «из коробки»: дефолтный логин, редиректы, сгенерированный пароль
▪️ пишем свою сущность User с ролями и разбираем каждый метод UserDetails. Зачем нужны isAccountNonLocked, isEnabled и прочие «непонятные» методы
▪️ реализуем UserDetailsService — ту самую точку входа, без которой фреймворк вообще не знает о ваших пользователях

Уровень — простой, время — ~9 минут. Идеально, если только начинаете разбираться в безопасности Spring-приложений или хотите наконец понять, что происходит под капотом.

🔗 Подробнее

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

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

#Enterprise

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

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

Middle Java Software Engineer — офис (Алматы) — Kaspi kz

Senior Java разработчик — удалёнка/гибрид/офис (Москва) —Азиатско-Тихоокеанский банк

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

ℹ️ @Transactional НЕ откатывается на checked-исключениях

Метод бросил исключение, ты ждёшь rollback, а в БД лежат наполовину применённые изменения. Скорее всего, исключение было checked:

@Transactional
public void process() throws BusinessException {
    repo.save(a);
    if (bad) throw new BusinessException("...");  // checked
    repo.save(b);
}

По умолчанию Spring откатывает транзакцию только на RuntimeException и Error. На любом checked-исключении (наследники Exception, кроме RuntimeException) транзакция коммитится. Это не баг, а наследие декларативных транзакций из EJB.

Два пути:

// 1) явно расширить условие отката
@Transactional(rollbackFor = Exception.class)

// 2) или сделать доменные исключения unchecked
public class BusinessException extends RuntimeException { ... }

Проверь свои сервисные методы, которые бросают checked-исключения внутри @Transactional — там часто прячется молчаливый частичный коммит.

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

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

#Enterprise

✔️ Concurrency-тест: пул потоков копит задачи до OOM

Нагрузка выросла, latency пополз вверх, потом OutOfMemoryError 👇

📦 Задание — code review

Сервис обрабатывает входящие события асинхронно.

@Configuration
public class ExecutorConfig {

    @Bean
    public ExecutorService eventExecutor() {
        return Executors.newFixedThreadPool(10);
    }
}

@Service
@RequiredArgsConstructor
public class EventService {

    private final ExecutorService eventExecutor;

    public void handle(Event event) {
        eventExecutor.submit(() -> process(event));
    }
}

▪️ Объясни

— Какая очередь стоит за Executors.newFixedThreadPool и почему она опасна под нагрузкой.
— Почему задачи бесконтрольно «копятся» и система падает в OutOfMemoryError, а не начинает отбрасывать нагрузку.
— Как собрать ThreadPoolExecutor руками: ограниченная очередь, RejectedExecutionHandler, backpressure. Чем плох и newCachedThreadPool в этом сценарии.

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

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

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

#practise

🐳 Магия Docker CLI

Собрали образ и он весит 2 ГБ, а вы не понимаете, откуда столько? docker history покажет размер каждого слоя — сразу видно, какая инструкция в Dockerfile раздула образ.

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

— Каждая инструкция в Dockerfile создаёт слой, и docker history показывает размер каждого.
— Сразу видно, если COPY затянул 800 МБ зависимостей.
— Помогает оптимизировать порядок слоёв для лучшего кэширования.

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

— Посмотреть слои: docker history my-image
— Без обрезки команд: docker history --no-trunc my-image
— Только размеры в human-readable: docker history --format "{{.Size}}\t{{.CreatedBy}}" my-image
— Сравнить два образа: запустите history для обоих и сравните слои.

💡 Если видите большой слой от COPY . . — значит, в контекст сборки попали модули, .git или логи. Проверьте dockerignore, это обычно экономит сотни мегабайт.

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

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

#Enterprise

🔍 List vs Set в @OneToMany: почему «просто замени на Set» — плохой совет

List без @OrderColumn в Hibernate — это bag, неупорядоченное мультимножество. Попытка вытащить две bag-коллекции одним JOIN FETCH роняет приложение ещё на старте:

org.hibernate.loader.MultipleBagFetchException:
cannot simultaneously fetch multiple bags

В интернете 280+ апвоутов у ответа «замени List на Set». Исключение он действительно убирает, но лечит симптом, а не причину.

Суть проблемы в том, что JOIN FETCH двух коллекций порождает декартово произведение строк (N×M). С Set Hibernate просто дедуплицирует это в памяти → SQL-результат всё равно раздут, и на больших коллекциях это деградация, а не решение.

Правильно — грузить максимум одну коллекцию за запрос. Persistence Context гарантирует, что в рамках сессии сущность загружается в единственном экземпляре, поэтому две коллекции можно безопасно дотянуть двумя отдельными запросами / @EntityGraph, или через @BatchSize / subselect-fetch.

Бонус про bag: при изменении bag-коллекции (особенно с join-таблицей без собственного PK) Hibernate нередко делает DELETE всех строк коллекции и INSERT заново вместо точечного INSERT. Ещё один аргумент не использовать bag для изменяемых связей.

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

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

#Enterprise

ℹ️ Circuit Breaker: контролируемая деградация вместо падения

Любой вызов внешнего сервиса может зависнуть, упасть или начать возвращать ошибки — неважно, ходишь ты через Feign, WebClient, gRPC или в базу. Circuit Breaker страхует от того, чтобы эта беда утянула за собой твоё приложение.

Дальше на примере Feign-клиента и Resilience4j в Spring, но паттерн работает с любым вызовом.

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

@CircuitBreaker(name = "authorService", fallbackMethod = "getInstanceFallback")
String getInstance();

name ссылается на конфиг в application.yml, а fallbackMethod на метод, который отдаст запасной ответ.

🔹Важное правило

Сигнатура фолбэка должна совпадать с исходным методом — тот же тип возврата, те же аргументы плюс Throwable последним параметром. Иначе получишь NoSuchMethodException в рантайме:

public String getInstanceFallback(Throwable ex) {
    return "Fallback content";
}

Настраиваем порог и время ожидания под тем же name:

resilience4j:
  circuitbreaker:
    instances:
      authorService:
        failure-rate-threshold: 50
        sliding-window-size: 10
        wait-duration-in-open-state: 5s

🔹 Как это живёт

Брейкер считает долю ошибок не с первого запроса, а по скользящему окну (sliding-window-size). 50% — это «половина из последних 10 вызовов упала», а не «одна ошибка из двух».

Когда порог превышен, цепь размыкается (open) и брейкер перестаёт долбиться в упавший сервис и сразу отдаёт fallback, не копя таймауты.

Через wait-duration-in-open-state цепь переходит в half-open: пропускает несколько пробных запросов. Сервис ожил — цепь замыкается обратно (closed), нет — снова размыкается.

🔹 Идея простая

Внешний сервис упал, а твоё приложение деградирует контролируемо, а не валится следом.

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

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

#Enterprise

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

Разработчик Java — удалёнка/гибрид (Санкт-Петербург) — 585, Холдинг

Java-разработчик Middle — удалёнка — CRT

Java / Flutter разработчик — удалёнка/гибрид (Москва) — GEOMAX

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

🫡 Один и тот же запрос к AI можно выполнить двумя способами — и получить совершенно разный результат.

1️⃣ способ — просто попросить написать код. Модель может сгенерировать рабочее решение, но именно на этапе проверки часто всплывают пропущенные edge case’ы, ошибки обработки или проблемы с тестами.

2️⃣ способ — дать агенту цикл Think → Act → Observe. Он не останавливается после первой попытки: планирует действия, проверяет результат и, если находит ошибку, исправляет её и пробует снова.

Самое интересное, что разница здесь не столько в модели ❕ Claude, GPT или другая LLM могут быть одинаковыми. Разницу создаёт инженерная система вокруг них.

📅 Именно это разберём 23 июля в 19:00 (МСК) на бесплатном вебинаре с Алексеем Жиряковым (Executive Director в Сбере, GenAI Data Platform, ex-CTO Stream и KION).

На живом демо покажем, как один и тот же запрос работает без агентной системы и с ней 🔥

🔗 Регистрация

🏃‍♀️ Proglib Academy