⚙️ RestTemplate vs WebClient

🔹 RestTemplate

javaRestTemplate restTemplate = new RestTemplate();
ResponseEntity<User> response = restTemplate.getForEntity(
    "https://api.example.com/users/{id}", 
    User.class, 
    userId
);
User user = response.getBody();

✔️ Простота, привычность, работает из коробки. Идеален для простых CRUD операций.

❌ Блокирующий I/O — поток висит и ждет ответа. При высоких нагрузках нужен большой thread pool. С 5.0 официально в maintenance mode.

🔹 WebClient

javaWebClient webClient = WebClient.create("https://api.example.com");
Mono<User> userMono = webClient.get()
    .uri("/users/{id}", userId)
    .retrieve()
    .bodyToMono(User.class);

✔️ Неблокирующий I/O — поток освобождается и обрабатывает другие запросы. Отлично работает с реактивными стримами. Fluent API, удобная настройка retry, timeout, circuit breaker.

❌ Кривая обучения — нужно понимать реактивные концепции (Mono, Flux). Сложнее дебажить, требует Project Reactor в зависимостях.

🔹 Технические нюансы

— Thread model: RestTemplate использует по потоку на запрос (blocking I/O). WebClient работает на event loop с малым числом потоков (по умолчанию CPU cores * 2).

— Performance: в синхронных сценариях разница минимальна. При параллельных запросах WebClient показывает x2-x5 прирост throughput за счёт эффективного использования потоков.

— Memory footprint: 1000 параллельных REST вызовов через RestTemplate = ~1000 МБ стека потоков. WebClient с той же нагрузкой — десятки МБ.

— Timeout configuration: RestTemplate требует настройки через ClientHttpRequestFactory. WebClient имеет встроенный .timeout(Duration) в цепочке вызовов.

— Error handling: RestTemplate выбрасывает исключения синхронно. WebClient возвращает Mono с ошибкой.

— Testing: RestTemplate легко мокается через MockRestServiceServer. WebClient требует понимания StepVerifier из reactor-test.

— Compatibility: RestTemplate работает везде. WebClient требует Spring WebFlux в classpath, даже если используешь его в обычном Spring MVC приложении.

❓ Что выбрать?

WebClient если стартуешь новый проект, делаешь микросервисы с высокой нагрузкой, уже используешь reactive stack или планируешь масштабироваться. RestTemplate если поддерживаешь legacy код без реактивности, команда не знакома с Project Reactor, делаешь простой CRUD сервис с малой нагрузкой.

Главное помни: преждевременная оптимизация — корень зла. Если RestTemplate закрывает задачу, не усложняй. Но если упираешься в потоки на проде, время учить реактивщину.

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

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

#CoreJava

🤫 Spring 4.2+: события без наследования ApplicationEvent

Начиная с Spring 4.2 (2015 год!), классы событий больше не обязаны наследовать ApplicationEvent.

🔹 До Spring 4.2:

public class UserCreatedEvent extends ApplicationEvent {
    private final String username;
    
    public UserCreatedEvent(String username) {
        this.username = username;
    }
    
    public String getUsername() {
        return username;
    }
}

🔹 Начиная с Spring 4.2+:

// Просто POJO
public class UserCreatedEvent {
    private final String username;
    
    public UserCreatedEvent(String username) {
        this.username = username;
    }
    // getters...
}

🔹 Использование идентично:

@Service
public class UserService {
    
    @Autowired
    private ApplicationEventPublisher publisher;
    
    public void createUser(String username) {
        publisher.publishEvent(new UserCreatedEvent(username));
    }
}

@EventListener
public void onUserCreated(UserCreatedEvent event) {
    log.info("User created: {}", event.username());
}

Использование обычных POJO-классов в качестве событий делает код независимым от Spring Framework, что улучшает тестируемость и переносимость приложения.

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

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

#Enterprise

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

#DevLife

✔️ Spring-тест: @RateLimit аннотация для методов

Напишите production-ready Spring компонент 👇

📦 Задание

Реализуйте кастомную аннотацию @RateLimit, которая ограничивает количество вызовов метода с использованием Spring AOP.

🔹 Требования

— Использовать Spring AOP
— Потокобезопасность
— Кэш лимитов
— Учитывать имя метода + параметры
— Custom exception при превышении

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

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

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

#practise

👑 Магия IntelliJ IDEA: множественные курсоры

Нужно изменить одинаковый код в 10 местах? Обычно делаешь Find & Replace или правишь вручную каждую строку. Есть способ быстрее — Multiple Cursors. Редактируешь несколько мест одновременно.

🔹 Что это

Несколько курсоров в редакторе. Печатаешь один раз — изменения применяются везде сразу. Как Vim visual block mode, но удобнее.

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

— Alt+J (Win/Linux) или Ctrl+G (Mac) — выделить следующее вхождение слова под курсором
— Alt+Shift+J — убрать последний курсор
— Ctrl+Alt+Shift+J — выделить ВСЕ вхождения сразу
— Alt+Shift+Click — поставить курсор мышью
— Alt+Shift+Insert → Column Selection Mode — выделение столбцом

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

— Массовое редактирование без регулярок
— Быстрее Find & Replace для простых случаев
— Видишь изменения сразу, контролируешь процесс

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

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

#Enterprise

🔼 Прокачай DevOps-скиллы на практике

Платформа с реальными DevOps-задачами. Кейсы по Linux, Docker и Kubernetes — всё как в бою, но с читами:

✔️ Автопроверка решений
✔️ Подсказки
✔️ Готовые решения

🔗 Попробовать

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

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

#CoreJava

🔬 Правильный вопрос про AI

Все исследования AI-ассистентов меряют одно: насколько быстрее ты закрываешь задачу. Метрика удобная, но она игнорирует 70–80% реальных затрат — поддержку, рефакторинг, устранение дефектов.

Исследование «Echoes of AI» (arXiv, 2025) спросило другое:

«Что будет, когда другой разработчик возьмёт AI-код и попытается его развивать?»

151 участник, 95% практикующие разработчики (не студенты). Java/Spring Boot проект, две фазы, настоящее РКИ. Одна группа пишет с AI, другая без. Потом третья группа без AI поддерживает и тот, и другой код.

Результат оказался неожиданный.

👉 Читать

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

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

#CoreJava

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

#DevLife

🧩 Просто о сложном: Saga Pattern

Когда пользователь оформляет заказ, нужно списать деньги, зарезервировать товар и уведомить склад. Всё в разных сервисах. Что делать, если один из них упал?

Обычная транзакция тут не поможет. Добро пожаловать в Saga.

Идея проста: разбиваем большую распределённую транзакцию на цепочку маленьких локальных. Каждый шаг — это своя транзакция в своём сервисе. Если что-то пошло не так, то запускаем компенсирующие транзакции в обратном порядке.

🔹 Два подхода

1. Choreography (хореография)

Сервисы общаются через события. Каждый сам знает, что делать дальше.

OrderService → [OrderCreated] → PaymentService
PaymentService → [PaymentDone] → InventoryService
InventoryService → [Reserved] → NotificationService

✔️ Просто, нет единой точки отказа
❌ Сложно отследить весь флоу, спагетти из событий

2. Orchestration (оркестрация)

Есть дирижёр — Saga Orchestrator. Он знает весь сценарий и командует сервисами.

public class OrderSagaOrchestrator {

    public void execute(Order order) {
        try {
            paymentService.charge(order);
            inventoryService.reserve(order);
            notificationService.notify(order);
        } catch (PaymentException e) {
            // компенсация не нужна — деньги не списаны
        } catch (InventoryException e) {
            paymentService.refund(order); // компенсируем
        }
    }
}

✔️ Флоу виден в одном месте, легко дебажить
❌ Оркестратор может стать узким местом

⚠️ Важно понимать: компенсирующая транзакция ≠ откат БД. Это бизнес-операция. Если деньги уже списаны, то мы не откатываем строку в БД, мы делаем возврат.

В Java-экосистеме Saga используют вместе с:

→ Apache Kafka / RabbitMQ — для событий между сервисами
→ Axon Framework — встроенная поддержка Saga из коробки
→ Spring State Machine — для управления состоянием оркестратора
→ Temporal / Conductor — оркестрация workflow на уровне инфраструктуры

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

✔️ Микросервисная архитектура
✔️ Несколько БД, нет возможности использовать 2PC
✔️ Долгоживущие бизнес-транзакции
❌ Монолит с одной БД — просто используй @Transactional

