java - 从 GC 角度来看 Java 流的影响或通过 GC 处理短期对象

Question

网上有一些文章提到了使用 Stream-s 相对于旧的 loop-s 的一些缺点:

• https://blog.jooq.org/2015/12/08/3-reasons-why-you-shouldnt-replace-your-for-loops-by-stream-foreach/
• https://jaxenter.com/java-performance-tutorial-how-fast-are-the-java-8-streams-118830.html

但是从GC的角度来看有什么影响吗？正如我假设(正确吗？)每个流调用都会在下面创建一些短暂的对象。如果底层系统频繁调用使用流的特定代码片段，从 GC 的角度来看，它最终是否会导致一些性能问题或给 GC 带来额外的压力？或者影响很小并且大多数时候可以忽略不计？

是否有任何文章对此进行了更详细的介绍？

Answer 1

公平地说，当 Holger 已经通过他的答案将主要思想联系起来时，给出答案是非常复杂的；我仍然会尝试。

GC 上的额外压力 - 可能是。执行 GC 周期需要额外的时间 - 很可能不会。可以忽略吗？我想说完全可以。到底你关心什么来自GC - 只需很少的时间即可回收大量空间，最好是通过超小型的世界静止事件。

让我们讨论一下 GC 主要两个阶段的潜在开销:标记和疏散/重新分配 (Shenandoah/ZGC)。第一 mark阶段，其中 GC找出什么是垃圾(通过实际识别什么是活的)。

如果 Stream 内部创建的对象不可访问，则永远不会扫描它们(此处为零开销)，如果可访问，则扫描它们将非常快。故事的另一面是:当您创建一个对象并GC时当它在标记阶段运行时，可能会触及它，LoadBarrier 的慢速路径(在 Shenandoah 的情况下)将处于 Activity 状态。这将添加几十个 ns我假设 GC 的特定阶段的总时间以及 SATB 中的一些空间队列。 Aleksey Shipilev 在一次演讲中表示，他试图测量执行单个屏障的开销，但未能成功，因此他测量了 3时间在数十 ns 范围内。我不知道 ZGC 的具体细节，但 LoadBarrier 也在那里。

要点是，这个标记阶段是在应用程序运行时以并发方式完成的，因此您的应用程序仍然可以完美运行。即使某些 GC 代码会被触发去做一些特定的工作(负载屏障)，它也会非常快并且对您来说完全透明。

第二阶段是“压缩”，即为 future 的分配腾出空间。 GC 的作用是将 Activity 对象从垃圾最多的区域(肯定是 Shenandoah)移动到空的区域。但仅限于有生命的物体。因此，如果某个区域有 100 个对象，并且只有 1 个对象处于 Activity 状态，则只有 1 个对象会被移动，那么整个区域将被标记为空闲。因此，如果 Stream 实现仅生成垃圾(即:当前不存在)，那么它对于 GC 来说是“免费午餐”，它甚至不知道它的存在。

这里更好的情况是这个阶段仍然是同时完成的。为了保持“并发”活跃，您需要知道 GC 周期从开始到结束分配了多少内存。这个数量是为了让 GC 正常工作而需要在 java 进程之上拥有的最小“额外”空间。

所以总的来说，你看到的是一个非常微小的影响；如果有的话。