limit(n) 在并行流中性能差，因其默认依赖顺序，强制全局协调截取“前n个”，引发同步与缓冲开销；加 unordered() 可让各线程独立截断，显著提升并行效率。
并行流中直接使用 limit(n) 会严重削弱并行优势，尤其在默认有序模式下，它强制流保持元素原始顺序，导致各线程无法独立截断，必须协同同步、缓冲大量中间结果，最终性能可能比顺序流还差。
limit 在并行流中为何变慢
并行流默认是有序流（ordered），而 limit 是一个有状态操作——它需要确保取到的是“前 n 个满足条件的元素”。这意味着：
- ForkJoinPool 必须等待所有分段任务完成部分过滤后，按原始索引排序合并，再统一截取前 n 个
- 即使已有上千个匹配元素分散在不同线程中，系统仍不能提前终止其他线程，必须继续处理剩余数据
- 为维持顺序，内部需维护额外缓冲区和协调逻辑，内存与同步开销显著上升
何时 limit 会触发全量扫描
以下场景下，limit 实际等效于遍历全部数据：
- 对未排序大数据集做
filter + limit，且匹配元素集中在末尾（例如：找“第100个大于10000的数”） - 结合
sorted()使用，如sorted().limit(10)—— 排序本身已强制全量加载+归并 - 源是
ArrayList但元素分布稀疏（如仅1%满足 filter 条件），limit 值远小于总匹配数时仍无法早停
如何安全高效地用 limit
关键不是禁用 limit，而是解除其顺序依赖：
- 显式调用
.unordered()：若业务允许返回任意 n 个匹配项（不要求“前 n 个”），加这一行可让各线程自主截断，零同步开销 - 改用
findAny()或findFirst()：当只需 1 个结果时，它们天然支持短路，并发发现即返回 - 对小数据集（stream().limit(n) 更轻量，避免并行调度成本
- 预估匹配密度高时，可先用
skip()配合分批处理，避免单次 limit 压力过大
验证性能影响的简易方式
用相同数据对比执行时间：
- 慢路径：
list.parallelStream().filter(...).limit(100).count() - 快路径：
list.parallelStream().unordered().filter(...).limit(100).count()
在百万级列表中，后者常快 3–8 倍；若匹配率低于 5%，前者耗时可能接近全量遍历。
