Backend Developer Java

Семантика языка Java: система типов и упаковка, строки и иммутабельность, контракт equals/hashCode, интерфейсы, обобщения и стирание типов, records и sealed-типы, модель исключений. Не синтаксис, а поведение и стоимость решений.

1. Типы: примитивы, ссылки и упаковкаДва мира типов: значение против объекта. Автоупаковка и её цена в аллокациях, кэш обёрток -128..127 и почему == на Integer — ловушка, а не сравнение значений.
2. Строки: пул, иммутабельность и конкатенацияИммутабельность String как источник разделения, потокобезопасности и кэша hashCode; пул литералов и ловушка == vs equals; почему конкатенация в цикле требует StringBuilder.
3. Контракт equals и hashCodeequals и hashCode как единый контракт: пять свойств, правило «равные → равный хеш» и почему без него объект теряется в HashMap; симметрия при наследовании (getClass против instanceof).
4. Интерфейсы: default-методы и функциональные интерфейсыdefault-методы для эволюции интерфейсов без слома реализаций и правила разрешения ромба; функциональные интерфейсы и граница с абстрактным классом по состоянию и множественности.
5. Обобщения и стирание типовОбобщения как compile-time-механизм, стираемый к рантайму: откуда unchecked и запрет instanceof, почему List<String> инвариантно не связан с List<Object>, и wildcards по правилу PECS.
6. Records, sealed-типы и сопоставление с образцомRecord как неизменяемый носитель данных с генерируемыми членами, а sealed + pattern matching — исчерпывающий switch, где компилятор ловит забытый вариант вместо рантайма.
7. Модель исключенийИерархия Throwable как классификация ошибок, checked против unchecked как решение об обязанности вызывающего, try-with-resources с подавленными исключениями и chaining с cause против антипаттернов, ломающих диагностику.

Java Collections Framework изнутри: устройство ArrayList и HashMap, стоимость операций, хеширование и коллизии, упорядоченные структуры, fail-fast итераторы и потокобезопасные коллекции. Выбор коллекции — это выбор асимптотики и памяти.

1. Иерархия коллекций и стоимость операцийДве оси выбора: интерфейс задаёт контракт, реализация — цену. Иерархия List/Set/Queue и отдельная Map, профили асимптотики и выбор коллекции по горячим операциям.
2. ArrayList и LinkedList: массив против связного спискаПочему ArrayList обгоняет LinkedList даже на вставках: амортизированный рост массива, локальность данных и кэш процессора — и где Big-O вводит в заблуждение.
3. HashMap изнутриМассив бакетов, хеш ключа и поиск через equals: коллизии и треификация, load factor и рехеш, и почему O(1) держится только при хорошем hashCode и иммутабельных ключах.
4. TreeMap, LinkedHashMap и упорядоченностьТри вида порядка: никакого (Hash), вставки/доступа (LinkedHash, основа LRU) и сортированный (Tree, O(log n)) — с ловушкой «сравнение по compareTo, а не equals».
5. Итераторы и fail-fast поведениеfor-each как Iterator и механизм modCount: почему ConcurrentModification Exception — это однопоточный баг обхода, как удалять правильно и почему fail-fast не защищает от потоков.
6. Потокобезопасные коллекцииТри уровня потокобезопасности и правило атомарности: ConcurrentHashMap с lock-free чтением и compound-методами, CopyOnWriteArrayList для read-heavy и блокирующие очереди для producer-consumer.

Функциональный слой Java: лямбды и ссылки на методы, конвейер Stream с ленивыми промежуточными операциями, коллекторы, Optional и цена параллельных стримов.

