java-8 - 来自 File.lines() 的并行流的内存使用情况

Question

我正在使用 Files.lines() 从大文件 (8GB+) 中读取行。如果按顺序处理，效果很好，内存占用非常低。一旦我将 parallel() 添加到流中，它似乎就会永久卡在它正在处理的数据上，最终导致内存不足异常。我相信这是 Spliterator 在尝试拆分时缓存数据的结果，但我不确定。我剩下的唯一想法是编写一个带有 trySplit 方法的自定义 Spliterator，该方法剥离少量数据进行拆分，而不是尝试将文件分成两半或更多。有没有其他人遇到过这个？

Answer 1

通过代码追踪我猜是 Spliterator被 Files.lines() 使用是Spliterators.IteratorSpliterator .谁的trySplit()方法有这样的评论:

        /*
         * Split into arrays of arithmetically increasing batch
         * sizes.  This will only improve parallel performance if
         * per-element Consumer actions are more costly than
         * transferring them into an array.  The use of an
         * arithmetic progression in split sizes provides overhead
         * vs parallelism bounds that do not particularly favor or
         * penalize cases of lightweight vs heavyweight element
         * operations, across combinations of #elements vs #cores,
         * whether or not either are known.  We generate
         * O(sqrt(#elements)) splits, allowing O(sqrt(#cores))
         * potential speedup.
         */

然后代码看起来像是分成了 1024 条记录(行)的倍数的批处理。所以第一个拆分将读取 1024 行，然后下一个拆分将读取 2048 行等等。每个拆分将读取越来越大的批量大小。

如果您的文件真的很大，它最终会达到最大批处理大小 33,554,432，即 1<<25 .请记住，这是行而不是字节，这可能会导致内存不足错误，尤其是当您开始让多个线程读取那么多时。

这也解释了减速的原因。在线程可以处理这些行之前提前读取这些行。

所以我要么不使用 parallel()完全或者如果你必须这样做，因为你正在做的计算每行都很昂贵，请编写你自己的 Spliterator，它不会像这样 split 。可能总是使用一批 1024 就可以了。