我听到一位同事说：
JVM 垃圾收集时间随着 JVM 大小呈指数增长。这是因为引用树是要分配的对象数量的函数，并且随着对象数量的增加，遍历树的难度呈指数级增长。
这听起来是对的。
我听到另一位同事说：
同一台机器上的 JVM 垃圾回收是线性的。如果将 8GB JVM 拆分为同一台机器上的两个 4G JVM（通过微服务），则将具有相同的垃圾收集持续时间，因为相同的操作系统会减慢相同数量的对象的速度。
这看起来不对——因为两个较小的 JVM 上的对象树应该更浅并且更容易遍历。
我的问题是：JVM 收集时间是否随 JVM RAM 大小呈指数增长？
假设：使用 Oracle JVM。
虽然霍尔格斯的解释是正确的，但我想提出稍微不同的方面。
GC 花费的时间与活动集中活动对象的数量成正比。这很容易证明。假设我们有两个堆大小相同的应用程序。在第一个堆中，我们分配 10 个对象，每个对象 100 MB，在第二个堆中，我们分配 1000 万个对象，每个对象 100 字节。在下一次GC时，每个应用程序中的一半对象无法访问（死亡）并且可以被收集。
不言而喻，追踪对象最多的图会花费更长的时间。
（顺便说一句，我记得读过“浅而宽”与“深而窄”的测量结果，没有明显的差异，但我不记得在哪里。@Holger：如果你有来源，我很乐意阅读）
请注意，遵循既定的 Java 编码实践实际上将确保实时集很小。 JVM 希望您以这种方式进行编码，并竭尽全力帮助保持实时集较小，逃逸分析 https://dzone.com/articles/do-not-let-your-java-objects-escape这只是热点的一个技巧。
所以，简而言之：NO
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
