powered by simpleCommunicator - 2.0.29     © 2024 Programmizd 02
Map
Форумы / Java [игнор отключен] [закрыт для гостей] / Stream и память
25 сообщений из 132, страница 4 из 6
Stream и память
    #40126830
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
faustgreen
adminDontSleep
так что базиль пока не убедительно - я лично сомневаюсь что до заверщения работы стрим будет терять ссылки на эти объекты,тем самым давая дорогу ГЦ- конечно лучше всего провести какой то наглядый тест с профилировщиком

Вот тест:
1) Этот код будет работать бесконечно:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
package test;

import java.util.stream.Stream;

public class Test {
	public static void main(String[] args) {
		Stream<Integer> infiniteStream = Stream.iterate(0, i -> i);

		infiniteStream
		  .map(e->String.valueOf(e))
		  .forEach(System.out::println);
		
	}
}




2) Этот код выдаст Exception in thread "main" java.lang.OutOfMemoryError: Java heap space:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
package test;

import java.util.stream.Stream;

public class Test {
	public static void main(String[] args) {
		Stream<Integer> infiniteStream = Stream.iterate(0, i -> i);

		infiniteStream
		  .map(e->String.valueOf(e))
                  .sorted()
		  .forEach(System.out::println);
		
	}
}



отличный пример мембер. ТС'у учится "меньше слов и больше кода"
В общем случае стрим это конвейерные операции. Память выделяется для самой коллекции проходящей через стрим или ВООБЩЕ не выделяется при обработке из сети.
...
Рейтинг: 0 / 0
Stream и память
    #40126837
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PetroNotC Sharp
....или ВООБЩЕ не выделяется при обработке из сети.

это как?
...
Рейтинг: 0 / 0
Stream и память
    #40126839
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Kudryavtsev,
а)
- создание коллекции для стрима - выделяем память ДЛЯ КОЛЛЕКЦИИ
- обработка стримом без выделения памяти
б)
- есть канал из сети = память не выделяется
- обработка стримом без выделения памяти
?
...
Рейтинг: 0 / 0
Stream и память
    #40126842
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Kudryavtsev,
аналогия - SAX и DOM парсер XML
...
Рейтинг: 0 / 0
Stream и память
    #40126844
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PetroNotC Sharp

...
б)
- есть канал из сети = память не выделяется
...

Что же это за сеть такая (на IBM PC и их клонах), что не требует локальной копии обрабатываемого объекта?

p.s. AFAIK конечно есть сетевые карты с такой возможностью (Infiniband или сильно продвинутые 10 G), но вот их поддержки Java'ой - я лично не помню
...
Рейтинг: 0 / 0
Stream и память
    #40126846
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Kudryavtsev,
вы наверно говорите о частностях.
Есть коллекция из млн объектов. А не объект один.
Именно это автора пугает.
Конечно один объект по приходу создается.
Суть что миллион не надо.
И вообще, стрим не для "не требует локальной копии обрабатываемого объекта"
Он для потока информации. Например видео поток.
Ключевое слово поток.
...
Рейтинг: 0 / 0
Stream и память
    #40126849
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Kudryavtsev,
многие пишут что for на 30 проц быстрее стрима.
Так что вопрос в том что тут экономит автор))
Он не борется с задачей. А изучает стримы за наш счет)
...
Рейтинг: 0 / 0
Stream и память
    #40126880
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PetroNotC Sharp

многие пишут что for на 30 проц быстрее стрима.

"не верю" ( C )
то, что знаю (профилировал) я:
1. при правильном использовании с ListArray стрим совершенно аналогичен for
2. при НЕправильном использовании с ListArray (что очень легко) стрим значительно (раза в 3-4, а может и больше) медленнее for'а.

При п.2., не срабатывает Jit оптимизация проверки выхода за пределы массива (при использовании с ListArray).
...
Рейтинг: 0 / 0
Stream и память
    #40126891
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Kudryavtsev,
Там особый юзкейс был. Посмотрю позже.
...
Рейтинг: 0 / 0
Stream и память
    #40126912
adminDontSleep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
faustgreen
Посмотри еще доки официальные, там есть, например, вот это:

reduce

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
T reduce(T identity, BinaryOperator<T> accumulator)

Performs a reduction on the elements of this stream, using the provided identity value
 and an associative accumulation function, and returns the reduced value. 
This is equivalent to:

T result = identity;
for (T element : this stream)
   result = accumulator.apply(result, element)
return result;



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

копни глубже про стримы и их взамодействие с памятью -вот эта реализация обратных пул итераций например
...
Рейтинг: 0 / 0
Stream и память
    #40126913
adminDontSleep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Basil A. Sidorov

P.S.
Я в курсе, что конкретные промежуточные операции (например - сортировка) будут "удерживать" весь сортируемый набор, но другим промежуточным операциям (например - счётчик) это совсем не требуется.

теперь ты гораздо ближе к истине ,но count() это терминальная операция - она возвращает число а не стрим,как промежуточные - разберись с этим и станет более понянет мой вопрос изначальный
...
Рейтинг: 0 / 0
Stream и память
    #40126915
adminDontSleep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Roman Osipov
В данном случае для подсчета оптимально использовать

https://docs.hazelcast.org/docs/4.0/javadoc/com/hazelcast/map/IMap.html#aggregate-com.hazelcast.aggregation.Aggregator-com.hazelcast.query.Predicate-

и в heap точно объекты не потянет, и скорость работы в десятки/сотни раз быстрее будет.

согласен
...
Рейтинг: 0 / 0
Stream и память
    #40126924
adminDontSleep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
вообщем провел тест

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
       LongStream intStream = LongStream.range(0, Long.MAX_VALUE);

        var sum = intStream
                .boxed()
                .map(Employee::new)
                .filter(x -> x.getId() % 2 == 0)
                .count();

        System.out.println(sum);



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

там ожидаемо стрим работал более похоже на цикл

это forEach()
...
Рейтинг: 0 / 0
Stream и память
    #40126925
adminDontSleep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
а это count()
...
Рейтинг: 0 / 0
Stream и память
    #40126926
adminDontSleep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
faustgreen
В первом примере все элементы бесконечного стрима "пролетают насквозь" нашу цепочку методов стрима. Создается бесконечное количество строк "0", но они каждую итерацию присваиваются одной и той же переменной.

Во втором случае создается бесконечное количество строк "0", которые накапливаются в методе sorted() и не проходят дальше (накапливаются в памяти).

в своих примерах ты по незнанию работы стримов либо лукавишь ,либо просто ошибаешься- вверху две картинки,которые разрушают твою теорию - о поэлементной обработке
- она поэлемента если у тебя териманалка поэлемента
- если терминалка подразумевают некую буферизацию - ты проиграл
поэтому твои тесты и не корректны и не отражают реальной картины происходящего
...
Рейтинг: 0 / 0
Stream и память
    #40126928
adminDontSleep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
класс Employee

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
public class Employee {

    private Long id;

    public Employee(Long id) {
        this.id = id;

    }

    public Long getId() {
        return id;
    }
}



тесты проводились на этом коде

терминальная оперцая forEach

Код: java
1.
2.
3.
4.
5.
6.
7.
       LongStream intStream = LongStream.range(0, Long.MAX_VALUE);

         intStream
                .boxed()
                .map(Employee::new)
                .filter(x -> x.getId() % 2 == 0)
                .forEach(System.out::println);



терминальная операция count()

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
      LongStream intStream = LongStream.range(0, Long.MAX_VALUE);

        var sum = intStream
                .boxed()
                .map(Employee::new)
                .filter(x -> x.getId() % 2 == 0)
                .count();

        System.out.println(sum);
...
Рейтинг: 0 / 0
Stream и память
    #40126933
adminDontSleep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
PetroNotC Sharp

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

ну и да я пытаюсь везде экономить и бороться за максимальную производительность
у меня например instaceOf ревью не пройдет
...
Рейтинг: 0 / 0
Stream и память
    #40126943
SpringMan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
adminDontSleep,

Без обид, но ты меряешь какую-то фигню и делаешь такие же выводы. На обоих графиках used heap size падает до нуля - это значит, что нет там никакой буферизации. Память растет до гига, потому что у тебя идет генерация кучи Employee, и очищаются они тогда, когда jvm посчитает, что ей нужно свободное место. Поставь -Xmx на 50 мб и никакого гига никто тратить не будет.

В твоем первоначальном примере, есть или нет утечки зависят только от двух мест:
1) Какая имплементация у surveyResultIdentitiesPersistDelayedMap(), если тут стандартные джавовые HashMap/TreeMap и т.д., то никаких буферизаций не будет (о чем тебе толдычат уже 4ую страницу). Если что-то другое, то надо смотреть какой стрим они возвращают (опять же обычно библиотечный код пишут не совсем идиоты, и вряд ли они будут что-то буферизировать без надобности)
2) Что находится в this::getCachedByIdentity, если этот кэш в хипе, то само сабой он будет расти. Но к стримам это имеет весьма далекое отношение

На чьей стороне лучше делать, это скорее вопрос к hezelcast-у, а не каким-то утечкам на стримах
...
Рейтинг: 0 / 0
Stream и память
    #40126946
faustgreen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
adminDontSleep

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