1. Лямбды и функциональные интерфейсыЛямбда как реализация единственного метода функционального интерфейса с типом из target type; стандартный набор java.util.function, ссылки на методы, захват через effectively final и лексическая прозрачность this.
2. Конвейер Stream: ленивость и исполнениеStream как ленивый конвейер: промежуточные операции описывают и ничего не считают до терминальной, элементы текут поэлементно (отсюда short-circuit и бесконечные источники), а сам стрим одноразовый.
3. Коллекторы: сбор, группировка, агрегацияCollector как композируемый рецепт свёртки: toMap с требованием уникальных ключей (иначе IllegalStateException) или merge, groupingBy/partitioningBy и downstream-агрегация группы за один проход.
4. Optional: семантика и границы примененияOptional как контракт в типе возвращаемого значения «результата может не быть»: извлечение через orElse/ifPresent вместо опасного get, композиция map/flatMap и почему он не для полей и параметров.
5. Параллельные стримы и их ценаparallelStream как разделяй-и-властвуй на ОБЩЕМ commonPool: выгоден лишь при делимом источнике, большом N×Q и stateless-операциях, а блокирующие задачи и мелкие данные делают его вредным.

Среда выполнения Java: устройство памяти (куча, стеки, metaspace), поколения и алгоритмы сборки мусора, загрузка классов, JIT-компиляция и диагностика проблем с памятью. Отделяет гарантии языка от поведения под нагрузкой.

1. Память JVM: куча, стеки, metaspaceКарта раздельных областей памяти с разными лимитами: объект в куче, ссылка в стеке, классы в metaspace — и почему каждый вид OutOfMemoryError лечится по-своему, а не -Xmx.
2. Сборка мусора: достижимость и поколенияМусор — недостижимое от корней (циклы собираются, забытые ссылки — нет); гипотеза «объекты умирают молодыми» даёт поколения, дешёвый minor против дорогого full и паузы stop-the-world.
3. Алгоритмы GC: G1, ZGC и выбор коллектораКоллекторы как точки на оси «пропускная способность против задержки»: сбалансированный дефолт G1, субмиллисекундный ZGC ценой накладных расходов, и выбор по профилю нагрузки.
4. Ссылки: strong, soft, weak, phantomЧетыре силы ссылок как шкала политик достижимости: soft под давлением памяти против weak сразу, phantom для пост-мортем очистки — и почему finalize заменён try-with-resources и Cleaner.
5. Загрузка классовИерархия загрузчиков с делегированием вверх и идентичность класса как «имя + загрузчик»: изоляция плагинов, «Foo к Foo не кастуется» и разница ClassNotFoundException против NoClassDefFoundError.
6. JIT: от интерпретации к машинному кодуДвухфазное исполнение: интерпретатор ради старта, JIT горячего ради пика; tiered C1/C2, инлайнинг и escape analysis, деоптимизация — и почему бенчмарк без прогрева лжёт.
7. OutOfMemoryError и поиск утечекДиагностика памяти в четыре шага: область из сообщения, утечка против недоразмера по live set, утечка как достижимое ненужное и поиск удерживателя через heap dump и dominator tree.

Многопоточность в Java: потоки и их жизненный цикл, мониторы и synchronized, volatile и видимость, пулы потоков и ExecutorService, CompletableFuture, явные блокировки и координация, виртуальные потоки. Гонки, взаимоблокировки и как их не создавать.

1. Потоки: создание, состояния, прерываниеШесть состояний потока, демоны и завершение JVM, и почему остановить поток можно только кооперативно: interrupt как просьба и правильная реакция на InterruptedException.
2. Мониторы: synchronized, wait и notifyМонитор объекта и взаимное исключение, координация через wait/notify с обязательным while-циклом, и почему разный порядок захвата двух мониторов даёт взаимоблокировку.
3. Volatile, атомарность и гонки данныхДве ортогональные проблемы — видимость (чинит volatile) и атомарность (не чинит): почему count++ остаётся гонкой и как выбрать между volatile, Atomic и блокировкой.
4. Пулы потоков и ExecutorServiceПул разделяет задачу и поток: неинтуитивная логика core→очередь→max→отказ, ловушка неограниченной очереди в newFixedThreadPool и отказ как backpressure.
5. CompletableFuture: композиция асинхронных задачКонвейер стадий вместо блокирующего get: thenApply/thenCompose/thenCombine, ошибки, текущие по цепочке через exceptionally/handle, и осознанный выбор исполнителя вместо commonPool.
6. Явные блокировки и примитивы координацииНабор специализированных инструментов под тип задачи: ReentrantLock с tryLock против deadlock, ReadWriteLock для read-heavy и Semaphore/Latch/ Barrier для не-взаимоисключающей координации.
7. Виртуальные потокиСмена экономики блокирующего I/O: отмонтирование от carrier при блокировке, масштаб вместо скорости, и три границы — не для CPU, беречься pinning, не пулить.

