HTTP/2 через TCP против HTTP/3 через QUIC

▪️HTTP/2

Мультиплексирование на уровне HTTP, сериализация на уровне TCP
Общий порядок доставки и контроль перегрузки (TCP)

Одна TCP-сессия

HTTP/2 фреймы (мультиплексированные)

* HEADERS (поток 1)
* HEADERS (поток 3)
* HEADERS (поток 2)
* DATA (поток 1)
* DATA (поток 3)
* DATA (поток 2)

TCP-пакеты: P1, P2, P3, P4, P5

TCP-пакеты смешивают данные из разных потоков
HoL-блокировка в TCP (Head-of-Line): потеря одного пакета блокирует все потоки

Клиент -> Сервер

▪️HTTP/3

Мультиплексирование на транспортном уровне (QUIC)

* Независимые потоки
* Независимый порядок доставки и восстановление

QUIC-соединение (поверх UDP)
QUIC Stream 1: QUIC Packet, QUIC Packet, QUIC Packet
QUIC Stream 2: QUIC Packet, QUIC Packet
QUIC Stream 3: QUIC Packet, QUIC Packet

Нет HoL-блокировки: потеря пакета влияет только на один поток

Клиент -> Сервер

👉 Java Portal

Java tip: для точных расчетов времени используй Duration и Instant.

✅Instant представляет конкретный момент времени в UTC с точностью до наносекунд. Получить можно так: Instant.now().

✅Duration показывает временной интервал между двумя Instant (в секундах, миллисекундах, наносекундах).

Вот пример:

Instant start = Instant.now();
...
Instant end = Instant.now();

Duration elapsed = Duration.between(start, end);

👉 Java Portal

Изучение Spring Boot у новичков часто вызывает перегруз 😵‍💫

Поэтому автор сделал Spring Boot Self Learning Guide: короткий гайд с упором на примеры, который покрывает самые часто используемые фичи Spring Boot.

👉 Java Portal

Java: с CompletableFuture.allOf(...) можно дождаться завершения сразу нескольких асинхронных задач, без ручной возни с join() по каждой.

👉 Java Portal

Осознанная стоимость абстракций: Autoboxing в современной Java

Мы живём во времена, когда на оперативной памяти для heap Java-приложений почти не экономят, а архитектурные решения, которые ещё недавно можно было назвать расточительными, всё чаще воспринимаются как best practices.

Но не все коту масленица. Благодаря AI-буму, облачным вычислениям и микросервисной архитектуре с сотнями одновременно работающих инстансов, мы можем воочию наблюдать неукротимый рост стоимости оперативной памяти, что обязывает вернуться к рассмотрению принципов её экономии.

В этих условиях привычные абстракции требуют переоценки.

Сегодня я хочу напомнить об одной из самых распространенных в Java — autoboxing — механизме автоматической упаковки примитивных типов в соответствующие объекты-обертки.

Приглашаю вас посмотреть на знакомый Java-код не глазами разработчика, а глазами JVM, сборщика мусора и процессора, и разобраться, как незаметные на уровне синтаксиса решения превращаются в аллокации, давление на GC и раздувание heap.

👉 Java Portal

Совет по Java: используйте List.copyOf(list), чтобы сделать безопасную, неизменяемую копию и избежать случайных изменений.

// До Java 10, чтобы получить независимую неизменяемую копию, приходилось писать так:
List<String> copy = Collections.unmodifiableList(new ArrayList<>(originalList));

// Начиная с Java 10 это можно сделать короче:
List<String> copy = List.copyOf(originalList);

// Любая попытка добавить/удалить элемент выбросит UnsupportedOperationException:
List<String> original = new ArrayList<>();
original.add("A");
original.add("B");
List<String> copy = List.copyOf(original);
copy.add("C"); // UnsupportedOperationException

👉 Java Portal

В Spring Boot лучше заменять @Value на @ConfigurationProperties, если хочешь больше контроля и нормальную тестируемость.

▪️Когда ты используешь @Value для кучи параметров, конфиг расползается по проекту: настройки оказываются разбросаны по разным классам, их сложнее поддерживать и тестировать.
▪️@ConfigurationProperties собирает связанные параметры в один класс, позволяет навесить валидацию и делает структуру кода аккуратнее.

Разница по сути такая:

▪️С @Value это строковая инъекция свойств без валидации.
▪️С @ConfigurationProperties это type-safe конфиг с возможностью валидации.

Плюсы:

▪️автокомплит в IDE
▪️валидация
▪️проще тестировать
▪️чище структура кода

В тестах можно просто замокать объект с настройками, вместо того чтобы возиться с отдельными @Value аннотациями на каждом поле.

👉 Java Portal