Gatherers.mapConcurrent only limits execution of concurrent tasks, not the results themselves, and since mapConcurrent preserves encounter order, when the next-item-to-be-pushed takes longer than the rest there's a build-up of already completed subsequent elements.

So under variable delay processing with large (or unbounded) streams out-of-memory situations can occur.

We can address this by not only limiting concurrent task processing, but limiting the work-in-progress to the configured maxConcurrency.

Gatherers.mapConcurrent responds to interruptions on the thread evaluating the stream by cutting the stream processing short. This can be non-intuitive, so a more dependable behavior would be to ignore-and-restore interruptions.

Gatherers.mapConcurrent doesn't wait until all spawned Virtual Threads have exited before returning from its finisher. In order to ensure that cleanup has occurred, it should wait for all those threads to have terminated when the finisher returns.