Прям целый набор взаимоисключающих параграфов. Не хочется активности ГЦ тогда не тащи данные в JVM просто спроси сразу число в том месте где данные хранятся те. БД.

Никакого логического обоснования необходимости буферизации нет для count (именно с точки зрения count функции а не подтягивания данных в стрим).

Если прям хочется скэкономить не тащи объект целиком, а лишь маркер его присутствия в heap.
boolean isCacheServeyIdExistsByIdentity();
Вернутый Boolean можно подсчитать и booleans и так закэшированы в jvm.

Даже больше если stream is sized то ответ count вернут сразу без даже какого либо каунтинга
В примере выше все портит .filter(x -> x.getSurveyId() == surveyId превщает в unknown size stream, а это тащит .map(this::getCachedByIdentity) в heap. (вообще getCachedByIdentity как то стремно выглядет ведь map функция подразумевается конвертер данных т.е. даные и так в памяти и мы просто с ними оперируем а тут выглядет так что поддтягиваются данные из кэша, что и side effect может иметь и еще и блокинг при этом в стриме получить)

Если нет возможности считать там где лежат данные и если повезло с surveyId и значения за диапазон небольшой не выходят, то пробуй не тащить целиком объект в head а тащи только getCachedSurveryIdByIdenity()) и проставь -XX:AutoBoxCacheMax ну например до 100тыс (если эти значения за 100тыс не выходят).


больше похоже подправление кода и постоянный перезапуск, и одна из кривых версий кода хранила ссылки и получили OOM или RAM не осталось на машинке свободной прям в этот раз. но эта версия тут же была исправлена и теперь не вспомнить какая из версий кидала OOM. OOM можно получить если бомбить память быстрее чем GC успевает освобождать ее. решается круткой edem для краковременных объектов чтобы не успевали как old помечаться объекты (у меня на 60мб не успевает чистить эдем и все в old попадает но тут объем маленький GC и так с лихвой успевает 60Мб проверять)