Формальная модель того, что потоки видят в памяти: happens-before, безопасная публикация объектов, атомики и CAS, ThreadLocal. Объясняет, почему код без синхронизации может видеть устаревшие данные.

1. Happens-before и гонки данныхВидимость между потоками возникает только через ребро happens-before (монитор, volatile, start, join, program order); два конфликтующих доступа без ребра — data race, а data-race-free программа ведёт себя sequentially consistent.
2. Безопасная публикация и finalПубликация ссылки и инициализация полей не упорядочены без happens-before — объект утекает недостроенным; final даёт видимость через freeze при отсутствии this-escape, а идиомы публикации и DCL с volatile создают нужное ребро.
3. Атомики и CAScount++ теряет обновления; CAS даёт атомарное условное обновление и lock-free оптимистичный цикл, Atomic его инкапсулируют с volatile-видимостью, под контеншеном LongAdder бьёт AtomicLong, а CAS уязвим к ABA.
4. ThreadLocal: изоляция состояния по потокуThreadLocal даёт каждому потоку свою копию — делить нечего, синхронизация не нужна; идеален для per-request контекста, но в пуле поток переживает задачу, поэтому без remove() в finally значение протекает в следующий запрос.

Основание Spring: IoC-контейнер и ApplicationContext, конфигурация и сканирование компонентов, автоконфигурация Spring Boot, externalized configuration с профилями и запуск приложения со встроенным сервером.

1. IoC-контейнер и ApplicationContextЧто такое IoC-контейнер и бины: как ApplicationContext читает конфигурацию и строит граф объектов, чем он отличается от BeanFactory и почему синглтоны создаются на старте приложения.
2. Конфигурация: @Configuration, @Bean и сканированиеДве дороги объявить бин — @Configuration/@Bean и сканирование со стереотипами. Почему вызов @Bean-метода не создаёт новый объект и чем full-режим конфигурации отличается от lite.
3. Автоконфигурация и стартерыОткуда в Boot-приложении берутся бины, которых никто не писал: стартеры, условия @Conditional, уступка пользовательским бинам и чтение condition evaluation report.
4. Внешняя конфигурация и профилиКак Boot разрешает конфликты конфигурации: стопка источников от файлов в jar до аргументов запуска, relaxed binding, @ConfigurationProperties и профили окружений.
5. Старт приложения и встроенный серверЧто происходит между main() и приёмом трафика: ось событий старта, выбор типа контекста, встроенный Tomcat как бин, раннеры и диагностика падений и медленного старта.

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

1. Жизненный цикл бинаКонвейер создания бина: инстанцирование, внедрение, колбэки инициализации в фиксированном порядке и пост-процессоры, на которых появляются прокси. Почему @PostConstruct — не «после старта приложения».
2. Области видимости биновScope как правило создания экземпляров: чем Spring-синглтон отличается от GoF, почему prototype не уничтожается контейнером и как чинить инъекцию короткоживущего бина в долгоживущий.
3. Способы внедрения зависимостейКонструктор, сеттер и поле как разные наборы гарантий: иммутабельность, non-null и тестируемость без контейнера. Правила @Autowired и цена полевой инъекции.
4. Разрешение неоднозначностейЧто делает контейнер, когда кандидатов несколько: воронка выбора, @Primary и @Fallback как приоритет, @Qualifier как смысловой фильтр и коллекции как «взять всех».
5. Циклические зависимостиПочему кольцо зависимостей неразрешимо для конструкторов, чем платит сеттерная лазейка с ранними ссылками, почему Boot запрещает циклы по умолчанию и как разрывать их дизайном.

Как работает «магия» Spring: динамические прокси JDK и CGLIB, модель аспектов, @Transactional под капотом и ограничения прокси-подхода — самовызов, final-методы, видимость.

