Ка лучше использовать parallelStream() в Java?

Question

[Sanzhar Zhanibekov]

Хотел бы получить информацию о параллельных стримах. Если смотреть прям под мой кейс, то у меня есть списки в котором хранятся объекты с BigDecimal
Приведу один из примеров

private static BigDecimal findAvg(List<Record> records) {
        return BigDecimal.valueOf(records.stream()
                .map(Record::getWithdrawal)
                .reduce(BigDecimal.ZERO, BigDecimal::add)
                .doubleValue() / records.size());
    }

Или приведу пример с parallelStream()

var records = dayRecords.parallelStream()
                    .filter(r -> r.getDescription().equals(description))
                    .collect(Collectors.toList());

В этом случае бывает программа не может остановиться. Пока не разобрался почему. Цель этого кейса, это приток производительности и потребление памяти с малом количестве.

В общем какие Best Practice есть с parallelStream() и с чем его едят? Какие лучше Collections выбирать для них?

Answer 1

[Dmitry Roo]

Бест-практиз - не использовать паралелСтрим:
https://dzone.com/articles/think-twice-using-java-8

Можно использовать StreamEx.

Answer 2

[mayton2019]

Не все коллекции поддерживают параллелизм стримов.

Какие BestPractices? Запускай анализ производительности под JMH и наблюдай. Не верь в рекламу.

Пример с подсчетом среднего значения в List (кстати какой это List? Какая implementation?) - очень софистичесчкий
и надуманный. Его любят преподаватели. Но в реальной жизни и в продуктовом коде тебе чаще придется вычислять среднее по ResultSet из JDBC или по какому-нибудь толстому JSON документу который льется из микросервиса.

Comments

[Sanzhar Zhanibekov]

кстати какой это List?

final List<Record> dayRecords = new ArrayList<>();

Какая implementation?

@Data
@AllArgsConstructor
public class Record {
    private Date date;
    private String description;
    private BigDecimal withdrawal;
}

очень софистичесчкий
и надуманный

Немного вас не понимаю, хотелось бы побольше услышать информации об этом

по какому-нибудь толстому JSON документу который льется из микросервиса.

В моем кейсе идет так. Есть csv file где 5 млн данных, где я вытаскиваю и конверчю в Record class. Среди 5 млн фильтруются и остаются 2,3 млн. Потом идет обработка и сохраняю в этот класс

@Data
@Builder
public class OutputRecord {
    private Date date;
    private String type;
    private BigDecimal min;
    private BigDecimal max;
    private BigDecimal average;
}

в общем если говорить по показателям

Если программа посчитает что нужно больше скорости, то будет терять в памяти. Но может замедлить скорость, тогда он выиграет в памяти. И все это в диапазоне 16-21 сек и 152-210 MB средняя минимальная память 65 MB. Как вы думаете, это нормальные показатели? Если нет, то хотелось бы услышать возможность оптимизации.

[mayton2019]

Sanzhar Zhanibekov, каким образом эти сущности OutputRecord попали в память? Они были считаны из файла или из базы?

[Sanzhar Zhanibekov]

mayton2019, они генерятся после обработки данных от класса Record

Примерно вот такой вот метод

private List<OutputRecord> fastFindWithdrawlsByDescription(final List<Record> dayRecords) {
        if (dayRecords == null || dayRecords.isEmpty()) return new ArrayList<>();
        List<OutputRecord> outputRecords = new ArrayList<>();
        dayRecords.forEach(record -> {
            List<Record> records = dayRecords.stream()
                    .filter(r -> r.getDescription().equals(record.getDescription()))
                    .toList();

            outputRecords.add(new OutputRecord(
                    records.get(0).getDate(),
                    records.get(0).getDescription(),
                    findMin(records),
                    findMax(records),
                    findAvg(records)));
        });
        return outputRecords;
    }

[mayton2019]

Sanzhar Zhanibekov, а dayRecords откуда взялись?

[Sanzhar Zhanibekov]

mayton2019, В общем его задача собирать Record за день
GitHub

[mayton2019]

Я почему спрашиваю. Вы передали List. Уже потеряли время на генерации листа и не сэкономили на стриминге. Провал по сути. Здесь конешно можно обсуждать стримы но вы уже проиграли.

Суммарное время работы вашей функции это сумма времени загрузки листа из базы и генерации outputrecords. Причем outputrecords будут занимать 1% от общего времени.

А если мы работаем с БД то запросами ROLLUP/Cube мы можем просто собрать эту метрику среднего прямо в БД и отдать ответом вместе с основным телом.

Это по сути мой ответ на вопрос по поводу софистического и надуманного примера.

Streams с параллелизмом практически мало вам дают пользы. Просто другие затраты съедают в тысячи и миллионы раз больше времени. Вот такое мое рассуждение по этому вопросу.

[Sanzhar Zhanibekov]

Я вас понял, но тут получается я получаю данные с csv и в принципе загрузка всех данных идет за пол секунды, не измерял. А вот цикл и обработка данных через foreach has next идет долго.

Суммарное время работы вашей функции это сумма времени загрузки листа из базы и генерации outputrecords.

Хотелось бы узнать решение этой проблемы. Я вот думаю можно было бы обойтись объектами и перейти на Map, HashMap, в данном случае смогу ли я избежать ухудшения производительности?

[Sanzhar Zhanibekov]

mayton2019,

А если мы работаем с БД то запросами ROLLUP/Cube мы можем просто собрать эту метрику среднего прямо в БД и отдать ответом вместе с основным телом.

Я бы с радостью получить такой опыт)) но увы у меня это тестовое задание где было определено работы с csv.

не сэкономили на стриминге

Если не сложно, а как сделать правильно? Вообще новичок в стримах и парарелях

[mayton2019]

Начни читать отсюда https://docs.oracle.com/en/java/javase/17/docs/api...
В стандартной документации достаточно полно изложены принципы и цели использования стримов. Про параллелизм пока забудь. Не надо это тебе. Обрати внимание как работают collect/reduce. И попробуй понять в чем разница между ними.

[Sanzhar Zhanibekov]

mayton2019, Хорошо! Обязательно все прочитаю! Сделал тесты на 5 млн данных. Вышли интересные показатели. создание
нового объекта - 20 сек
использование HashMap - 7 сек

С радостью переделал метод для обработки и записи. Выходит 45-55 сек, хотя с классами вышло 15-23 сек.