🏗 Java: Структурная конкурентность. Прощайте, зомби-потоки!

Допустим, вы используете Виртуальные потоки (Project Loom), чтобы сделать два независимых запроса: получить данные пользователя (API 1) и его заказы (API 2).

Раньше мы использовали ExecutorService или CompletableFuture. Но у них есть огромная архитектурная дыра: они ничего не знают друг о друге.

🧟‍♂️ Проблема зомби-потоков (Unstructured Concurrency)

Если API 1 мгновенно падает с ошибкой 500, ваш метод все равно будет ждать, пока API 2 доработает (или упадет по таймауту). Поток, качающий заказы, становится "сиротой". Он делает бесполезную работу, тратит сеть и память, хотя результат уже никому не нужен.

А если ошибку выкинет родительский метод? Дочерние потоки продолжат жить своей жизнью в фоне. Это хаос.

🧩 Решение: StructuredTaskScope

В современной Java (начиная с 21 версии) потоки привязали к лексической области видимости - блоку кода. Если мы выходим из блока (из-за ошибки или успешного завершения), все запущенные внутри него дочерние потоки автоматически отменяются (получают interrupt).

Вот как выглядит "Запрос-Ответ", где должны выполниться оба действия (Стратегия *All or Nothing*):

// ShutdownOnFailure: если один упал, отменяем остальные
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    
    // Запускаем подзадачи (Subtasks)
    Subtask<User> user = scope.fork(() -> fetchUser(id));
    Subtask<List<Order>> orders = scope.fork(() -> fetchOrders(id));

    scope.join();          // Ждем завершения обеих задач...
    scope.throwIfFailed(); // ...или первой же ошибки!

    // Сюда дойдем, только если обе задачи успешны
    return new UserProfile(user.get(), orders.get());
} 
// При выходе из блока любые зависшие потоки будут убиты

🏎 Стратегия "Кто первый, тот и прав"

А что, если вам нужно получить курс валют, и у вас есть 3 разных провайдера? Вам нужен ответ от любого, кто ответит быстрее.

// ShutdownOnSuccess: первый успешный отменяет остальные
try (var scope = new StructuredTaskScope.ShutdownOnSuccess<Quote>()) {
    
    scope.fork(() -> getFromBankA());
    scope.fork(() -> getFromBankB());
    scope.fork(() -> getFromBankC());

    scope.join(); // Ждем первого успешного

    return scope.result(); // Возвращаем самый быстрый ответ
}

Как только Банк А ответит, запросы к Банкам B и C будут немедленно отменены. Никакого ручного управления Future.cancel(). Всё работает из коробки.

🧠 Почему это меняет всё?

1. Читаемость: Многопоточный код читается сверху вниз, как обычный синхронный.
2. Безопасность ресурсов: Утечки потоков физически невозможны. Структура гарантирует, что родитель не завершится, пока не разберется со всеми детьми.
3. Идеальные логи: Стек-трейс теперь показывает реальную иерархию (кто кого вызвал), а не обрывается на внутренностях пула потоков.

В связке с Виртуальными потоками это делает Java одним из самых удобных языков для написания высоконагруженных сетевых приложений.

#Concurrency #ProjectLoom #CleanCode #Backend

👉 @java_geek

🏗 System Design: Эволюция архитектуры от 1 до 1 000 000 пользователей

Главная ошибка разработчиков при проектировании систем - строить звездолет для поездки за хлебом. Микросервисы, Kafka и Kubernetes не нужны вашему стартапу в первый день.

Архитектура должна эволюционировать шаг за шагом. Вот как выглядит этот путь.

Уровень 1: Одинокий Волк (1 - 1000 юзеров)

Всё крутится на одном сервере (например, в DigitalOcean или AWS EC2).

• Что там: Ваше Java-приложение (Monolith) + база данных (PostgreSQL) + веб-сервер (Nginx) живут на одной машине.
• Плюсы: Развертывание занимает 5 минут, всё работает быстро (сетевые задержки нулевые).
• Минусы: Если сервер упал - упало всё. Масштабировать можно только покупкой более мощного процессора/памяти (Вертикальное масштабирование).

Уровень 2: Разделение труда (10 000 юзеров)

Приложение начинает тормозить, потому что СУБД "съела" всю оперативную память.