1. Динамические прокси: JDK и CGLIBПрокси как отдельный объект перед целью: JDK-прокси по интерфейсам против CGLIB-подкласса, дефолт Spring Boot, ограничения final и private и почему вызов через this минует обёртку.
2. Модель Spring AOP: аспекты, advice, pointcutСловарь AOP поверх знакомых прокси: аспект, пять типов совета как try/catch/finally, язык точек среза execution и @annotation, границы рантайм-плетения Spring.
3. @Transactional под капотомТранзакционный перехватчик на прокси: почему checked-исключения не откатывают, что такое rollback-only маркер и UnexpectedRollbackException, и как выбирать между REQUIRED, REQUIRES_NEW и NESTED.
4. Ограничения прокси: самовызов и границыДиагностика молчащих аннотаций: один вопрос «прошёл ли вызов через прокси» и пять причин отказа — от самовызова и final-методов до бинов, созданных слишком рано.

Слой, где контракт API превращается в код: путь запроса через DispatcherServlet, контроллеры и привязка параметров, валидация, единый формат ошибок и сериализация через Jackson.

1. DispatcherServlet: путь запросаКарта пути HTTP-запроса: front controller с делегатами по ролям, execution chain с интерцепторами, запись REST-ответа в адаптере и честная разница между фильтром и интерцептором.
2. Контроллеры и привязка параметровСигнатура как декларация каналов: путь, query, заголовки и тело через резолверы аргументов, правила обязательности и конверсии, три типовых 400 и ловушка DTO без @RequestBody.
3. Валидация входных данныхBean Validation на границе API: включатели @Valid и метод-валидация с разными исключениями, фаза между привязкой и методом и честная граница «форма — на входе, истина — в домене».
4. Обработка ошибок и ProblemDetailФормат ошибок как часть контракта: @ControllerAdvice как единая таблица перевода исключений, стандарт ProblemDetail с application/problem+json и готовая база для всех Spring-исключений.
5. Сериализация: Jackson и DTOОдин настроенный JsonMapper на приложение, управление формой JSON и три болезни сериализации сущностей — почему наружу выходят только намеренные контракты-DTO.

Семантика протокола, на которой держится любой API: методы и коды состояния, безопасность и идемпотентность, кэширование с условными запросами, версионирование и эволюция контракта.

1. Методы и коды состоянияМетод как объявленное намерение и код как честный машиночитаемый исход: семантика методов по RFC 9110, граница 4xx/5xx и почему «200 на всё» ломает кэши, ретраи и алерты.
2. Безопасность и идемпотентностьДва контрактных свойства методов по RFC 9110: почему идемпотентность — про эффект на состояние, а не про ответ, и как ключ идемпотентности делает POST безопасным для повтора.
3. Кэширование и условные запросыДва рычага HTTP-кэша — свежесть и ревалидация через ETag/304 — и вторая роль ETag: защита от потерянных обновлений через If-Match/412, та же оптимистическая блокировка, что @Version.
4. Версионирование и эволюция APIВерсию порождает только ломающее изменение: классификация изменений, стратегии версионирования с компромиссами и управляемая депрекация через заголовки Deprecation и Sunset.

ORM поверх реляционной БД: persistence context и жизненный цикл сущности, маппинг связей, стратегии загрузки и проблема N+1, запросы и проекции, транзакции и блокировки, кэши Hibernate. Ключевой навык — видеть, какой SQL порождает код.

1. ORM и persistence contextРабочая память между кодом и базой: identity map, dirty checking и write-behind. Почему UPDATE происходит без save, а SQL выполняется не в порядке кода.
2. Жизненный цикл сущностиЧетыре состояния сущности как отношение к контексту: почему merge возвращает другую managed-копию, что на самом деле делает save Spring Data и как определить состояние объекта в любой точке кода.
3. Маппинг связейОдин внешний ключ против двух объектных ссылок: владелец связи и mappedBy, хелперы синхронизации, осознанные каскады и отличие orphanRemoval от cascade=REMOVE.
4. Ленивая загрузка и проблема N+1Lazy-заглушки и их контекст-владелец: откуда берутся LazyInitializationException и N+1, как их видеть в SQL-логе и чинить формой выборки — fetch join, EntityGraph, batch size — а не EAGER'ом.
5. Запросы: JPQL, производные методы и проекцииТри источника запроса в Spring Data и их приоритет, JPQL как язык модели, пагинация с ценой count-запроса и проекции — чтение без аренды persistence context.
6. Транзакции и блокировки в JPAПотерянные обновления и почему @Transactional от них не защищает: @Version с обработкой конфликтов, пессимистичные блокировки через @Lock и атомарный UPDATE как третий путь.
7. Кэши HibernateТри кэша с разными контрактами: первый уровень как сам persistence context, второй — выключенная по умолчанию подписка с риском устаревания, кэш запросов — надстройка с грубой инвалидацией.

Слой под ORM: JDBC как протокол доступа, пулы соединений и их настройка, границы транзакций на уровне соединения и версионирование схемы через миграции. Именно этот слой определяет поведение под нагрузкой.

1. JDBC: соединение, statement, результатJDBC как слой под ORM: PreparedStatement передаёт значения отдельно от текста SQL (структурная защита от инъекций), ResultSet — курсор, а autocommit делает каждый statement транзакцией — многошаговое обернуть setAutoCommit(false).
2. Пулы соединенийСоединение дорого установить — пул переиспользует; контринтуитивно пул должен быть МАЛЫМ (~(ядра2)+диски), потому что параллелизм БД ограничен, а connectionTimeout и утечки соединений задают поведение под нагрузкой.
3. Миграции схемыСхема как версионированный код из упорядоченных неизменяемых миграций в schema history table (checksum сторожит), откат — компенсирующей миграцией вперёд, а zero-downtime требует совместимости с работающим кодом через expand-contract.

Асинхронный обмен событиями через Kafka: архитектура (топики, партиции, offset), продюсеры и консьюмеры, семантики доставки, идемпотентность потребителя и обработка отравленных сообщений, интеграция через Spring Kafka.

1. Зачем брокер сообщенийФакт-подписка вместо вызова-ответа: временная развязка, буфер пиков и fan-out читателей — и честная цена в виде согласованности со временем, двойной записи и распределённой отладки.
2. Архитектура KafkaПартиционированный журнал: почему порядок живёт в партиции и выбирается ключом, offset принадлежит потребителю, надёжность — контракт ISR, а метаданными правит KRaft.
3. Продюсер: ключи, партиционирование, гарантииАсинхронный конвейер записи: партиция по хэшу ключа, батчинг, договорная сила acks поверх ISR и идемпотентный продюсер — что он снимает, а какие дубли остаются вам.
4. Консьюмеры и группыГруппа как распределённый читатель: потолок масштабирования в партициях, два таймера живости, цена ребалансировки и коммит позиции как архитектурное решение с исходами при сбое.
5. Семантики доставкиТри семантики как порядок «обработать/зафиксировать позицию», транзакции Kafka с offset'ом внутри и честная граница exactly-once: внутри Kafka-конвейера — настройкой, до вашей БД — инженерией.
6. Идемпотентность потребителя, retry и DLQИнженерия потребителя при at-least-once: идемпотентность через целевое состояние или таблицу обработанных сообщений, классификация сбоев, ограниченные ретраи и dead letter topic как очередь на расследование.
7. Spring for Apache KafkaПаттерны модуля в коде: коммит-модель контейнера и AckMode, DefaultErrorHandler с классификацией ошибок, DLQ через DeadLetterPublishingRecoverer и защита от битой десериализации.

Безопасность Spring-приложения: цепочка фильтров и SecurityContext, модель аутентификации, правила авторизации, stateless REST API с JWT, а также CSRF, CORS и сессии.

1. Цепочка фильтров и SecurityContextSpring Security — упорядоченная цепочка сервлет-фильтров ПЕРЕД контроллером, отсекающая неавторизованное до бизнес-кода; текущий пользователь живёт в SecurityContextHolder на ThreadLocal и очищается в конце запроса.
2. Модель аутентификацииАутентификация — делегирование manager→provider→UserDetailsService+PasswordEncoder; пароль хранят односторонней адаптивной функцией (bcrypt: намеренно медленной, с солью и work factor), а не быстрым SHA-256, который перебирается миллиардами/сек.
3. Авторизация: URL и методыПравила authorizeHttpRequests применяются по порядку (первое совпадение выигрывает), роль — это authority с префиксом ROLE_, который hasRole добавляет сам, а @PreAuthorize даёт тонкую метод-безопасность поверх URL (defense in depth).
4. Stateless API: JWT resource serverStateless REST: сервер проверяет самодостаточный JWT по ПОДПИСИ без хранилища (claims→authorities), payload лишь base64 (не шифр), а цена statelessness — токен нельзя отозвать до exp (короткий TTL+refresh или blocklist).
5. CSRF, CORS и сессииТри разных механизма: CSRF защищает от авто-отправки cookie (токен на небезопасных методах, отключаем лишь при bearer-заголовке), CORS — браузерное правило cross-origin чтения (не авторизация), а сессию для API выключают STATELESS.

Что отличает рабочий сервис от учебного: операционные требования, Actuator и health-проверки, корректное завершение под трафиком, конфигурация окружений и обращение с секретами.

1. Что значит production-readyProduction-ready — набор свойств КОДА (наблюдаемость, устойчивость, конфиг из окружения, graceful shutdown, statelessness), а не «задачи DevOps»: оркестратор лишь использует заложенное разработчиком, а 12-factor систематизирует эти свойства.
2. Actuator и health-проверкиActuator открывает наружу только /health (остальное закрыть — утечка секретов); liveness проверяет внутреннее (сбой→рестарт), readiness — внешние зависимости (сбой→вывод из трафика без рестарта), а БД в liveness даёт каскадные рестарты.
3. Корректное завершениеКорректное завершение — упорядоченный дренаж (SIGTERM→readiness→стоп новых→дожитие активных в grace-таймаут→закрытие ресурсов) плюс координация с балансировщиком через preStop-зазор, иначе гонка «ЛБ ещё шлёт / сервер уже закрыл» рвёт запросы при деплое.
4. Конфигурация окружений и секретыConfig отделяют от кода в переменные окружения (один артефакт на все среды, лакмус open source), а секреты не хранят ни в git (история/форки), ни в образе (распаковка) — только в менеджере секретов с рантайм-внедрением и ротацией.

Пирамида тестов для Java-бэкенда: JUnit 5, тестовые дублёры с Mockito, срезы контекста Spring, интеграционные тесты с реальными зависимостями через Testcontainers и проектирование кода под тестируемость.

1. Пирамида тестовМного быстрых юнит-тестов внизу, меньше интеграционных, мало медленных E2E наверху: чем выше — тем меньше (дороже/хрупче/медленнее); ice-cream cone — антипаттерн, а стратегия — толкать тесты вниз без дублирования покрытия.
2. JUnit 5JUnit создаёт новый экземпляр на каждый тест (изоляция — течёт лишь static); BeforeEach на каждый vs BeforeAll один раз static, assertThrows/assertAll вместо ручного try/catch, а @ParameterizedTest покрывает много входов одним методом.
3. Mockito и тестовые дублёрыПять видов дублёров, где stub проверяет состояние/результат, а mock — поведение/вызовы (verify лишь для не-наблюдаемых эффектов); over-mocking привязывает тест к реализации, поэтому мокают на границах и предпочитают проверку результата.
4. Тесты Spring: срезы контекстаСрезы (@WebMvcTest, @DataJpaTest) грузят только нужный слой вместо полного @SpringBootTest; Spring кэширует контекст при одинаковой конфигурации, поэтому разнобой @MockitoBean/property плодит контексты и тормозит набор.
5. Интеграционные тесты с TestcontainersСуррогаты (H2/мок) ведут себя иначе прода и дают ложную уверенность — Testcontainers поднимает реальную БД/Kafka в одноразовом контейнере (static на класс, @ServiceConnection для Spring) ценой скорости и зависимости от Docker.
6. Проектирование под тестируемостьТестируемость — свойство дизайна, а не тестов: трудный тест = симптом связанного кода; инъекция зависимостей даёт шов, чистые функции тестируются без моков, а время и случайность прячут за подменяемую абстракцию (Clock), инфраструктуру — за порт.

Три канала наблюдаемости Java-сервиса: структурное логирование с корреляцией, метрики через Micrometer и распределённая трассировка с OpenTelemetry. Без них поведение под нагрузкой остаётся непрозрачным.