Что такое обратные пул итерации? Сбрось ссылку, если есть под рукой.
...
Рейтинг: 0 / 0
Stream и память
    #40126950
faustgreen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
adminDontSleep
в своих примерах ты по незнанию работы стримов либо лукавишь ,либо просто ошибаешься- вверху две картинки,которые разрушают твою теорию - о поэлементной обработке
- она поэлемента если у тебя териманалка поэлемента
- если терминалка подразумевают некую буферизацию - ты проиграл
поэтому твои тесты и не корректны и не отражают реальной картины происходящего


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

Еще раз напишу, я стримы глубоко не знаю, просто когда с ними возился, и сложилось такое виденье. Где то могу ошибаться.
...
Рейтинг: 0 / 0
Stream и память
    #40126952
adminDontSleep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SpringMan
adminDontSleep,

Без обид, но ты меряешь какую-то фигню и делаешь такие же выводы. На обоих графиках used heap size падает до нуля - это значит, что нет там никакой буферизации. Память растет до гига, потому что у тебя идет генерация кучи Employee, и очищаются они тогда, когда jvm посчитает, что ей нужно свободное место. Поставь -Xmx на 50 мб и никакого гига никто тратить не будет.

В твоем первоначальном примере, есть или нет утечки зависят только от двух мест:
1) Какая имплементация у surveyResultIdentitiesPersistDelayedMap(), если тут стандартные джавовые HashMap/TreeMap и т.д., то никаких буферизаций не будет (о чем тебе толдычат уже 4ую страницу). Если что-то другое, то надо смотреть какой стрим они возвращают (опять же обычно библиотечный код пишут не совсем идиоты, и вряд ли они будут что-то буферизировать без надобности)
2) Что находится в this::getCachedByIdentity, если этот кэш в хипе, то само сабой он будет расти. Но к стримам это имеет весьма далекое отношение

На чьей стороне лучше делать, это скорее вопрос к hezelcast-у, а не каким-то утечкам на стримах

да какие обиды если ты сделал выводы не удосужившись почитать последние посты- я привел два графика с одним и тем же стримом но разными терминальными операциями - чтобы доказать местным снобам- что память жвм имеет немного иное представление - чем они тут пишут
...
Рейтинг: 0 / 0
Stream и память
    #40126954
adminDontSleep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
faustgreen
adminDontSleep
в своих примерах ты по незнанию работы стримов либо лукавишь ,либо просто ошибаешься- вверху две картинки,которые разрушают твою теорию - о поэлементной обработке
- она поэлемента если у тебя териманалка поэлемента
- если терминалка подразумевают некую буферизацию - ты проиграл
поэтому твои тесты и не корректны и не отражают реальной картины происходящего


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

Еще раз напишу, я стримы глубоко не знаю, просто когда с ними возился, и сложилось такое виденье. Где то могу ошибаться.

ты много где верно говоришь но ошибаешься в одном 0 стримы имеют состояние- тоесть применяя какую то промежуточную операцию ты меняешь состояние стрима ЦЕЛИКОМ!!! а не его элементы

при этом после этого ты уже не можешь вызывать состояние стрима которое было до этой операции
...
Рейтинг: 0 / 0
Stream и память
    #40126955
adminDontSleep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
faustgreen
adminDontSleep

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

Что такое обратные пул итерации? Сбрось ссылку, если есть под рукой.

это основы работы стрима

стрим работает от термианльной операции в отличии от любых циклов
тоесть работа стрима начинается с терминалки и именно поэтому у тебя не забился хип- ты применял терминалку к каждому элементу стрима - потоэтму гц спокойно собирал нулевые ссылки
как я тебе выше показал даже count() показывает абсолютно другое состоняние памяти
...
Рейтинг: 0 / 0
Stream и память
    #40126960
SpringMan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
adminDontSleep

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

К сожалению я прочитал эти посты, и повторю еще раз - и графики и выводы полная фигня. Ты можешь еще раз конкретно написать два предложение: первое - что сказали местные снобы, второе - в чем они не правы. Конкретно какое представление говорят они и какое верное?
У тебя графики за разные интервалы времени, не выставлен xmx, внутри forEach стоит System.out::println - хотя бы из-за этого твои картинки не имеют никакого смысла. После того как ты это исправишь, еще можешь рассказать как эти графики объясняют что-то про буферизацию/утечки/по элементные обработки - вот это будет самое интересное и смешное
...
Рейтинг: 0 / 0
Stream и память
    #40126965
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
adminDontSleep

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

Расскажи как ты себе понимаешь "утечку памяти".
...
Рейтинг: 0 / 0
25 сообщений из 132, страница 4 из 6
Форумы / Java [игнор отключен] [закрыт для гостей] / Stream и память
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]