Шёл за утечкой памяти, нашёл утечку диска: SXSSFWorkbook без dispose() в Apache POI

Меня зовут Игорь Симаков, работаю engineering manager’ом и руковожу командами разработки

На одном из наших сервисов, который работает с XLSX-файлами, прилетел production-алерт на высокое потребление памяти. Стандартный P3, обычно решается рестартом. Пошёл смотреть поды и нашёл проблему, к памяти отношения не имеющую, но представляющую больший риск, чем сам алерт. Об этом и расскажу ниже: чем «утечка диска» отличается от «утечки памяти», как мы наткнулись на грабли в Apache POI и как закрыли их на уровне архитектуры

Утечка памяти и утечка диска: в чём разница

В обоих случаях логика одинаковая: приложение выделило ресурс и не освободило. Со временем расход растёт, пока не упрётся в потолок

Утечка памяти. Объекты копятся в куче Java (heap) или в native-памяти за её пределами — direct buffers (память для сетевого I/O в обход heap), нативные библиотеки, стеки потоков. Ссылка живёт там, где не должна, GC её не собирает. Память пода растёт, упирается в limits.memory, Kubernetes делает OOMKill, под перезапускается. Локальная проблема: страдает только сам сервис, лечится рестартом

Утечка диска. Приложение создаёт файлы и не удаляет. Здесь начинается интересное: упирается это не в потолок пода, а в свободное место на диске ноды. По умолчанию /tmp в поде — это emptyDir без sizeLimit, физически он лежит на диске ноды (тот же /dev/vda2, где живёт ОС, container runtime, логи контейнеров). У пода лимита нет, он пишет, пока место есть на ноде. Когда место заканчивается, write() возвращает ENOSPC, и падает не только наш сервис — падает всё, что пишет на этот диск, включая чужие поды и kubelet

Утечка памяти — локальная: Kubernetes отрабатывает её рестартом. Утечка диска распределённая, физический диск ноды один на всех, и автоматически его никто не «перезагрузит»

Что такое RSS

Дальше я буду писать «RSS пода = N MiB». Расшифрую сразу, чтобы не отвлекало.

RSS (Resident Set Size) — это сколько физической оперативной памяти процесс реально занимает прямо сейчас. Сюда входит всё: JVM heap, non-heap (метаспейс, code cache), native-аллокации (direct buffers, пулы Netty), стеки потоков, замапленные в память файлы

Виртуальной памяти процесс может «зарезервировать» больше, чем есть физической. Но в RSS считается только то, что реально лежит в RAM. Именно RSS показывает top в одноимённой колонке, и именно RSS Kubernetes сравнивает с limits.memory пода, чтобы решить, не пора ли OOMKill

Чем мы измеряем память: контейнер и JVM

Под «потреблением памяти» в Kubernetes обычно смешивают два разных набора метрик. Разведу их явно.

Метрики контейнера. Собирает cAdvisor, отдаёт в Prometheus. Ключевая — container_memory_working_set_bytes (грубо: RSS пода минус inactive file cache). По ней Kubernetes решает делать OOMKill, и по ней же триггерится наш алерт PodMemoryHigh85 — working_set / limits.memory > 0.85. Нотификация идёт через Alertmanager в Grafana OnCall

Метрики JVM. Spring Boot Actuator + Micrometer на /actuator/prometheus. Полезные: jvm.memory.used{area="heap"}, jvm.memory.used{area="nonheap"} (метаспейс, code cache), jvm.gc.pause. Видна только память, которой управляет JVM. Direct buffers, нативные либы, стеки потоков, OTel-агент для этих метрик невидимы

Если контейнер растёт, а heap стоит, то это утечка в native-памяти, -Xmx тут не поможет

Декорации

• Spring Boot 3, JDK 21, Apache POI 5.x

• Сервис отдаёт продавцам XLSX-шаблон с их остатками и принимает обратно заполненный. Файлы бывают большие, поэтому используется SXSSFWorkbook, streaming-вариант POI: он держит в памяти только окно последних N строк, а остальное сбрасывает на диск

• Прод: Kubernetes, два пода, limits.memory=2Gi, requests.memory=512Mi. /tmp смонтирован на host disk, не tmpfs