1. Логи, метрики, трассировкиТри канала отвечают на разные вопросы: метрики — «что не так», трассировки — «где в цепочке», логи — «почему»; ни один не достаточен, а сила — в корреляции через trace id (расследование метрика→трассировка→лог).
2. Структурное логированиеSLF4J-фасад + Logback с дисциплиной уровней (INFO в проде), структурный JSON для машинной агрегации вместо plain-text, MDC с trace id для корреляции строк запроса (очищать в пуле) и запрет секретов/PII в логах.
3. Метрики: MicrometerТип метрики выбирают под природу величины (Counter растёт, Gauge колеблется, Timer — длительность+перцентили); теги дают срезы, но высококардинальный тег (userId/uuid) взрывает мониторинг — а RED задаёт каркас ключевых метрик.
4. Распределённая трассировкаTrace — путь одного запроса из дерева спанов (где потрачено время); распространение контекста (trace id через traceparent/Kafka-заголовки) сшивает спаны разных сервисов, OpenTelemetry — стандарт, а сэмплирование держит стоимость под контролем.

Доставка Java-сервиса: образы и Dockerfile с учётом особенностей JVM, основы Kubernetes (поды, деплойменты, конфигурация), пробы и лимиты ресурсов, конвейер сборки и деплоя.

1. Контейнеры: изоляция и образыКонтейнер разделяет ядро хоста (не своя ОС, как у ВМ) — потому лёгкий и быстрый; образ — стек кэшируемых слоёв из реестра, несущий приложение с зависимостями, что даёт одинаковое окружение от ноутбука до прода.
2. Dockerfile для Java-приложенияMulti-stage (финал без build-инструментов), кэш-порядок (зависимости до кода), slim JRE и non-root; а JVM должна видеть cgroup-лимиты (UseContainerSupport/ MaxRAMPercentage), иначе размеряет heap от памяти хоста и падает OOMKilled.
3. Kubernetes: поды, деплойменты, сервисыПод эфемерен (новый IP при пересоздании), поэтому клиенты ходят через стабильный service; deployment декларативно держит реплики, катит rolling update без даунтайма и самовосстанавливается, а ConfigMap/Secret вносят конфигурацию снаружи.
4. Пробы и ресурсы подаТри пробы (liveness→рестарт, readiness→из трафика, startup→защита медленного старта JVM); requests планируют, limits ограничивают, а превышение memory limit убивает под (OOMKilled, несжимаема) против троттлинга CPU (сжимаем).
5. Конвейер CI/CDАвтоматический путь коммит→прод: тесты как ворота на каждый коммит, один неизменный образ по средам (build once), миграции в конвейере (expand-contract) и деплой стратегией (rolling/blue-green/canary) с быстрым откатом на предыдущий образ.

Сервис среди ненадёжных соседей: режимы отказов и каскады, повторы с таймаутами, размыкатель цепи, изоляция ресурсов и осознанная деградация.

1. Режимы отказов и каскадыМедленный ответ хуже быстрой ошибки — держит потоки/соединения, исчерпывает общий пул и роняет несвязанные запросы, а отказ каскадно идёт вверх по цепочке; нужен бюджет времени с таймаутами, а стратегия зависит от transient/non-transient.
2. Таймауты и повторыТаймаут на каждом вызове; повтор только идемпотентных операций (иначе двойной эффект — idempotency key), с экспоненциальным backoff и джиттером против ретрай-шторма, ограниченным числом попыток и остановкой при non-transient.
3. Размыкатель цепиАвтомат closed→open→half-open: при превышении порога сбоев за окно open сразу отказывает без вызова (экономит ресурсы и даёт восстановиться), half-open осторожно пробует; в отличие от retry breaker предотвращает обречённый вызов, а при open отдаёт fallback (Resilience4j).
4. Изоляция и деградацияBulkhead даёт каждой зависимости свой пул/лимит — медленная топит только свой отсек, не общий пул (решение каскада); осознанная деградация возвращает урезанное вместо полного отказа, а устойчивость складывается из слоёв (таймаут+retry+breaker+bulkhead+деградация).

