Java 中可选<T>的 GC 开销

我们都知道，在Java中分配的每个对象都会在未来的垃圾回收周期中增加权重,...

这听起来像是一个没有人可以否认的声明，但让我们看看垃圾回收器的实际工作，考虑现代JVM的常见实现以及分配对象对其的影响，特别是像实例这样的对象，这些实例通常是临时性的。Optional

垃圾回收器的首要任务是识别仍处于活动状态的对象。“垃圾回收器”这个名称将重点放在识别垃圾上，但垃圾被定义为无法访问的对象，找出哪些对象无法访问的唯一方法是通过消除过程。因此，第一个任务是通过遍历和标记所有可访问的对象来解决的。因此，此过程的成本不取决于分配对象的总量，而仅取决于那些仍然可以访问的对象。

第二个任务是使垃圾的内存可用于新的分配。所有现代垃圾回收器都不会对仍然可访问的对象之间的内存差距感到困惑，而是通过疏散整个区域，将所有具有该内存的活动对象传输到新位置并调整对它们的引用来工作。该过程完成后，内存作为整个块可用于新分配。因此，这又是一个过程，其成本不取决于分配对象的总量，而仅取决于（部分）仍然处于活动状态的对象。

因此，如果像临时对象这样的对象在两个垃圾回收周期之间分配和放弃，则可能不会对实际的垃圾回收过程产生任何成本。Optional

当然，只有一个捕获。每次分配都会减少可用于后续分配的内存，直到没有剩余空间并且必须进行垃圾回收。因此，我们可以说，每次分配都会通过分配空间的大小除以对象大小来减少两个垃圾回收运行之间的时间。这不仅是一个相当小的分数，而且仅适用于单线程方案。

在像 Hotspot JVM 这样的实现中，每个线程都对新对象使用一个线程本地分配缓冲区 （TLAB）。一旦它的TLAB满了，它将从分配空间（又名伊甸园空间）中获取一个新的。如果没有可用的垃圾回收，将触发垃圾回收。现在，所有线程都不太可能同时到达其 TLAB 的末尾。因此，对于此时在 TLAB 中仍有一些空间的其他线程，如果它们分配了更多仍适合该剩余空间的对象，则不会有任何区别。

也许令人惊讶的结论是，并非每个分配的对象都会对垃圾回收产生影响，即由不触发下一个gc的线程分配的纯本地对象可能是完全免费的。

当然，这不适用于分配大量对象。分配大量 TLAB 会导致线程分配更多的 TLAB，并最终比没有更多 TLAB 更早触发垃圾回收。这就是为什么我们有这样的类，比如允许在不分配对象的情况下处理大量元素，就像 a 一样，而将结果作为单个实例提供没有问题。正如我们现在所知道的，单个临时对象对gc的影响很小（如果有的话）。IntStreamStream<Integer>OptionalInt

这甚至没有触及JVM的优化器，如果逃逸分析已经证明对象是纯本地的，它可能会消除热点中的对象分配。