Что произошло

В понедельник в 05:41 UTC прилетел PodMemoryHigh85 на одном из подов: RSS выше 85% от limits.memory=2Gi

Состояние пода:

• uptime 6 суток 4 часа, не рестартился;

• RSS 1731 MiB (84.5% от 2Gi);

• JVM heap занимает всего 263 MiB, non-heap 327 MiB. То есть около 1.1 GiB RSS лежит вне JVM;

Тот самый разрыв между метриками контейнера и метриками JVM, про который я писал выше: 1.1 GiB лежит вне JVM, и actuator его не видит. Чтобы понять, кто конкретно ест память, нужен heap dump плюс знание про native-аллокаторы

Я снял heap dump через kubectl port-forward + jcmd, открыл в Eclipse MAT и нашёл главного аллокатора за пределами heap: Netty PoolArena, пул direct buffers для сетевого I/O. 21 арена по 16 MiB, около 336 MiB. Поведение штатное: Netty по умолчанию делает арену на каждый CPU, а в k8s availableProcessors() возвращает 21 ядро ноды. Лечится флагами -Dio.netty.allocator.numDirectArenas=2 -XX:MaxDirectMemorySize=256m. Оформил отдельным action item — вопрос с memory alert закрыт

Но пока копался в поде через kubectl exec, краем глаза заметил странное в du. Вот как выглядит состояние прода прямо сейчас (фикс ещё на ревью, баг живёт):

$ kubectl -n pl-seller-storage-service exec seller-storage-service-...-fpznf -c app -- bash$ du -sh /tmp/poifiles1.9G    /tmp/poifiles$ ls /tmp/poifiles | wc -l10046$ ls -lh /tmp/poifiles | head -7total 1.9G-rw------- 1 10001 root  564K May 26 13:48 poi-sxssf-sheet10003417958849786613.xml-rw------- 1 10001 root  607K May 19 11:05 poi-sxssf-sheet10004469281468030521.xml-rw------- 1 10001 root  248K May 26 18:34 poi-sxssf-sheet10004610036281220997.xml-rw------- 1 10001 root  142K May 26 20:45 poi-sxssf-sheet10006089183010237705.xml-rw------- 1 10001 root     0 May 21 16:07 poi-sxssf-sheet10006300192782898050.xml-rw------- 1 10001 root     0 May 21 05:17 poi-sxssf-sheet10009984612842940696.xml$ df -h /tmpFilesystem      Size  Used Avail Use% Mounted on/dev/vda2       367G  276G   76G  79% /tmp

Почти 2 GiB временных файлов на одном поде, на втором — 10103 файла, тоже 1.9 GiB. Для масштаба: RSS пода в этот момент 1.7 GiB, то есть на диске под держит даже больше, чем занимает в памяти. Файлы датированы от 19 мая (дата старта uptime), часть нулевого размера — следы незакрытых workbook’ов после исключений

Я понаблюдал ещё час: счётчик растёт по мере работы сервиса. Каждый раз, когда пользователь загружает Excel, POI создаёт новые временные файлы и оставляет их на диске. По данным с момента первого разбора это даёт около 800 файлов в сутки на под, или полгигабайта в сутки на ноду от одного нашего сервиса

И последняя строчка вывода df -h /tmp показывает, что диск ноды уже на 79% (76 GiB свободно из 367 GiB). На той же ноде живут чужие сервисы, и часть «работы» по заполнению диска уже на нас. Тут P3 на сервис превращается в потенциальный P1 на инфраструктуру: если на ноде живут ещё десять сервисов и пара из них тоже «протекает», диск кончается за дни и кладёт всех соседей

Почему SXSSFWorkbook.close() не удаляет временные файлы

SXSSFWorkbook это streaming-вариант POI для записи XLSX. Идея простая: вместо того чтобы держать весь документ в памяти, библиотека сохраняет последние N строк в RAM, а более старые сериализует в файлы poi-sxssf-sheet*.xml в java.io.tmpdir. Это даёт возможность писать XLSX на сотни тысяч строк без OOM

Подвох в том, что SXSSFWorkbook реализует AutoCloseable. То есть выглядит, что try-with-resources сделает всё сам, и временные файлы тоже подчистятся. На практике нет