Обзорный модуль-развилка: как выбирать направление роста после уверенного владения основой — профилирование JVM, специализированные протоколы, реактивный стек, соседние языки платформы.

1. Как выбирать специализациюСпециализацию выбирают от реальной потребности проекта/роли, а не от хайпа: у каждого направления (профилирование/gRPC/реактив/языки) свой сигнал «пора» и признак преждевременности, а ширина крепкой основы важнее преждевременной глубины в одном.

Поиск узких мест по измерениям: методология профилирования, Java Flight Recorder и Mission Control, CPU- и аллокационные профили с флеймграфами, чтение GC-логов и базовая настройка сборщика.

1. Сначала измерениеИнтуиция о горячем месте систематически ошибается, поэтому оптимизация без профиля — угадывание; работает цикл гипотеза→метрика→профиль→изменение→повторное измерение с целью уложиться в бюджет задержки, меняя одно за раз на реальной нагрузке.
2. Java Flight Recorder и Mission ControlJFR встроен в JVM с оверхедом ~1% и безопасен в проде непрерывно (чёрный ящик), пишет события (методы/аллокации/локи/GC/I/O) через флаг или jcmd, а JMC открывает .jfr и автоматически диагностирует проблемы — первый выбор прод-профилирования без агентов.
3. CPU- и аллокационные профилиСэмплирующий профайлер статистически оценивает нагрузку, а флеймграф читается по ширине (шире=горячее); JVMTI-профайлеры страдают safepoint bias (время не туда), async-profiler сэмплит в любой точке и различает CPU- и аллокационный профили.
4. GC-логи и базовая настройкаТри метрики GC (throughput/latency/footprint) — компромисс; GC-логи показывают, GC ли узкое место, но большинство проблем от кода (темп аллокаций/удержание), поэтому фикс — сначала код по alloc-профилю, а коллектор и кучу меняют лишь после измерения.

Бинарный RPC поверх HTTP/2: контракты в protobuf, генерация кода и виды вызовов, дедлайны и обработка ошибок, стриминг. Когда gRPC выигрывает у REST и какой ценой.

1. Модель gRPC: protobuf и HTTP/2gRPC — contract-first бинарный RPC: .proto→codegen, protobuf кодирует номера полей (эволюция добавлением, номер неприкосновенен), поверх HTTP/2 с мультиплексированием — эффективнее REST для межсервиса, но бинарно и не для браузера.
2. Сервисы, стабы и дедлайныprotoc генерирует стабы (blocking/async); deadline — абсолютная точка, пропагируемая по хопам (downstream наследует остаток) как единый бюджет цепочки, при истечении → DEADLINE_EXCEEDED с авто-отменой; ошибки — статус-коды gRPC, контекст — метаданные.
3. СтримингЧетыре типа RPC (unary + server/client/bidi streaming) под форму данных (фид/загрузка чанками/интерактив); порядок сообщений внутри стрима гарантирован, HTTP/2 flow control даёт backpressure, а частичность до отмены не откатывается.

Неблокирующий стек: модель реактивных потоков с обратным давлением, типы Reactor (Mono, Flux), WebFlux против MVC и честное сравнение с виртуальными потоками.

1. Реактивные потоки и обратное давлениеPublisher/Subscriber/Subscription с неблокирующим backpressure: потребитель задаёт темп через request(n) (в отличие от безграничных колбэков), а блокировка внутри пайплайна стопорит немногочисленные event-loop-потоки и рушит throughput.
2. Reactor: Mono, Flux и операторыMono(0/1)/Flux(0..N) холодные — без subscribe ничего; map — sync 1-к-1, flatMap — async (элемент→Publisher, разворачивает); ошибки — сигнал onError вниз по цепочке (onErrorResume, не try/catch), а subscribeOn/publishOn уносят блокирующее с event loop.
3. WebFlux, MVC и виртуальные потокиMVC прост, но упирается в пул потоков; WebFlux масштабирует IO малым event-loop-пулом ценой полностью неблокирующего стека и сложной отладки (спецтул, не дефолт); виртуальные потоки (Java 21+) дают масштаб при простоте MVC — выбор по нагрузке и команде, не по хайпу.