Kafka: heartbeat не заменяет вызовы poll

Consumer может отправлять heartbeat и при этом слишком долго обрабатывать пачку. В Java-клиенте Kafka 4.0 прогресс проверяется отдельно: интервал между вызовами poll ограничивает max.poll.interval.ms.

Если интервал превышен, consumer рискует потерять партиции, а коммит может завершиться CommitFailedException. Размер пачки ограничивает max.poll.records. Увеличение интервала даёт больше времени на обработку, но может замедлить rebalance.

Если обработку вынести в worker, consumer должен продолжать вызывать poll. Auto commit отключают, партиции приостанавливают до конца обработки, а offsets коммитят вручную только после обработки. Сам KafkaConsumer не thread-safe: worker-потоки не должны произвольно вызывать его методы.

KafkaConsumer 4.0: Detecting Consumer Failures

StampedLock: читать поля можно до проверки, использовать — после

Оптимистическое чтение в StampedLock обходится без удержания read lock. Поток получает stamp через tryOptimisticRead(), копирует поля в локальные переменные и вызывает validate(stamp). Использовать прочитанные значения можно после успешной проверки.

Если за это время другой поток захватывал write lock, проверка провалится. В примере Oracle чтение повторяют уже под read lock. До проверки поля могут противоречить друг другу. При обходе изменяемого массива или вызове метода по прочитанной ссылке могут понадобиться дополнительные проверки согласованности данных.

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

StampedLock, Java SE 25
#java

ClassValue хранит вычисленные данные для каждого класса

Таблицу методов для диспетчеризации или разобранные метаданные можно кешировать отдельно для каждого класса. Для такой задачи у JDK есть ClassValue<T>: get(type) возвращает значение, связанное с конкретным Class, и при необходимости запускает computeValue(type).

При гонке вычисление может выполниться несколько раз. С классом свяжется одно значение, его и получат вызывающие потоки. Поэтому computeValue должен допускать повторный вызов. Если внутри отправлять платёж или регистрировать ресурс с необратимым побочным эффектом, гарантий «ровно один раз» не будет.

remove(type) убирает связь и инвалидирует устаревшие вычисления. При следующем обращении значение можно вычислить заново. Здесь удобно хранить именно данные, зависящие от класса, а не произвольный кеш по бизнес-ключам.

ClassValue, Java SE 25
#java

Дерево процессов в ProcessHandle меняется во время обхода

Java-сервис запускает внешний конвертер, а тот порождает дочерние процессы. children() даёт только прямых детей, descendants() — потомков всех уровней. Оба метода возвращают снимок, а не живую коллекцию.

Процесс из снимка может завершиться ещё до того, как до него дойдёт обход. Между проверкой isAlive() и действием тоже остаётся гонка. Хранить только PID тоже рискованно: после завершения процесса ОС может выдать этот номер другому.

Поэтому один обход descendants() не гарантирует, что вся группа процессов будет остановлена. Для управления внешней задачей нужны обработка ошибок и учёт ограничений ОС. ProcessHandle не даёт прав сверх тех, что есть у обычного нативного приложения.

ProcessHandle, Java SE 25
#java

transferTo может скопировать меньше запрошенного

Вызов FileChannel.transferTo(position, count, target) возвращает число реально переданных байтов. Оно может быть меньше count и даже равняться нулю. Например, у неблокирующего target может не хватить места в выходном буфере.

При повторном вызове нужно сдвинуть явный offset и уменьшить остаток на число переданных байтов. Позиция исходного FileChannel сама не меняется. Если offset уже достиг текущего размера файла, новых байтов не будет.

Если метод вернул ноль, повтор без ожидания готовности target или проверки конца файла может превратиться в пустой цикл.

ОС иногда передаёт данные прямо из файлового кеша. Это может ускорить передачу, но документация не обещает zero-copy для любой системы и любого канала.

FileChannel.transferTo, Java SE 25
#java

G1 не использует остаток региона после большого объекта

G1 в JDK 25 считает humongous объект размером не меньше половины региона. Он попадает в последовательность соседних регионов old generation. Остаток последнего региона недоступен другим аллокациям до освобождения всего объекта.

Поэтому свободные байты в heap ещё не означают, что для следующего большого объекта найдётся достаточно соседних свободных регионов. Размер региона G1 выбирает автоматически, если его не задали через -XX:G1HeapRegionSize.

Ставшие недостижимыми humongous-объекты обычно освобождаются на Remark или Full GC. Для массивов примитивов есть механизм раннего освобождения. Одна большая аллокация сама по себе не означает обязательный Full GC: поведение нужно сопоставлять с логами и заполнением heap.

Oracle: Humongous Objects, JDK 25
#jvm

Завершённый шаг Spring Batch при рестарте пропускается

Job упал на финальном шаге. При рестарте того же JobInstance Spring Batch обычно пропускает шаги со статусом COMPLETED. Если проверку входных данных или уборку ресурсов нужно выполнять каждый раз, у шага задают allowStartIfComplete(true).

Другая настройка, startLimit, ограничивает число запусков шага. В примере документации лимит равен 2: после двух неудач на третьей попытке шаг уже не запускается. Повтор требует вмешательства, например изменения лимита или запуска нового JobInstance.

