1Z0-829 Working with Streams and Lambda Expressions Practice Test 2 — 15 Questions

Question 1

A method returns an Optional<String>. The developer wants to transform the value inside the Optional to uppercase and print it, but only if present. Which best-practice approach uses streams?

Accepted Answer

opt.stream().map(String::toUpperCase).forEach(System.out::println);. It converts the Optional to a Stream using opt.stream(), then applies map(String::toUpperCase) to transform the value, and finally uses forEach(System.out::println) to print it only if present. This approach leverages the Stream API's lazy evaluation and functional pipeline, which is the best practice for integrating Optional with streams.

Answer

opt.map(String::toUpperCase).ifPresent(System.out::println);

Answer

opt.ifPresent(s -> System.out.println(s.toUpperCase()));

Answer

Stream.of(opt).map(o -> o.get().toUpperCase()).forEach(System.out::println);

Question 2

Which are valid method references in Java 17?

Accepted Answer

String::new. Option A (String::new) is a valid constructor reference in Java 17, matching a functional interface such as Supplier or Function, since constructor references use the ClassName::new syntax. Option B (String::isEmpty) is a valid unbound instance method reference, where the receiver becomes the first functional parameter, e.g., Predicate p = String::isEmpty. Option D (Math::random) is a valid static method reference to Math.random(), compatible with Supplier since it takes no arguments and returns a double. Option E (this::toString) is a valid bound instance method reference, capturing the enclosing instance's toString() and matching a no-arg functional interface like Supplier. Option C (null::equals) is not valid because a bound instance method reference requires a non-null receiver expression; null::equals would compile only in the sense of a null-typed receiver and throws a NullPointerException at runtime, so it is not a valid method reference for practical use.

Answer

null::equals

Question 3

What is the output of the code above?

Accepted Answer

18. The code creates a stream of lists containing numbers 1 through 9, flatMaps to a single stream of integers, filters for numbers divisible by 3 (leaving 3, 6, 9), and reduces them by summing. The sum is 3+6+9=18, making option A correct.

Answer

15

Answer

9

Answer

27

Question 4

A stream pipeline uses groupingBy with a downstream collector to count occurrences. The developer expects a Map<Integer, Long> but gets a compilation error. Which is the correct way to write the collector?

Accepted Answer

Collectors.groupingBy(Function.identity(), Collectors.counting()). Options C and D are both correct ways to produce a Map<Integer, Long> using groupingBy with a downstream collector. Option C uses Collectors.counting(), which is the standard method for counting elements in each group. Option D uses Collectors.summingLong(e -> 1L) to sum a constant 1 for each element, effectively achieving the same count. Options A and B are incorrect: A uses toMap which is not a grouping operation, and B uses Collectors.count() which does not exist (the correct method is counting()).

Answer

Collectors.toMap(Function.identity(), e -> 1L, Long::sum)

Answer

Collectors.groupingBy(Function.identity(), Collectors.count())

Question 5

A developer wants to collect elements from a stream into an immutable List. Which collector should be used?

Accepted Answer

Collectors.toUnmodifiableList(). `Collectors.toUnmodifiableList()` directly returns a collector that accumulates elements into an immutable `List`. This was introduced in Java 10 and guarantees that the resulting list cannot be modified, throwing `UnsupportedOperationException` on any mutation attempt.

Answer

Collectors.toList()

Answer

Collectors.collectingAndThen(Collectors.toList(), Collections::unmodifiableList)

Answer

Collectors.toList().stream().collect(Collectors.toUnmodifiableList())

Question 6

A stream pipeline uses sorted() with a Comparator that calls a thread-unsafe method on each element. The pipeline is parallel. What is the likely outcome?

Accepted Answer

The pipeline may produce incorrect ordering or throw a ConcurrentModificationException.. In a parallel stream pipeline, the `sorted()` operation requires a stable sort that merges results from multiple threads. If the provided `Comparator` calls a thread-unsafe method on each element, concurrent invocations from different threads can cause race conditions, leading to incorrect ordering or a `ConcurrentModificationException` if the method modifies shared state. The pipeline does not automatically fall back to sequential execution for `sorted()` when the comparator is stateful or unsafe.

