Может кто то подсказать такой вопрос



например есть такой метод- что он делает - идет в кеш за мапой - берет коллекцию ключей-по этим ключам в кеше находит нужные объекты ,фильтрует и считает

вопрос простой на этапе вот этом


мы получаем из кэша объекты - будут ли они все в памяти болтаться или же нет?

и если же будут целиком объекты то если мы возьмем их id только

например вот так

что именно тебе не понятно в вопросе?

смотри стрим начинается с получения из мапы кей сета - мы получаем множество UUID
по этим UUID мы достаем из кеша Объекты

далее мы преобразуем стрим из этих объектов в стрим идентификаторов


и далее фильтруем по неким условиям и считаем сумму элеметов в стриме

ворпос в том будут ли в памяти все время работы этого метода все Объекты которые мы выбрали из кеша?

проблема в том что не хочется в память тащить такого количество объектов ,во первых они достаточно объемные и их очень много ,а хип не резиновый
поэтому и возник вопрос - если все время работы метода все объекты будут в хипе - то такое мне не подходит ,если же элемент после второго map будет кандидат на удаление - то это уже более интересно .Но я подозреваю что пока метод целиком не отработает на все этим элементы будут ссылки из стрима и хип раздуется ровно на количество этих элеентов - что мне конечно же не подходит

[quot mayton#22420011]Вот по 17-шке пишут.

https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/stream/package-summary.html

The key abstraction introduced in this package is stream. The classes Stream, IntStream, LongStream, and DoubleStream are streams over objects and the primitive int, long, and double types. Streams differ from collections in several ways:

No storage. A stream is not a data structure that stores elements; instead, it conveys elements from a source such as a data structure, an array, a generator function, or an I/O channel, through a pipeline of computational operations.
Functional in nature. An operation on a stream produces a result, but does not modify its source. For example, filtering a Stream obtained from a collection produces a new Stream without the filtered elements, rather than removing elements from the source collection.
Laziness-seeking. Many stream operations, such as filtering, mapping, or duplicate removal, can be implemented lazily, exposing opportunities for optimization. For example, "find the first String with three consecutive vowels" need not examine all the input strings. Stream operations are divided into intermediate (Stream-producing) operations and terminal (value- or side-effect-producing) operations. Intermediate operations are always lazy.
Possibly unbounded. While collections have a finite size, streams need not. Short-circuiting operations such as limit(n) or findFirst() can allow computations on infinite streams to complete in finite time.
Consumable. The elements of a stream are only visited once during the life of a stream. Like an Iterator, a new stream must be generated to revisit the same elements of the source.


все равно не очень понятно если я из кеша выбираю объекты - хранятся ли они где то или нет?
тоесть первой операцией у нас идет получние ключей из мапы- тут все нормально - мапа уже в памяти - к ней ворпосов нет
вопрос в том что я получаю далее стрим объектов - и преобразую его в стрим идентификаторов - и мой вопрос простой - что будет с объектами - которые я достал из кэша - будут ли они храниться в хипе пока метод не отработал либо же сразу после преобразования стрима объектов в стрим идентификаторов - объекты будут помечены на удаление

проверять я конечно проверю- но может быть кто то знает и сталкивался с этим

кеш в данном случае это хезель каст

конечно тяжело-это же динамический процесс - его нужно отловить- тоесть когда система будет нагружена достаточно
если делать замеры на тестовой среде - нужно просить тестировщиков - а это геморой- проше на форуме спрсоить - может кто то знает как оно там работает под капотом

но фактически уже сейчс понятно что коллекция объектов будет загружена в хип из кэша ,далее пока не применится терминальная операция стрим не понменят своего состояния
- тоесть фактически я думаю что пока метод не отрбаотает на все эти объкеты будет ссылка и гц не сможет их удалить до оконочания метода- это собственно все ,что мне нужно знать было

если есть кто не согласен с этим - прошу к дискуссии

в данном случае хезель является источником правды и можно тоже самое сделать средствами хезелькаста и на стороне хезелькаста не затаскивая в хип лишние данные.

Но я повторюсь - меня интересует как будет огранизована работа памяти в данной цепочке

колекция UUID -по ней получаем из кэша- стрим объектов - мапим в стрим других объектов( например в лонги) фильтруем и считаем количество элементов

вот на каждом этом этапе интересует поведение памяти

в целом ты прав,но забываешь о том ,что объекты изнчально находятся в кеще(в данном случае это хезель каст) и чтобы стрим начал с ними работать я думаю они будут целиком загружены в хип

хезель каст в данном случае работает как отдельный процесс в докер контейнере

все верно есть задача - а я выбираю как лучше сделать,объекты находятся в кеше( хезель каст) -
нужно взять все имеющиеся там объекты взять у них атрибут по нему отфильтровать и посчить сумму объектов

чтобы это сделать можно пойти несколькими путями
1.достать из кеша все эти объекты и сделать то о чем я писал в начале топика- но меня смушает тот факт что я буду тянуть в хип по сути не нужные мне объекты чтобы их просто посчитать
2.можно сделать это средствами хезель каста - тоже не выглядит как суперпроизводительное решение

да все верно это преждевременная оптимизация- но и собственно интерес к тому,как это будет выглять в памяти

хорошо вот средствами хезелькаста




я правильно понимаю что вот эта строчка
все таки вытащит в хип джава процесса эту коллекцию - пусть и уже отфильтрованную ,либо же в хип попадет только size()

ну я с тобой тут согласен - но мы все таки явно не выяснили как под капотом ведет себя стрим- может ( конечно нет,но всеже)
тут ворпос тоже ребром - кеш так же будет процессиить эту мапу,и так же тратить ресурсы свои на это и тут вопрос где будет оптимальней
так же мы в случае с хезель часть работы возложим на кеш часть вытащим в джава процесс - тоесть не все так однозначно как ты говоришь