Настройки рестарта не отменяют уже отправленное письмо или выполненный внешний HTTP-запрос. Что произойдёт при повторе таких действий, нужно определить в самом шаге и его интеграциях.

Spring Batch 6.0.6: Configuring a Step for Restart
#spring

Opaque token проверяется через сервер авторизации

При introspection Resource Server отправляет bearer token на endpoint сервера авторизации со своими учётными данными. В ответе Spring Security проверяет active: true, а scopes превращает в authorities с префиксом SCOPE_.

По умолчанию principal — OAuth2AuthenticatedPrincipal. Имя аутентификации берётся из sub, если это поле есть в ответе. Для настройки нужны адрес introspection endpoint, client ID и client secret.

В стандартной цепочке проверка токена зависит от доступности introspection endpoint. Собственный кеш меняет частоту обращений к нему и поведение при отзыве токена. При такой настройке нельзя заранее обещать мгновенный отзыв.

Spring Security 7.1.2: Opaque Token
#spring

BTrace: временная трассировка работающей JVM

Когда нужен ответ на конкретный вопрос о работающем Java-приложении, BTrace позволяет подключить Java-пробу к процессу. Инструментация временная, без изменения кода приложения и его перезапуска.

В wiki BTrace для стабильной ветки 2.2.x указан namespace org.openjdk.btrace. Это стоит учитывать при поиске примеров: старый скрипт и текущая версия инструмента могут использовать разные имена пакетов.

BTrace можно применять вместе с JFR: JFR даёт непрерывную историю, проба помогает собрать целевые наблюдения для текущей диагностики. Перед подключением нужно отдельно проверить совместимость с целевой JVM и права на attach. Описание инструмента не гарантирует, что проба будет безопасной, а накладные расходы — низкими на вашей нагрузке.

Что считает circuit breaker, если рядом есть retry

Порядок обёрток определяет, какие вызовы попадают в окно breaker. Если retry снаружи, а breaker внутри, breaker видит каждую попытку. При обратном порядке он видит итог целого запроса после повторов. Три попытки могут стать тремя записями в окне или одной.

В учебном проекте Fuse разобраны оба варианта. В цепочке декораторов последняя добавленная политика оказывается внешней. От порядка обёрток зависит и момент, когда breaker узнает о сбое.

Отдельная ловушка — повторять CallNotPermittedException от открытого breaker. До зависимости вызов уже не дошёл, а retry может продолжить тратить бюджет попыток и ждать backoff. Автор предлагает исключить этот тип из повторов.

Fuse полезен как разбор реализации. Для production его автор рекомендует Resilience4j.

Какая JVM расходует ресурсы в Gradle-тестах

Когда тесты распараллелены, общего времени задачи мало для диагностики. InfoTestProcess связывает CPU, heap, GC и JIT каждого воркера с PID и задачей Gradle.

Агент записывает идентификаторы при старте JVM, а при завершении снимает метрики через MXBean. Плагин объединяет эти файлы по PID. Это итог по процессу, а не профиль отдельных методов. Отсутствующие снимки учитываются отдельно.

В версии 2.2.1 нужны Gradle 8.2+ и JDK 17+ у воркеров. Без Develocity отчёт остаётся в build/info-test-process/statsTestTasks.json. В Build Scan при числе воркеров больше 950 сохраняются наиболее затратные по CPU, а усечение явно отмечается.

🎙 Открытое собеседование по Java с Senior-разработчиком из Uzum

Правильный ответ на собесе ещё не гарантирует оффер. На открытом мок-интервью разберём, что ещё оценивает интервьюер ↓

18 ноября в 19:00 МСК Сергей Чамкин, Senior-разработчик в Uzum, ex-Wildberries, проведёт техническое интервью с кандидатом!

У Сергея 7 лет коммерческого опыта с Java и Kotlin в highload-проектах. Он также проводил технические собеседования в EPAM, Wildberries и RNT Group.

За час эфира ты:
→ узнаешь, какие вопросы задают на технических собеседованиях по Java;
→ увидишь, какие ответы убеждают интервьюера, а какие вызывают сомнения;
→ поймёшь, какие темы стоит подтянуть перед собственным собеседованием.

Кандидат увидит вопросы впервые. Никакого заранее подготовленного сценария ☝🏻

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

🎁 Бонус за регистрацию: файл «50 эталонных ответов на сложные вопросы Java-интервью»

Переходи в бота, чтобы зарегистрироваться на эфир и забрать подарок:  @shortcut_sh_bot

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

Что именно анализирует JLiSA

Статический анализ работает с моделью программы. В JLiSA Java-код разбирает Eclipse JDT, затем фронтенд строит графы потока управления для LiSA. Абстрактные домены, межпроцедурную стратегию и проверки можно выбирать независимо.

Например, интервальный домен описывает диапазоны значений. Проверяющий компонент использует результат анализа, чтобы искать нарушения свойств программы. Меняется домен — меняется точность модели.

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

И не все режимы статические. check анализирует программу, а validate и find-bug запускают её через JDI. Для этих команд нужны модули jdk.compiler и jdk.jdi.