🔧 HikariCP: детектирование утечек соединений в production

При работе с базой данных через HikariCP нередка ситуация, когда Connection не закрывается должным образом (забытый close(), исключение до finally блока). В production это приводит к исчерпанию пула и падению приложения с ошибкой "Connection is not available".

🔹 Решение

▪️ Включение leak detection через application.yml

spring:
  datasource:
    hikari:
      leak-detection-threshold: 30000
      max-lifetime: 600000
      connection-timeout: 20000

▪️ Или программно через HikariConfig

@Bean
public DataSource dataSource() {
    HikariConfig config = new HikariConfig();
    config.setJdbcUrl(jdbcUrl);
    config.setUsername(username);
    config.setPassword(password);
    config.setLeakDetectionThreshold(30000); // 30 сек
    config.setMaxLifetime(600000);
    return new HikariDataSource(config);
}

При утечке в логах появится stacktrace места создания проблемного Connection. Значение 30000ms (30 сек) оптимально для большинства случаев - меньше даст false positive на долгих транзакциях, больше может пропустить реальные утечки.

⚠️ В production рекомендуется держать включенным постоянно, т.к. overhead минимален, а диагностика критична.

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

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

#Enterprise

✔️ Java-тест: Debouncer для частых событий

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

📦 Задание

Реализуйте debouncer, который откладывает выполнение действия пока события продолжают поступать:

public class Debouncer {
    public Debouncer(long delayMs) {
        // Ваш код здесь
    }
    
    public void call(Runnable action) {
        // Ваш код здесь
        // Если вызов повторяется до истечения delayMs
        // - отменить предыдущий и запланировать новый
        // Выполнить только когда delayMs прошло без новых вызовов
    }
}

🔹 Требования

— Выполнять action только если delayMs прошло без новых вызовов
— Каждый новый call() отменяет предыдущий таймер
— Использовать ScheduledExecutorService
— Потокобезопасность

🔹 Пример:

Debouncer debouncer = new Debouncer(300); // 300ms
debouncer.call(() -> search(query)); // откладываем
debouncer.call(() -> search(query)); // отменяем предыдущий
debouncer.call(() -> search(query)); // отменяем предыдущий
// Через 300ms выполнится только последний

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

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

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

#practise

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

#DevLife

👑 Магия IntelliJ IDEA: код без проекта

Нужно быстро протестировать Stream API, проверить регулярку или набросать алгоритм? Создавать временный класс в проекте — оверкилл. Для этого есть Scratch Files.

🔹 Что это

Временные файлы с полной поддержкой языка: подсветка, автокомплит, запуск кода. Живут в IDE, но не в проекте. Не попадают в Git, не захламляют структуру.

🔹 Как создать

— Ctrl+Shift+Alt+Insert → Scratch File.
— File → New → Scratch File.
— Или Ctrl+Shift+A → "New Scratch File".

🔹 Два типа

Scratch Files — файлы с конкретным языком (Java, Kotlin, SQL, JSON). Поддерживают автокомплит и выполнение.
Scratch Buffers — простой текст для заметок и TODO.

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

— Тестируешь алгоритм без создания Test класса.
— Прототипируешь SQL перед добавлением в JPA.
— Сохраняешь сниппеты со Stack Overflow.
— Отлаживаешь регулярки, парсинг JSON, работу с датами.

Особенно полезно при рефакторинге: копируешь сложную логику в scratch, тестируешь варианты упрощения, не трогая основной код.

🔹 Фишки

— Автосохранение между перезапусками IDE.
— Запуск кода: Ctrl+Shift+F10 для Java/Kotlin.
— Все файлы в одном месте: Project view → Scratches and Consoles.
— Хранятся локально в ~/.config/JetBrains/, не в проекте.

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

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

#Enterprise

🎯 Перестань использовать new ArrayList<>() везде

❌ Было:

List<String> names = new ArrayList<>();
names.add("Alice");
names.add("Bob");
names.add("Charlie");
return names;

✔️ Стало (Java 9+):

return List.of("Alice", "Bob", "Charlie");

🔹 Почему лучше:

→ Immutable по умолчанию — меньше багов
→ Компактнее в памяти (нет capacity overhead)
→ Читается как данные, а не как инструкции
→ Если нужна мутабельность:

var names = new ArrayList<>(
    List.of("Alice", "Bob", "Charlie")
);

Явно показываем намерение изменять список.

⚠️ Bonus:

javaMap.of("key1", "value1", "key2", "value2")
Set.of("a", "b", "c")

Работает для Map и Set тоже.

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

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

#Enterprise

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

#DevLife

🕯 Модели многопоточности: что выбирают разные языки

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

➡️ Модель 1: Event Loop (Python, JavaScript/Node.js)

▪️ Суть: один OS-поток на процесс. Runtime сам переключает контекст между задачами.

В CPython есть GIL (Global Interpreter Lock) — мьютекс, который позволяет выполнять байткод только одному потоку за раз. Это сделано для упрощения управления памятью через reference counting. В JavaScript модель изначально однопоточная — event loop обрабатывает задачи последовательно.

▪️Что это значит на практике

— Один инстанс сервиса = одно ядро процессора.
— Для использования 16 ядер нужно запустить 16 процессов + балансировщик.
— Потоки в Python/JS — это логическая абстракция, не настоящие OS threads.
— Для CPU-intensive задач в Python используют multiprocessing (отдельные процессы с изолированной памятью).

✔️ Плюсы

