Экспорт в Excel клал API-под, хотя файл был на 15 тысяч строк

Команда ограничила экспорт до 50 тысяч строк, помня про проблему с XSSFWorkbook, и решила, что этого достаточно. Но под упал на отчёте в 15 тысяч строк — объём явно не причина.

Причина была в соседнем месте: перед записью в Excel сервис собирал весь отчёт в List, потом прогонял через три стрима — фильтрация, обогащение справочниками, сортировка по трём полям — и только после этого писал в книгу. Каждый промежуточный стрим материализовался в новый список того же размера, справочники подгружались как отдельные Map в памяти на каждый вызов. 15 тысяч строк отчёта на выходе означали сотни тысяч объектов в памяти на входе из-за join'а со справочниками без кэша.

Fix был не про формат файла, а про конвейер: справочники подгружаются один раз и переиспользуются, сортировка и фильтрация уходят в SQL-запрос, а не в Java-стрим после выгрузки всех строк.

Следующий вопрос в таком разборе — почему SXSSFWorkbook (потоковая запись) не решает проблему сам по себе. Правильный ответ: он решает проблему записи в файл, но не решает проблему сборки самого отчёта в памяти до того, как данные попадут в workbook — если сборка уже раздула heap, потоковый writer это не отменит.

Проблема с памятью на экспорте почти никогда в библиотеке записи — она в том, что происходит до вызова write().

Тренажёр: 900+ вопросов и задач, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки