joc*_*ull 3 java garbage-collection optional
我们都知道，用Java分配的每个对象都增加了以后的垃圾回收周期的权重，并且Optional<T>对象没有什么不同。我们经常使用这些对象来包装可为空的对象，这将导致代码更安全，但是要花多少钱呢？
是否有人知道可选对象添加了什么样的附加GC压力，而不是简单地返回null，以及这对高通量系统的性能有什么样的影响？
我们都知道，用Java分配的每个对象都会在未来的垃圾回收周期中增加权重，…
这听起来像是一条没人能否认的声明，但是让我们看一下垃圾收集器的实际工作，考虑现代JVM的常见实现以及分配的对象对其的影响，尤其是像Optional实例之类的对象，这些对象通常是临时性的。
垃圾收集器的首要任务是识别仍然存在的对象。名称为“垃圾收集器”的重点是识别垃圾，但是垃圾被定义为无法访问的对象，而找出哪些对象无法访问的唯一方法是通过消除过程。因此，第一个任务是通过遍历和标记所有可到达的对象来解决。因此，此过程的成本不取决于分配的对象的总量，而仅取决于仍可实现的对象。
第二项任务是使垃圾内存可用于新分配。所有现代垃圾收集器都不会撤消仍然可访问的对象之间的内存空白，而是通过撤离完整区域，将带有该内存的所有活动对象转移到新位置并调整引用来工作。在此过程之后，整个块可将内存用于新分配。因此，这又是一个过程，其成本不取决于分配的对象的总量，而仅取决于仍然存在的对象（的一部分）。
因此，Optional如果在两个垃圾回收周期之间分配和放弃该对象，那么临时对象之类的对象可能根本不会增加实际垃圾回收过程的成本。
一口气，当然。每次分配都会减少可用于后续分配的内存，直到没有剩余空间并且必须进行垃圾回收为止。因此，可以说，每次分配都会减少两次垃圾回收运行之间的时间，方法是分配空间的大小除以对象大小。这不仅是很小的一部分，而且还仅适用于单线程方案。
在像Hotspot JVM这样的实现中，每个线程都将线程本地分配缓冲区（TLAB）用于新对象。一旦TLAB装满，它将从分配空间（又名Eden空间）中获取一个新的。如果没有可用的，将触发垃圾回收。现在，不太可能所有线程同时到达其TLAB的末端。因此，对于此时在其TLAB中仍有剩余空间的其他线程，如果它们分配了更多仍适合该剩余空间的对象，则不会有任何区别。
可能令人惊讶的结论是，并非每个分配的对象都会对垃圾回收产生影响，即由线程分配的不触发下一个gc的纯本地对象可能是完全空闲的。
当然，这不适用于分配大量对象。分配很多它们会导致线程分配更多的TLAB，并最终比没有的情况更早触发垃圾回收。这就是为什么我们有这样的类，例如IntStream允许处理大量元素而无需分配对象的情况（如会发生这种情况）Stream<Integer>，而将结果作为单个OptionalInt实例提供则没有问题。众所周知，单个临时对象对gc的影响很小（如果有的话）。
如果Escape Analysis已证明对象纯粹是本地的，那么这甚至没有触及JVM的优化器，后者可以消除热点中的对象分配。