从迭代器创建的CompletableFuture并行流未实现延迟求值的原因

这是个非常典型的Java 8并行流与Spliterator特性相关的问题，咱们结合你的代码和Java流的底层逻辑来拆解：

核心差异：Spliterator的SIZED特性 #

Java Stream的并行处理能力完全依赖于Spliterator的特性，其中**SIZED特性**（表示Spliterator能提前知道元素总数量）是关键：

1. Stream.of()的正常表现 #

Stream.of("list one", ...)基于固定集合创建，对应的Spliterator自带SIZED特性。并行流处理时，能提前计算出需要处理的元素数量，配合limit(2)可以在流的早期阶段就截断元素流——只有前两个元素会进入map(this::cf)环节，所以仅会创建并执行前两个CompletableFuture，符合你的预期。

2. 基于未知大小Spliterator的异常表现 #

你的testIterator方法中，用Spliterators.spliteratorUnknownSize(...)生成的Spliterator没有SIZED特性，并行流无法提前得知总元素数量。

并行流的处理逻辑是通过拆分Spliterator来分配并行任务，对于未知大小的Spliterator，它会采取"贪婪"的拆分策略：不断尝试获取元素、拆分任务，直到满足终止条件（比如limit(2)的数量要求）。但在这个过程中，已经被拆分出来的元素会被依次送入map环节——也就是你的cf()方法会被所有元素调用，导致所有CompletableFuture都被创建并启动异步任务。而limit(2)只是在最终的forEach阶段只消费前两个结果，无法回溯阻止已经启动的异步任务。

parallel()的影响 #

移除parallel()后表现正常，是因为串行流是按需逐个获取元素：先取第一个元素处理，完成后再取第二个，满足limit(2)后就停止获取后续元素，自然不会触发后续的cf()调用。而并行流为了提高效率，会提前批量获取更多元素进行拆分处理，这才暴露了未知大小Spliterator的问题。

解决方案（针对Java 8） #

如果你的场景中能提前获取Iterator对应的元素数量，可以改用带大小参数的Spliterator创建方式：

// 假设你能拿到原集合的size
int size = Arrays.asList("iterator one", "iterator two", "iterator three", "iterator four", "iterator five").size();
Iterator<String> iterator = Arrays.asList("iterator one", "iterator two", "iterator three", "iterator four", "iterator five").iterator();
StreamSupport.stream(Spliterators.spliterator(iterator, size, Spliterator.ORDERED), false)

这样生成的Spliterator带有SIZED特性，并行流就能像Stream.of()一样正确配合limit(2)截断元素流，避免不必要的异步任务执行。

如果无法提前获取大小，你可以考虑在map之前先执行limit(2)，或者手动控制异步任务的触发时机，确保只创建需要的CompletableFuture。

内容的提问来源于stack exchange，提问作者Peter