1Z0-829 Working with Streams and Lambda Expressions Practice Question
A developer is processing a stream of strings and needs to create a map where the key is the string length and the value is a list of strings of that length. They write the following code: Map<Integer, List<String>> map = strings.stream() .collect(Collectors.groupingBy(String::length)); The code works correctly in a sequential stream, but when they switch to parallelStream, they notice that sometimes the map contains fewer keys than expected. They suspect that the issue is related to the default map implementation used by groupingBy. What is the most likely cause and the correct fix?
⚠ Common exam trap
Many exam-takers assume providing a concurrent map factory to `groupingBy` fixes the issue, but they overlook that the collector's internal merge logic must also be concurrent, which only `groupingByConcurrent` provides.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Replace groupingBy with groupingByConcurrent.
`Collectors.groupingByConcurrent` is designed for concurrent reduction and produces a `ConcurrentMap`, which safely handles parallel stream processing without losing keys. The default `groupingBy` uses a non-concurrent `HashMap` that can lose entries due to race conditions when multiple threads merge partial results.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Provide a custom thread-safe map factory to groupingBy, e.g., ConcurrentHashMap::new.
Why it's wrong here
While the three-argument overload of groupingBy does accept a map supplier, simply providing a ConcurrentHashMap factory does not make the collector thread-safe because the downstream collector used internally still performs non-concurrent merge operations. The correct approach is to use groupingByConcurrent which ensures both the map and the reduction are concurrent.
- ✗
Remove parallelStream() and use stream() to avoid concurrency issues.
Why it's wrong here
Removing parallelStream() and using stream() avoids the concurrency issue entirely, but it doesn't solve the underlying problem of how to correctly use parallel streams. If parallelism is desired, groupingByConcurrent is the proper fix.
- ✓
Replace groupingBy with groupingByConcurrent.
Why this is correct
Correct. groupingByConcurrent is designed for concurrent reduction and produces a ConcurrentMap, ensuring thread-safety during parallel stream processing without losing entries.
- ✗
The classifier function (String::length) is not threadsafe.
Why it's wrong here
The classifier function String::length is stateless and thread-safe. The issue is not with the classifier but with how the collector merges partial results in parallel.
Go deeper
Related to this question
About these practice questions
This 1Z0-829 question is part of Courseiva's 513-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 1Z0-829 practice question is part of Courseiva's free Oracle certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 1Z0-829 exam.