Why should I use concurrent characteristic in parallel stream with collect?

by

These two collectors operate in a fundamentally different way.

First, the Stream framework will split the workload into independent chunks that can be processed in parallel (that’s why you don’t need a special collection as the source, synchronizedList is unnecessary).

With a non-concurrent collector, each chunk will be processed by creating a local container (here, a Map) using the Collector’s supplier and accumulating it into the local container (putting entries). These partial results have to be merged, i.e. one map has been put into the other, to get a final result.

A concurrent collector supports accumulating concurrently, so only one ConcurrentMap will be created and all threads accumulate into that map at the same time. So after completion, no merging step is required, as there is only one map.

So both collectors are thread-safe, but might exhibit entirely different performance characteristics, depending on the task. If the Stream’s workload before collecting the result is heavy, the differences might be negligible. If like in your example, there is no relevant work before the collect operation, the outcome heavily depends on how often mappings have to be merged, i.e the same key occurs, and how the actual target ConcurrentMap deals with contention in the concurrent case.

If you mostly have distinct keys, the merging step of a non-concurrent collector can be as expensive as the previous putting, destroying any benefit of the parallel processing. But if you have lots of duplicate keys, requiring merging of the values, the contention on the same key may degrade the concurrent collector’s performance.

So there’s no simple “which is better” answer (well, if there was such an answer, why bother adding the other variant). It depends on your actual operation. You can use the expected scenario as a starting point for selecting one but should measure with the real-life data then. Since both are equivalent, you can change your choice at any time.

More Related Contents:

  1. Custom thread pool in Java 8 parallel stream
  2. Parallel streams, collectors and thread safety
  3. Nested Java 8 parallel forEach loop perform poor. Is this behavior expected?
  4. How can I throw CHECKED exceptions from inside Java 8 streams?
  5. Java 8 Iterable.forEach() vs foreach loop
  6. Collect successive pairs from a stream
  7. Word frequency count Java 8
  8. Java 8: performance of Streams vs Collections
  9. How do synchronized static methods work in Java and can I use it for loading Hibernate entities?
  10. Why are Java Streams once-off?
  11. Reverse a comparator in Java 8
  12. Is this a bug in Files.lines(), or am I misunderstanding something about parallel streams?
  13. Can a Collector’s combiner function ever be used on sequential streams?
  14. Java 8: How do I work with exception throwing methods in streams?
  15. Why does Iterable not provide stream() and parallelStream() methods?
  16. Instruction reordering & happens-before relationship [duplicate]
  17. Java Streams: How to do an efficient “distinct and sort”?
  18. stream on JPA lazy list
  19. How does combiner in Stream.collect method work in java 8?
  20. Java8: HashMap to HashMap using Stream / Map-Reduce / Collector
  21. Merging two Map with Java 8 Stream API
  22. How to compare two Streams in Java 8
  23. Nested lists with streams in Java8
  24. Why does Collectors.toMap report value instead of key on Duplicate Key error?
  25. Handling Exceptions for ThreadPoolExecutor
  26. Why does this stream return no element?
  27. In Java 8 how do I transform a Map to another Map using a lambda?
  28. Is it possible to get next element in the Stream?
  29. Java 8 Stream and operation on arrays
  30. What is the difference between intermediate and terminal operations?

Leave a Comment