Saga — это не серебряная пуля, это компромисс. Ты жертвуешь изоляцией ради масштабируемости. Данные могут быть временно не консистентны и это нормально, если бизнес с этим согласен.

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

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

#CoreJava

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

Java-разработчик — Офис (Казань)

Java-разработчик — от 230 000 до 330 000 ₽ — удалёнка/гибрид (Москва)

Senior Java Developer (Kotlin) — от 400 000 ₽ — удалёнка

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

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

Наглядная шпаргалка с примерами и визуализацией SQL JOIN.

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

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

#CoreJava

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

#DevLife

💥 Разрушим частый миф

Мне НЕ нужно разбираться с управлением памятью в Java, так как за меня всё делает GC

Garbage Collector (GC) действительно очищает неиспользуемые объекты, которые больше не имеют активных ссылок. Благодаря этому в Java не нужно вручную освобождать память, как в C++.

Несколько предпосылок к исходному тезису:

🔹 В других языках, где ручное управление памятью (C, C++), утечки очевидны — если забыл free(), память навсегда потеряна.
🔹 В Java GC работает автоматически, поэтому кажется, что он решает все проблемы сам.
🔹 "Ну раз GC есть, значит, про память можно не думать!" — типичная ошибка.

GC удаляет только те объекты, которые больше не имеют активных ссылок. Если же объект остаётся доступным, но фактически не используется, он будет занимать память до завершения работы приложения.

🔽 Несколько случаев утечек памяти

1️⃣ Статические коллекции (заполняем, но не чистим)

Если создать static List и постоянно добавлять в него объекты, они никогда не будут удалены GC, потому что статические поля живут весь срок жизни приложения.

public class MemoryLeak {
    private static final List<byte[]> cache = new ArrayList<>();
    
    public static void main(String[] args) {
        while (true) {
            cache.add(new byte[10 * 1024 * 1024]); 
            System.out.println("Добавили 10MB в кеш. Используемая память: " +
                    (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()) / (1024 * 1024) + "MB");
        }
    }
}

Через пару минут — OutOfMemoryError

2️⃣ Потоковые переменные (ThreadLocal)

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

public class ThreadLocalLeak {
    private static final ThreadLocal<byte[]> threadLocalData = new ThreadLocal<>();

    public static void main(String[] args) {
        ExecutorService executor = Executors.newFixedThreadPool(5);

        for (int i = 0; i < 10; i++) {
            executor.execute(() -> {
                threadLocalData.set(new byte[10 * 1024 * 1024]); // 10MB на поток
                System.out.println("Память занята потоком!");
            });
        }

        executor.shutdown();
    }
}

Поток завершится, а память останется занята, потому что ThreadLocal не очищается автоматически.

3️⃣ Внутренние классы и "утекшие" ссылки

Если анонимный класс или лямбда-ссылка ссылается на внешний объект, она может мешать GC очистить его.

public class InnerClassLeak {
    private String data = "Очень важные данные";

    public void createAnonymousClass() {
        Runnable task = new Runnable() {
            @Override
            public void run() {
                System.out.println("Используем: " + data);
            }
        };
        new Thread(task).start();
    }
}

task ссылается на data, даже если InnerClassLeak больше не используется → GC не очистит объект.

👎 Миф разрушен. GC не всемогущий и даже с ним придётся изучать, как работать с памятью в Java.

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

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

#CoreJava

✔️ SQL-тест: Топ категорий Google Search

Задача из реального интервью в Google 👇

📦 Задание

Google хочет проанализировать самые популярные категории поиска для оптимизации результатов.

Таблицы на картинке. Напишите запрос для подсчета общего количества поисков в каждой категории по месяцам за 2024 год.

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

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

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

#practise

🖥 Визуализатор кода

Прямо в браузере можно посмотреть, что происходит под капотом кода: как создаются и взаимодействуют объекты, как данные перемещаются в памяти, и как работает стек вызовов. Всё это можно увидеть пошагово.

Если что-то непонятно, встроенный AI-помощник объяснит логику кода или поможет разобраться в чужом решении.

⛓ Ссылка на сервис

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

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

#Enterprise

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

#DevLife