🔍 Завтра тестовое собеседование с Java-разработчиком

17 декабря(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle Java-разработчика.

Как это будет:
📂 Сергей Чамкин, старший разработчик из Uzum, ex-WildBerries, будет задавать реальные вопросы и задачи разработчику-добровольцу
📂 Cергей будет комментировать каждый ответ респондента, чтобы дать понять чего от вас ожидает собеседующий на интервью
📂 В конце можно будет задать любой вопрос Сергею

Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для Java-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы.

Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_sh_bot

Реклама.
О рекламодателе.

Нужно загрузить ресурсы в Spring? Вот несколько рекомендуемых подходов:

-» @Value + Resource для classpath, файловой системы и URL
-» ResourceLoader для путей, которые определяются во время выполнения
-» ResourcePatternResolver для загрузки по шаблонам

У каждого варианта своя зона применения.

Разбираем, когда и что использовать

👉 Java Portal

WebFlux часто вызывает путаницу, потому что его обычно объясняют со стороны инструмента, а не со стороны проблемы.

Поэтому начнем с базы.

Сначала: блокирующий vs неблокирующий код

-» Блокирующий код:
Поток встает и ждет, пока операция не завершится.
Пока ждет, он ничего больше делать не может.

-» Неблокирующий код:
Поток делегирует ожидание и остается свободным для других задач.
Когда результат готов, выполняется продолжение.

Это не быстрее.
Это просто более эффективное использование потоков.

Еще одно ключевое понятие перед тем как идти дальше:

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

Представь так:
потребитель может сказать продюсеру: «присылай только столько, сколько я успеваю обработать».

Теперь к WebFlux.

WebFlux позволяет строить полностью неблокирующие приложения end-to-end:

-»Неблокирующий сервер (Netty)
-»Неблокирующие API
-»Проброс backpressure без перегрузки потребителя
-»Реактивная модель (Mono, Flux)

Ключевое слово здесь end-to-end.
Если хотя бы одна часть блокирует, весь выигрыш размывается.

Самая частая ошибка при работе с WebFlux

Использовать WebFlux, а потом:

-»Дернуть блокирующую базу данных
-»Использовать SDK без реактивной поддержки
-»Делать .block(), потому что так проще

В итоге:

-»Все равно все становится блокирующим
-»Ты просто добавил сложности
-»Ничего не выиграл

WebFlux не превращает блокирующий код в неблокирующий.

А Virtual Threads разве это не меняют?

Меняют, и это важно.

С Virtual Threads:

-»Блокирующая модель снова становится жизнеспособной
-»Цена ожидания резко падает
-»Необходимость в WebFlux уменьшается

Но есть нюанс.

Virtual Threads не дают:

-»Backpressure
-»Контроль потока
-»Композицию стримов
-»Настоящий стриминг данных

Они меняют tradeoff, но не убирают саму проблему.

Когда WebFlux все еще имеет смысл

WebFlux оправдан, когда:

-»Нужен реальный backpressure
-»Ты работаешь с непрерывными стримами (SSE, WebSockets)
-»Есть fan-out из множества внешних вызовов
-»Нужно явно контролировать поток данных

По необходимости, а не потому что модно.

Когда не стоит использовать WebFlux

-»Классический CRUD
-»Сложная бизнес-логика
-»Команды без реактивного опыта
-»Проекты, где читаемость важнее конкурентности
-»Когда Virtual Threads решают задачу с меньшей когнитивной стоимостью

WebFlux это другая модель исполнения.

Если твоя проблема не в масштабной I/O-конкурентности,
WebFlux тебе не поможет.

А сегодня, с Virtual Threads, многим он уже просто не нужен.

👉 Java Portal

Тема Islands теперь используется по умолчанию во всех IDE от JetBrains.

Более мягкий и сбалансированный внешний вид, рассчитанный на комфорт и концентрацию во время работы.

Посмотреть подробнее 👉 https://jb.gg/discover-the-islands

👉 Java Portal

Случайные UUID убивают производительность базы данных.

Ты перешел с целочисленных ID (1, 2, 3…) на UUID (a1b2-3c4d-…) ради безопасности или распределенной генерации.

И вдруг записи в БД стали медленнее. Иногда намного.

Вот почему.

Фрагментация индексов.

Большинство индексов в БД это B-Tree (сбалансированные отсортированные деревья). Физическое расположение данных имеет значение.

1. Последовательные ID

Когда ты вставляешь последовательные числа (1, 2, 3), новые записи всегда попадают в самый правый лист индекса.

Записи предсказуемые и последовательные.
Максимальные cache hit’ы.
Страницы индекса остаются заполненными на 100%.

Это максимальная скорость, на которую способна твоя база.

2. Случайные UUIDv4

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

Из-за этого:

-» База постоянно подгружает случайные страницы с диска в память (random I/O).

-» Page split. Если целевая страница заполнена, БД вынуждена делить ее пополам, в итоге получаются две полупустые страницы.

-» Эффект швейцарского сыра. Индекс раздувается и заполняется дырками, зря тратя RAM и место на диске.

-» Когда размер индекса превышает объем доступной памяти, пропускная способность на запись может просесть на 20–90%.

3. UUIDv7

Перестань использовать UUIDv4 в качестве primary key. Используй UUIDv7 (стандартизирован в RFC 9562).

UUIDv7 содержит таймстемп в начале ID, поэтому он сортируемый.

В итоге ты получаешь лучшее из двух миров:

-» Распределенная генерация, без центрального счетчика.

-» Монотонные вставки. В B-Tree они ведут себя почти как последовательные числа, без фрагментации.

-» Безопасность. Нельзя просто угадать ID (атакующий не узнает, что пользователь 101 идет сразу после 100), хотя стоит учитывать, что время создания записи становится видно.

Итог простой: ты сохраняешь удобство UUID и избавляешься от перфоманс-потерь.

👉 Java Portal

Совет по Spring Boot: используйте TaskScheduler для реализации лёгких динамических задач. Для более сложных сценариев лучше смотреть в сторону Quartz.

Инжектим и используем:

@Autowired
TaskScheduler scheduler;

scheduler.schedule(
    () -> System.out.println("Hello!"),
    new CronTrigger("0 */5 * * * *") // каждые 5 минут
);

Инжектируемый бин — это ThreadPoolTaskScheduler, встроенная реализация сразу TaskScheduler и ScheduledExecutorService

При необходимости конфигурацию можно кастомизировать:

@Configuration
@EnableScheduling
public class SchedulerConfig {

    @Bean
    public TaskScheduler taskScheduler() {
        ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();
        scheduler.setPoolSize(5);
        scheduler.setThreadNamePrefix("my-scheduler-");
        scheduler.initialize();
        return scheduler;
    }
}

👉 Java Portal