• Что делаем: Выносим базу данных на отдельный сервер. Желательно использовать управляемое решение (Managed DB от облачного провайдера), чтобы не возиться с бэкапами.
• Результат: Приложение и БД больше не дерутся за ресурсы.

Уровень 3: Горизонтальное масштабирование (100 000 юзеров)

Трафик растет. Один сервер приложения больше не справляется с HTTP-запросами.

• Что делаем: Ставим Load Balancer (Балансировщик нагрузки) и поднимаем 3-5 одинаковых серверов с вашим Java-приложением.
• Правило: Ваше приложение должно стать Stateless (без состояния). Вы больше не можете хранить сессии пользователей в локальной памяти (RAM), иначе юзер залогинится на Сервере 1, а следующий запрос попадет на Сервер 2, и его "выкинет". Сессии уезжают в централизованное хранилище.

Уровень 4: Спасаем базу данных (500 000 юзеров)

Приложений много, а БД одна. Она начинает "задыхаться" от количества чтений.

• Что делаем (Кэш): Ставим Redis или Memcached. До 80% запросов в типичном приложении - это чтение одних и тех же данных. Кэш отдает их за миллисекунды.
• Что делаем (Репликация): Разделяем БД на Master (для записи) и несколько Slave/Replica (только для чтения).

Уровень 5: Асинхронность и Очереди (1 000 000+ юзеров)

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

• Что делаем: Внедряем брокер сообщений (Kafka или RabbitMQ) и создаем воркеры.
• Как это работает: Юзер жмет "сгенерировать отчет". Приложение кидает задачу в Kafka и мгновенно отвечает юзеру: "В процессе". А фоновые серверы-воркеры не спеша забирают задачи из очереди и делают тяжелую работу.

🧠 Главный принцип System Design

Не усложняйте систему до тех пор, пока метрики не покажут, что текущий уровень больше не справляется. Каждое усложнение (Load Balancer, Redis, Kafka) несет за собой новые проблемы: инвалидация кэша, задержки сети, дублирование сообщений.

#SystemDesign #Architecture #Backend #Scaling

👉 @java_geek

⚖️ System Design: Балансировщик нагрузки (Load Balancer). Как не уронить сервера?

В прошлом посте мы поняли, что один сервер не справляется, и запустили еще три таких же. Но как пользователи узнают, к какому из них подключаться? Не выдавать же им три разных IP-адреса!

Здесь на сцену выходит Load Balancer (LB) - регулировщик вашего трафика.



LB становится единственной точкой входа. Он принимает на себя все запросы от пользователей и по-умному раскидывает их по вашим серверам. Но как именно он решает, куда отправить следующий запрос? Для этого есть алгоритмы.

🧠 Главные алгоритмы балансировки

1. Round Robin (Карусель)
Самый простой и популярный по умолчанию. Запросы раздаются по кругу: первому серверу, второму, третьему, снова первому.

• Плюсы: Легко настроить, нулевая нагрузка на сам LB.

• Минусы: Слепой алгоритм. Если 1-й сервер завис, генерируя тяжелый отчет, а 2-й свободен, LB всё равно кинет им запросы поровну. 1-й сервер умрет окончательно.

2. Least Connections (Кто свободнее?)
LB работает как умный менеджер: он считает, сколько активных соединений висит на каждом сервере прямо сейчас. Новый запрос летит туда, где меньше всего работы.

• Идеально для: Приложений с долгими соединениями (чаты на WebSockets, потоковая передача видео, скачивание файлов).

3. IP Hash (Липкие сессии / Sticky Sessions)
LB берет IP-адрес пользователя, прогоняет через хэш-функцию и привязывает этот IP к конкретному серверу.

• Зачем нужно: Если ваше (легаси) приложение хранит корзину товаров в оперативной памяти конкретного сервера, вам критически важно, чтобы юзер всегда попадал на один и тот же сервер. Иначе на следующем клике его корзина "опустеет".

• Современный совет: Старайтесь избегать Sticky Sessions. Храните сессии в Redis, чтобы любой сервер мог обработать любой запрос.

4. Weighted алгоритмы (Система весов)
У вас в кластере два сервера: новый 32-ядерный монстр и старенькая 4-ядерная виртуалка. Если включить обычный Round Robin, старый сервер сгорит.
Вы задаете им "веса" (например, 8 и 1). Теперь мощный сервер будет получать 8 запросов на каждый 1 запрос к слабому.