Answer

The pipeline will throw an exception because the comparator is stateful.

Answer

The pipeline will sort correctly because sorted() is a sequential operation.

Answer

The pipeline will run sequentially because the stream source is not ordered.

Question 7

A developer uses a parallel stream to process a large collection and wants to collect results into a List while preserving encounter order. Which of the following collectors will guarantee order preservation?

Accepted Answer

collect(ArrayList::new, List::add, List::addAll). The custom collector using `ArrayList::new`, `List::add`, and `List::addAll` explicitly specifies an insertion-ordered collection (`ArrayList`) and uses the combiner `List::addAll`, which preserves the encounter order when merging partial results from parallel streams. The `Collectors.toList()` and `Collectors.toUnmodifiableList()` do not guarantee order preservation in parallel streams, as their internal implementations may use non-ordered structures like `HashSet` during accumulation.

Answer

collect(Collectors.toUnmodifiableList())

Answer

collect(Collectors.toList())

Answer

collect(Collectors.toMap(Function.identity(), v->v))

Answer

collect(Collectors.toCollection(TreeSet::new))

Question 8

A stream pipeline filters strings, sorts them, and returns the first match: .filter(s -> s.length() > 3).sorted().findFirst(). This is inefficient because sorted() processes all elements. Which alternative achieves the same result with better performance?

Accepted Answer

.filter(s -> s.length() > 3).min(Comparator.naturalOrder()). `min(Comparator.naturalOrder())` is a terminal operation that finds the smallest element according to natural ordering without sorting the entire stream. It uses a single pass reduction, which is O(n) in time complexity, whereas `sorted().findFirst()` must sort all elements (O(n log n)) before picking the first. This makes `min()` significantly more efficient for this use case.

Answer

.filter(s -> s.length() > 3).sorted().limit(1).findFirst()

Answer

.filter(s -> s.length() > 3).parallel().sorted().findFirst()

Answer

.filter(s -> s.length() > 3).sorted().collect(Collectors.toList()).get(0)

Question 9

Refer to the exhibit. What is the result?

Accepted Answer

IllegalStateException. The code attempts to call `findAny()` on a `Stream` that has already been consumed by a terminal operation (`forEach`). Once a terminal operation is executed on a stream, the stream is closed and cannot be reused. Any subsequent call to a terminal operation on the same stream reference throws `IllegalStateException`. Option C is correct because the second terminal operation violates the single-use contract of streams.

Answer

abc

Answer

NullPointerException

Answer

abcabc

Question 10

Refer to the exhibit. What is the output?

Accepted Answer

12. (12). The exhibit shows a stream reduction with identity value 1 and elements 2, 3, 2. The reduce operation multiplies each element with the accumulated result: 1 * 2 = 2, 2 * 3 = 6, 6 * 2 = 12. The identity is the starting accumulator, not a stream element.

Answer

30

Answer

0

Answer

20

Question 11

A company runs a Java 17 microservice that processes real-time financial transactions. The application receives a large number of transactions per second, each with a timestamp, amount, and type. The current implementation uses a sequential stream to filter and aggregate transactions into a Map. The team observes high latency and CPU spikes during peak loads. They suspect the stream pipeline is inefficient. The pipeline code is: Map stats = transactions.stream() .filter(t -> t.getTimestamp().isAfter(Instant.now().minusSeconds(60))) .collect(Collectors.groupingBy(Transaction::getType, Collectors.summarizingDouble(Transaction::getAmount))); The transactions list is an ArrayList that is frequently modified by other threads (adding new transactions). The system has multiple CPU cores available. Which of the following changes is the MOST effective way to improve performance while maintaining correctness?

Accepted Answer

Use .parallelStream() on a snapshot (new ArrayList<>(transactions)) and keep the same collector.. Using .parallelStream() on a snapshot (new ArrayList<>(transactions)) ensures thread safety by preventing concurrent modification during stream operations, while leveraging multiple cores for parallel processing. The collector remains the same because Collectors.groupingBy and summarizingDouble are thread-safe when used with parallel streams (they use concurrent reduction internally). This approach maintains correctness and improves performance.

Answer

Use .stream().parallel() with a custom thread pool and ensure the stream source is not modified during operation.

Answer

Replace ArrayList with CopyOnWriteArrayList and use .parallelStream() with the same collector.

Answer

Replace the collector with Collectors.groupingByConcurrent() and use .parallelStream() directly on the original list.

Question 12

A financial application processes millions of transactions daily. The original code uses a for loop to aggregate transactions into a Map<Long, TransactionSummary> where the key is account ID. To improve performance, a developer refactors it using parallel streams: transactions.parallelStream() .collect(Collectors.toMap( Transaction::getAccountId, Function.identity(), (t1, t2) -> t1.merge(t2), // merging logic HashMap::new )); After deployment, they observe that the resulting map is smaller than expected and some transaction summaries are missing. Profiling shows the merge function is called infrequently, suggesting that the map is losing entries. What is the most likely cause and the correct fix?

Accepted Answer

Replace HashMap::new with ConcurrentHashMap::new in the collector.. The issue is that `HashMap::new` is not thread-safe. When `parallelStream()` splits the stream into multiple threads, each thread creates its own `HashMap` for partial results. These partial maps are then merged using the collector's combiner, but `HashMap` does not guarantee thread safety during concurrent access or merging. Using `ConcurrentHashMap::new` ensures that the map can be safely populated and combined across threads, preventing lost entries. The merge function itself is associative (merging two summaries into one), so the problem is purely the thread-unsafe map supplier.

Answer

Remove parallelStream() and use sequential stream to avoid concurrency issues.

Answer

The merge function is not associative; change it to use a combiner that is associative.

Answer

Use forEach with a ConcurrentHashMap and putIfAbsent to manually merge.

Question 13

A team is developing a real-time data processing pipeline that reads sensor data from a message queue. The pipeline uses a flatMap operation that calls an external geocoding service for each sensor reading. The external service has a rate limit of 10 requests per second and is slow (150ms average response time). The current code: sensorStream.parallelStream() .flatMap(reading -> getGeocode(reading).stream()) .forEach(system.out::println); The application is overloaded because parallel stream fires many concurrent requests, exceeding the rate limit and causing failures. They need to process all sensor data but must respect the rate limit. Which approach should they use?

Accepted Answer

Use a sequential stream with a custom rate limiter (e.g., a semaphore) that blocks when the limit is reached.. Using a sequential stream with a custom rate limiter (e.g., a Semaphore configured to allow only 10 permits per second) ensures that the external geocoding service is called at a controlled rate, preventing rate-limit violations. The sequential stream processes elements one at a time, and the rate limiter blocks the thread when the limit is reached, naturally throttling requests to stay within the 10 requests/second limit while still processing all data.

Answer

Reduce the parallelism level by using a custom thread pool with a fixed number of threads.

Answer

Use filter to drop some sensor readings to reduce the load.

Answer

Use a sequential stream and hope the processing completes within the time window.

Question 14

A developer is converting legacy for loops to streams. The legacy code: List list = new ArrayList<>(); for (String s : strings) { if (s.length() > 5) { list.add(s.length()); } } They write: List list = strings.stream() .filter(s -> s.length() > 5) .map(s -> s.length()) .collect(Collectors.toList()); But it doesn't compile. The error is: 'cannot find symbol: method collect(Collector>)'. What is the likely issue?

Accepted Answer

The map operation returns an IntStream, which does not have a collect method. Use map(s -> s.length()).boxed().collect(...) or mapToInt(...).boxed().. The issue is that `map(s -> s.length())` on a `Stream` returns an `IntStream`, not a `Stream`. The `IntStream` interface does not have a `collect(Collector)` method; it only has `collect(Supplier, BiConsumer, BiConsumer)`. To use `Collectors.toList()`, you must convert the `IntStream` back to a `Stream` via `.boxed()`, or use `mapToInt(...).boxed()`, or use `map(s -> (Integer) s.length())` to keep a `Stream`.

Answer

The lambda in filter is incorrectly written; it should be s.length > 5.

Answer

The stream should be made unordered to allow the collector to function.

Answer

Use parallelStream() to enable the collect method.