— Простой код без race conditions и deadlocks.
— Не нужны сложные примитивы синхронизации.
— Идеально для I/O-bound нагрузки (сеть, БД).

❌ Минусы

— Усложненная инфраструктура (больше процессов, межпроцессное взаимодействие через очереди/БД).
— Процессы изолированы — нет shared memory.
— Сложнее использовать многоядерность.

➡️ Модель 2: Platform Threads (Traditional Java)

▪️ Суть: 1:1 mapping между Java Thread и OS thread. Планировщик ОС управляет всеми потоками.

Когда вы создаете new Thread() в классической Java, вы напрямую создаете OS thread. Все потоки конкурируют за CPU время через планировщик ОС. У каждого потока ~1 МБ стека.

▪️ Что это значит на практике

— Ограничение на количество потоков (~тысячи, не миллионы).
— Создание потока дорогая операция (~1ms).
— Context switch происходит в kernel space (затратно).
— Поэтому появились thread pools, чтобы переиспользовать потоки.

✔️ Плюсы

— Простая инфраструктура — один процесс использует все ядра.
— Shared memory между потоками (быстрый обмен данными).

❌ Минусы

— Race conditions, deadlocks, visibility/atomicity проблемы.
— Многопоточный код сложен в тестировании и отладке.
— Ограничение на количество потоков может стать узким местом даже при незагруженном CPU.

➡️ Модель 3: Virtual Threads / Goroutines (Java 21+, Go)

▪️ Суть: M:N mapping. Runtime сам мультиплексирует легковесные потоки на OS threads.

В Go это goroutines (управляются Go runtime через GMP-планировщик). В Java 21+ — Virtual Threads (Project Loom). Оба подхода реализуют концепцию green threads или user-level threads.

▪️ Механизм работы

Virtual Threads поверх ForkJoinPool.

— JVM создает carrier threads (platform threads).
— Виртуальные потоки привязываются/отвязываются от carrier threads.
— При блокирующей операции виртуальный поток отвязывается, carrier thread берет другой виртуальный поток.
— Стеки virtual threads хранятся в heap, управляются GC.

▪️Что это значит на практике

— Можно создавать миллионы потоков (в Go — goroutines, в Java — виртуальные потоки).
— Создание потока почти бесплатно (байты памяти вместо мегабайт).
— Блокирующий код работает эффективно — runtime просто переключает контекст на другую задачу.
— Планировщик делает принудительное переключение, предотвращая монополизацию CPU.

✔️ Плюсы

— Нет лимита на количество одновременных задач.
— Простой императивный код вместо async/reactive.
— Shared memory все еще доступна.
— Эффективное использование ресурсов.

❌ Минусы

— Проблемы многопоточности остаются (race conditions, deadlocks).
— В Java есть pinning проблема (synchronized блоки могут прибить virtual thread к carrier thread).
— Thread-local переменные нужно использовать осторожно.

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

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

#CoreJava

🖥 Kotlin + JPA = 💔 ?

Думаете, Kotlin идеально сочетается с JPA? А вот и нет!

data class, val, final-классы и даже дефолтные значения — всё это может тихо саботировать вашу персистентность.

ℹ️ В статье

→ Почему data-классы — плохая идея для entity
→ Как val ломает контракт JPA (но работает... пока)
→ Почему первичный ключ должен быть nullable
→ Как правильно настроить проект с плагинами no-arg и all-open

Не наступайте на грабли — читайте, пока не поздно

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

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

#Enterprise

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

Java Developer (Middle) — 200 000 —‍ 250 000 ₽ — удалёнка

Middle / Senior Java Developer — офис/гибрид (Москва)

Java Developer (Middle / Senior) — удалёнка

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

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

#DevLife

⚙️ Генерим Spring Boot-фичи с AI

Нужно быстро набросать сервис для бизнес-функции? AI поможет сэкономить часы на шаблонах, валидации и boilerplate.

📝 Промпт:

Generate a Spring Boot REST endpoint that handles [описание бизнес-логики]. Include request/response DTOs, validation, exception handling, and service-layer interaction. Use best practices and explain design decisions.

💡 Дополнительные возможности:

— Добавьте Use Java 17+ features if possible, чтобы сразу писать современно
— Добавьте Add unit tests for controller and service, чтобы не откладывать на потом
— Добавьте Make it modular for future feature extension, если планируется масштабирование

💬 А вы используете AI как «копилку шаблонов» или уже доверяете ему фичи под ключ?

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

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

#Enterprise

🎯 Перестань инжектить зависимости через @Autowired на полях

❌ Было:

@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;
    
    @Autowired
    private EmailService emailService;
    
    @Autowired
    private ValidationService validationService;
}

✔️ Стало:

@Service
@RequiredArgsConstructor
public class UserService {
    private final UserRepository userRepository;
    private final EmailService emailService;
    private final ValidationService validationService;
}

🔹 Почему лучше

→ Immutable зависимости — объект полностью сконфигурирован после создания
→ Тестируемость — можно создать объект без Spring контекста.
→ Явные зависимости — видно сразу, если класс раздулся (5+ зависимостей = запах)
→ Null-safety — final поля гарантируют инициализацию
→ Рефлексия не нужна — Spring использует обычный конструктор

📌 Когда field injection допустим

→ @Value для примитивных конфигов
→ Тестовые классы с @MockBean

Но для основной бизнес-логики — только constructor injection.

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

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

#Enterprise

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

#DevLife