🛠 Суперспособности балансировщиков

LB - это не только про алгоритмы. У него есть еще две критически важные функции:

• 🩺 Health Checks (Проверка пульса): Балансировщик постоянно "пингует" свои сервера (например, запрашивает /health). Если сервер не ответил 3 раза подряд, LB помечает его как "мертвый" и перестает слать на него трафик. Пользователи даже не заметят, что один из серверов сгорел.

• 🔒 SSL Termination: Расшифровка HTTPS-трафика отнимает много ресурсов процессора. Балансировщик может взять эту тяжелую криптографию на себя. Он расшифровывает запрос, а дальше внутри вашей приватной (безопасной) сети общается с серверами по быстрому и легкому HTTP.

#SystemDesign #Backend #LoadBalancer #Architecture #DevOps

👉 @java_geek

🗑️ Java Garbage Collector: Кто убирает за вами мусор?

Разработчики на C и C++ живут в постоянном страхе утечек памяти: выделил память через malloc - обязан очистить через free. Мы же в Java просто пишем new Object() и идем пить кофе.

Всю грязную работу делает Garbage Collector (Сборщик мусора или просто GC). Но если не понимать, как он работает, ваше приложение однажды просто "зависнет" на пару секунд на продакшене.

🛑 Главная проблема: Stop-The-World

GC не может убирать мусор, пока ваше приложение активно меняет ссылки на объекты. Ему нужно поставить всё на паузу. Эта пауза называется Stop-The-World (STW).
В этот момент все ваши потоки замирают, пользователи видят "колесико загрузки", а запросы по сети отваливаются по таймауту. Вся эволюция GC в Java - это борьба за уменьшение этих пауз.

🧬 Гипотеза поколений

Как GC понимает, что удалять? Он опирается на одно гениальное наблюдение: 98% объектов умирают молодыми. (Например, локальные переменные внутри метода живут доли секунды).

Поэтому память (Heap) поделили на две части:
1. Young Generation (Молодое поколение): Сюда попадают все новые объекты. Очистка здесь происходит часто и невероятно быстро (Minor GC).

2. Old Generation (Старое поколение): Сюда "переезжают" объекты-долгожители (например, закэшированные данные или синглтоны Spring). Очистка здесь происходит редко, но занимает много времени (Major/Full GC).



🥊 Битва титанов: Какой GC выбрать?

В современных версиях Java вам, как правило, нужно знать о двух главных сборщиках.

1. G1 (Garbage-First)
• Статус: Включен по умолчанию с Java 9.

• Как работает: Дробит память на сотни мелких регионов. Во время уборки он смотрит: "Ага, вот в этом регионе 90% мусора, начну с него" (отсюда и название - мусор в первую очередь).

• Кому подходит: 95% обычных веб-приложений. Он отлично балансирует между высокой пропускной способностью и приемлемыми паузами (целевая пауза по умолчанию — 200 мс).

2. ZGC (Z Garbage Collector)
• Статус: Готов к бою (Production Ready) с Java 15, а в Java 21 стал генерационным.

• Как работает: Настоящая магия и инженерное чудо. ZGC выполняет почти всю работу параллельно с вашим приложением, используя "цветные указатели" (colored pointers).

• Суперсила: Паузы Stop-The-World не превышают 1 миллисекунды, даже если у вас куча (Heap) размером в 16 Терабайт!

• Кому подходит: Финансовым биржам, игровым серверам и системам, где важна ультра-низкая задержка (Low Latency).

🛠 Как включить?

Ничего устанавливать не нужно, просто добавьте флаг при запуске java -jar:

• Для G1 (если у вас старая Java): -XX:+UseG1GC

• Для ZGC: -XX:+UseZGC

🧠 Золотое правило Memory Management
Сборщик мусора в Java невероятно умен. Не пытайтесь ему "помогать".
Вызовы System.gc() в коде - это выстрел себе в ногу. Просто пишите чистый код, не держите ссылки на объекты, которые вам больше не нужны, и GC сделает всё сам.

#Java #GarbageCollector #Performance #JVM #Backend

👉 @java_geek