В Javadoc Apache POI это сказано прямо:

dispose() — Dispose of temporary files backing this workbook on disk. Calling this method will render the workbook unusable

close() корректно закрывает базовый workbook, дописывает ZIP-стрим, отдаёт ресурсы. А вот удаление временных sheet-файлов с диска это отдельная операция, dispose(). В POI 5.x внутри close() dispose() вызывается только в определённой ветке: если запись прошла без исключений. А если посреди записи что-то упало (например, IOException на OutputStream), temps остаются. На практике именно это и копится в проде

Наш старый код выглядел как образец try-with-resources:

try (InputStream in = ...;     XSSFWorkbook template = new XSSFWorkbook(Objects.requireNonNull(in));     SXSSFWorkbook wb = new SXSSFWorkbook(template, ROW_ACCESS_WINDOW_SIZE)) {    wb.setCompressTempFiles(true);    // ... запись XLSX ...    wb.write(os);    os.flush();} catch (IOException e) {    log.error("XLSX write failed: {}", e.getMessage(), e);    throw new ServiceException(FILE_GENERATION_FAILED, "xlsx");}

Фикс

dispose() нужно вызывать явно, в finally, и до того, как закроется обёрнутый XSSFWorkbook-template. Если template закроется первым, dispose() может бросить IllegalStateException, потому что внутри он лезет в template за списком sheet’ов. Поэтому я вытащил SXSSFWorkbook из try-with-resources в обычное объявление и обернул в свой try/finally

@Override@SuppressWarnings("PMD.CloseResource")public <T> void write(List<T> records, OutputStream os, Class<T> schemaClass) {    var xlsxProfile = xlsxProfileResolver.resolve(schemaClass);    try (InputStream in = Thread.currentThread().getContextClassLoader()             .getResourceAsStream(xlsxProfile.templatePath());         XSSFWorkbook template = new XSSFWorkbook(Objects.requireNonNull(in))) {        SXSSFWorkbook wb = new SXSSFWorkbook(template, ROW_ACCESS_WINDOW_SIZE);        try {            wb.setCompressTempFiles(true);            writeWorkbook(wb, records, schemaClass, xlsxProfile, os);        } finally {            disposeQuietly(wb);        }    } catch (IOException e) {        log.error("XLSX write failed: {}", e.getMessage(), e);        throw new ServiceException(FILE_GENERATION_FAILED, "xlsx");    }}private static void disposeQuietly(SXSSFWorkbook wb) {    try {        wb.dispose();    } catch (Exception e) {        log.warn("SXSSFWorkbook dispose failed", e);    }    try {        wb.close();    } catch (IOException e) {        log.warn("SXSSFWorkbook close failed", e);    }}

dispose() идёт первым: он удаляет sheet-temps. close() потом закрывает zip-output. Оба завёрнуты в try/catch с log.warn — если из write() уже летит ServiceException, не хочется маскировать его cleanup-ошибкой

Тест, который ловит регресс

Apache POI даёт удобный хук: TempFile.setTempFileCreationStrategy(...). Через него можно подменить директорию, куда POI создаёт временные файлы. В тесте это позволяет показать на @TempDir и проверить, что после write() там не осталось ничего с префиксом poi-sxssf-sheet

class XlsxStreamingFileServiceTest extends BaseTest {    private static final String POI_SHEET_PREFIX = "poi-sxssf-sheet";    @Autowired    private XlsxStreamingFileService xlsxStreamingFileService;    @AfterEach    void restorePoiTempStrategy() {        TempFile.setTempFileCreationStrategy(            new DefaultTempFileCreationStrategy(new File(System.getProperty("java.io.tmpdir")))        );    }    @Test    void writeShouldDisposePoiTempFilesAfterSuccess(@TempDir Path poiTempDir) throws IOException {        TempFile.setTempFileCreationStrategy(new DefaultTempFileCreationStrategy(poiTempDir.toFile()));        var records = List.of(/* ... */);        xlsxStreamingFileService.write(records, new ByteArrayOutputStream(), MySchemaDto.class);        assertNoPoiSheetFilesLeft(poiTempDir);    }    @Test    void writeShouldDisposePoiTempFilesEvenIfOutputStreamFails(@TempDir Path poiTempDir) throws IOException {        TempFile.setTempFileCreationStrategy(new DefaultTempFileCreationStrategy(poiTempDir.toFile()));        var records = List.of(/* ... */);        try (OutputStream failing = new OutputStream() {            @Override public void write(int b) throws IOException { throw new IOException("boom"); }        }) {            assertThatThrownBy(() -> xlsxStreamingFileService.write(records, failing, MySchemaDto.class))                .isInstanceOf(ServiceException.class);        }        assertNoPoiSheetFilesLeft(poiTempDir);    }    private static void assertNoPoiSheetFilesLeft(Path poiTempDir) throws IOException {        try (Stream<Path> walk = Files.walk(poiTempDir)) {            var leftover = walk                .filter(Files::isRegularFile)                .filter(p -> p.getFileName().toString().startsWith(POI_SHEET_PREFIX))                .toList();            assertThat(leftover)                .as("POI streaming temp files must be deleted via SXSSFWorkbook.dispose() after write")                .isEmpty();        }    }}

Второй тест я считаю важнее первого. Он покрывает кейс, когда OutputStream.write(...) бросает IOException посреди записи. Без dispose() в finally именно этот сценарий и оставлял файлы. На happy path старый код тоже проходил без ошибок, поэтому проблема пряталась именно в exception-ветке

Защита от регрессии через ArchUnit

Тест выше проверяет один конкретный flow. Но SXSSFWorkbook— публичный класс POI, и завтра кто-то использует его в другом месте и снова получит утечку. Это случай для ArchUnit: правило архитектурного уровня закрывает класс проблем целиком, а не один эндпоинт

@ArchTeststatic final ArchRule SXSSF_WORKBOOK_USAGE_LIMITED_TO_FILE_PACKAGE =    noClasses()        .that().resideOutsideOfPackage("..file..")        .should().dependOnClassesThat()        .haveFullyQualifiedName("org.apache.poi.xssf.streaming.SXSSFWorkbook")        .because("SXSSFWorkbook создаёт POI tmp-файлы в системном tmp-dir и требует явного dispose() "            + "для их удаления; использовать только через сервис в пакете ..file..");

Перевод на русский: никакой класс вне пакета ..file.. не имеет права зависеть от SXSSFWorkbook. Если завтра кто-то напишет new SXSSFWorkbook(...) в другом месте, билд упадёт с понятным сообщением. Проблема решится на ревью за пять минут, а не через шесть суток uptime на проде

Логика общая: один раз нашёл нетривиальные грабли в библиотеке, закрепи запрет на уровне архитектуры. Тест на конкретный flow и ArchUnit-правило — два разных уровня защиты, и они дополняют друг друга, а не дублируют

Что бы я сделал по-другому

• Про устройство /tmp в Kubernetes я узнал, только когда полез копать утечку. По умолчанию emptyDir —-это диск ноды, а tmpfs нужно включать явно через medium: Memory. Стоит закладывать это в Pod spec осознанно, не оставлять «как-нибудь сложится»

• Алерт на свободное место на диске ноды у нас был, но триггерился на 90%. Для роста 250 MiB в сутки это даёт мало времени на реакцию — стоит понизить порог

• Полезно иметь отдельную метрику по размеру emptyDir каждого пода (cAdvisor умеет). Тогда утечка ловится отдельно от RSS, и сразу видно, на каком сервисе она копится, а не «диск ноды растёт, ищите виноватого»

Итоги

• SXSSFWorkbook.close() в Apache POI не удаляет временные sheet-файлы. Это поведение по доке, а не баг библиотеки. Нужен явный dispose() в finally

• try-with-resources не гарантирует cleanup, если у класса в цепочке «закрытие» и «освобождение ресурсов» — разные операции

• В Kubernetes /tmp по умолчанию лежит на диске ноды. Утечка диска одного пода ставит под угрозу всех соседей по ноде. Это сильно меняет приоритет таких багов

• Если нашёл нетривиальный гвоздь в библиотеке, имеет смысл закрепить запрет на уровне ArchUnit. Это сильнее, чем тест на конкретный flow