我听到一个同事说:
JVM garbage collection times increase exponentially with JVM size. This is because the tree of references is a function of the amount of the amount of objects to allocate - and gets exponentially harder to traverse the tree as the number of objects get bigger.
这听起来是对的。
我听到另一个同事说:
JVM garbage collection on the same machine is linear. Given an 8GB JVM split in two 4G JVMs on the same machine (via microservices) will have the same garbage collection durations because the same OS is slowing you down for the same number of objects.
这似乎不对——因为两个较小的 JVM 上的对象树应该更浅，更容易遍历。
我的问题是: JVM 收集时间是否随 JVM RAM 大小呈指数增长？
假设:使用 Oracle JVM。
最佳答案
没有这么简单的依赖。
首先，将“垃圾收集”视为对象引用上的函数显然只是指标记阶段，而忽略了分配、释放或复制/移动对象的成本。标记成本取决于必须遍历的事件引用的数量，死对象或未使用的内存都不会对其产生任何影响。因此，仅仅为同一个应用程序提供更多 RAM 并不一定会改变垃圾收集性能。
有一种趋势是使用您提供给 JVM 的任意数量的 RAM，因此提供更多 RAM 可能会降低垃圾收集周期的频率，但可能需要更多时间来标记所有事件对象。但是由于垃圾收集之间有更多的时间会增加对象变为未使用的机会，因此标记成本通常不会与收集之间的时间相同。
很容易证明在实践中它实际上是相反的。只需使用任意 Java 应用程序并将可用内存减少到几乎不运行时不会遇到 OutOfMemoryError 的程度。 .您将看到提供更少的 RAM 如何使其变慢，越接近该点，速度就会显着变慢。另一方面，实际上不需要证明为应用程序提供如此多的 RAM 以至于它在其生命周期内永远不需要垃圾收集具有最小的成本。
当我们只看标记阶段，而不考虑它发生的频率，而只考虑它如何随着实时引用的数量而变化时，仍然没有理由让它应该是指数级的。对象引用可以形成一个很少是树的任意图。此外，垃圾收集器不需要遍历每个对象引用。它只需要遍历之前没有遇到过的对象的引用(猜猜它为什么被称为“标记”)，这意味着需要遍历的引用数量与事件对象的数量相同。发现不需要遍历引用可能会产生一些成本，但这仍然是线性开销。
像 HotSpot(它不再是 Sun 的属性)这样的 JVM 使用分代垃圾收集和卡标记，只遍历内存部分(卡)发生变化的新对象和旧对象的引用，而不是所有事件对象。由于更改旧对象和创建新对象都需要 CPU 时间，因此它不会直接随可用 RAM 扩展。
关于performance - JVM 收集时间是否随 JVM RAM 大小呈指数增长？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48779855/