⚙️ Async Profiler

Async Profiler — это современный профайлер для JVM, который показывает, где именно «горит» CPU и где происходят утечки памяти. В отличие от классических профайлеров, он использует низкоуровневые возможности ОС (perf, JVMTI) и практически не влияет на производительность.

📌 Что умеет:

— Делает CPU и allocation flame graph'ы
— Минимальный overhead
— Поддерживает анализ Java и нативного кода вместе
— Умеет снимать снапшоты и строить красивые SVG-отчёты

🧠 Особенно полезен, если у вас микросервисы или приложения с нагрузкой 24/7 — можно ловить узкие места без остановки сервиса.

🔗 Async Profiler на GitHub

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

#буст

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

#развлекалово

💬 Обратная связь

По воскресеньям выходит пост с подборкой свежих статей/новостей. Посты собирают мало реакций, в связи с чем вопрос: как вы оцениваете эту рубрику?

👍🏼 — Мне нравится, иногда нахожу, что почитать.
🌚 — Рубрика нормальная, но можно улучшить формат поста.
🤔 — Скучно/не интересно, лучше что-то другое постить.

И пишите любые ваши мысли и предложения в комментариях, сделаем контент интереснее вместе.

⚡️ JUnit 5: @ClassTemplate

В JUnit 5 появилась интересная аннотация @ClassTemplate. Она полезна, когда один и тот же набор тестов нужно выполнить в разных контекстах. Например: проверить класс с разными локалями, флагами или окружениями.

Обычно в таких случаях мы либо дублируем тестовые классы, либо городим параметризованные тесты. Но @ClassTemplate позволяет описать тест один раз, а запускать его несколько раз — каждый раз в новом окружении.

🔍 Как это работает

— Помечаем тестовый класс @ClassTemplate.
— Регистрируем ClassTemplateInvocationContextProvider, который возвращает список «контекстов» (например, en/it).
— JUnit прогоняет один и тот же класс для каждого контекста.

💡 Пример

— Есть Greeter, который должен возвращать приветствие по-английски и по-русски.
— Мы пишем один тест → JUnit запускает его дважды: для en и для ru.
— В отчёте два результата, код теста при этом один.

⚠️ Важные детали

— Работает начиная с JUnit 5.13.
— Для читаемых логов удобнее запускать через JUnit Console Launcher.
— Отличается от @TestTemplate тем, что переиспользует весь класс, а не отдельные методы.

💬 А вы чаще решаете такие задачи параметризацией или дублированием тестов?

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

#буст

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

#развлекалово

❓ В чём разница между Statement и PreparedStatement?

— Statement используется для выполнения простых SQL-запросов без параметров. Он формирует запрос как строку и каждый раз компилирует его заново, что может быть медленно и небезопасно.

— PreparedStatement предварительно компилируется базой данных и позволяет задавать параметры через плейсхолдеры. Что повышает производительность при многократном выполнении одного запроса и защищает от SQL-инъекций (данные не конкатенируются со строкой запроса, а подставляются корректно).

Поэтому в реальных проектах почти всегда используют PreparedStatement.

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

🔧 Как устроена масштабируемая система

Представьте, что вам нужно обрабатывать миллионы запросов и файлов — как это сделать эффективно? Ответ кроется в правильном проектировании архитектуры.

Вот ключевые компоненты:

🔹 DNS — запросы перенаправляются на нужный сервер.

🔹 Балансировка нагрузки — равномерное распределение трафика между серверами для избежания перегрузок.

🔹 Масштабирование — использование распределенных сервисов и кеширования для работы с большими объемами данных.

🔹 Обработка медиа — загрузка и обработка изображений/видео с последующей обработкой метаданных.

🔹 Базы данных — распределение данных и управление запросами для обеспечения высокой доступности.

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

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

#буст

🤫 Что действительно важно в Java 21

Ну всё, хватит отдыхать 😁
Обсудим интересные фичи 21 java.

Переход на версию LTS — не просто "модно", а реальная возможность повысить продуктивность проекта. Вот на что стоит обратить внимание:

1️⃣ Виртуальные потоки (Virtual Threads)

При миллионе одинаковых тестовых задач время получается следующее :
— FixedThreadPool : 33 мин.
— CachedThreadPool : 1:26 мин.
— VirtualThreadPerTask : всего 14 секунд

Производительность и масштабируемость на новом уровне.

2️⃣ Улучшенные паттерны и паттерн-свитчи

Record-паттерны позволяют одновременно проверять тип и извлекать поля, свитчи стали мощнее — меньше кода, больше читаемости.

3️⃣ Generational ZGC (Garbage Collector)

Минимальные задержки (sub-миллисекунды) и оптимальное управление памятью, что идеально для latency-чувствительных приложений.

4️⃣ Строковые шаблоны (String Templates)

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

5️⃣ Коллекции с упрощённой навигацией (Sequenced Collections)

Последовательные операции легко доступны: getFirst(), getLast(), reversed() — удобно и логично.

💬 Кто уже работал с виртуальными потоками?

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

#буст

🥇 Унификация API-ошибок в Spring Boot

Чёткая схема API помогает наладить диалог между провайдером и клиентом, а единый формат ошибок — избавить потребителей от хаоса в коде и лишних поводов для «боли».

🔹 В Spring Boot по умолчанию структура ошибок выглядит так:

{
"timestamp": "2021-15-08T14:32:17.947+0000",
"status": 500,
"error": "Internal Server Error",
"path": "/test"
}

Такая форма ответа не всегда содержит тип ошибки для обработки на клиенте, а также предоставляет мало контекста для формирования пользовательских сообщений.

🔹 Решение: разработать унифицированную структуру, например:

{
"error": {
"type": "USER_NOT_FOUND",
"message": "User with ID 12345 not found.",
"status": 500,
"path": "/integration/apps",
"timestamp": "2021-15-08T14:32:17.947+0000",
"data": {
"userId": "12345"
}
}
}

🔹 Как внедрить:

▪️ Создаём единое исключение AppException:

public final class AppException extends RuntimeException {
private final ErrorType type;
private Map<String, Object> data;
// конструктор и геттеры...
}
public enum ErrorType {
USER_NOT_FOUND(404), AUTHENTICATION_FAILED(401), …;
private final int status;
// геттеры...
}

▪️ Глобальный обработчик:
Используем @ControllerAdvice с @ExceptionHandler(AppException.class) для перехвата ошибок и возвращения QErrorResponse, содержащего нужную структуру

▪️ Обработка всех остальных ошибок:
Создаём свой ErrorController, заменяющий BasicErrorController, и возвращаем данные в таком же формате QErrorResponse:

@RestController
@RequestMapping("${server.error.path:${error.path:/error}}")
public class RestErrorController extends AbstractErrorController {
// логика формирования QErrorResponse…
}

Это гарантирует, что любые ошибки возвращаются в одинаковом формате .

🔹 Почему это важно:

— Унификация ответа облегчает обработку ошибок на клиенте.
— Контекст в data позволяет выдавать более понятные сообщения пользователю.
— Расширяемость дает возможность добавлять новые типы ошибок при сохранении консистентности.

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

#буст