NMT в HotSpot: сначала включить, потом искать рост

Native Memory Tracking нужно включить при старте JVM, например флагом -XX:NativeMemoryTracking=summary. Если процесс уже работает без NMT, включить сбор через jcmd не получится.

После прогрева сохраните базу командой jcmd <pid> VM.native_memory baseline. Позже jcmd <pid> VM.native_memory summary.diff покажет изменения по категориям относительно неё.

NMT учитывает внутренние аллокации HotSpot, но не всю память стороннего native-кода. Рост категории даёт направление для диагностики, а не готовое доказательство утечки.

На карточке — команды из руководства Oracle Java 25.

Native Memory Tracking в HotSpot
#jvm #java

Micrometer: каждый новый 404 может раздувать метрику

Если в собственной инструментализации записывать сырой URI в тег метрики, запросы к /missing/a, /missing/b и тысячам других несуществующих путей дадут тысячи разных значений тега.

Micrometer разбирает именно такой пример: если не ограничивать значения URI для 404, кардинальность метрики растёт с каждым новым отсутствующим ресурсом. Вместо произвольного пути можно использовать ограниченное значение вроде NOT_FOUND.

Это задача проектирования собственных тегов. Из примера не следует, что все интеграции Spring Boot по умолчанию записывают сырые 404-пути.

На схеме меняется только тег URI. Значения условные, измерений памяти здесь нет.

Micrometer: Tag Values

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.