java - Java VM 是否移动内存中的对象，如果是，如何移动？

Question

Java 虚拟机是否曾在内存中移动对象，如果是，它如何处理对移动对象的更新引用？

我问是因为我正在探索以分布式方式(即跨多个服务器)存储对象的想法，但出于效率原因，我需要能够在服务器之间移动对象。对象需要能够包含指向彼此的指针，甚至指向远程服务器上的对象。我正在尝试考虑更新对移动对象的引用的最佳方法。

到目前为止我的两个想法是:

1. 在某个地方维护一个引用间接，它在对象的生命周期内不会移动，如果对象移动，我们会更新它。但是 - 如何管理这些间接访问？
2. 保留每个对象的反向引用列表，这样我们就知道如果对象被移动必须更新什么。当然，这会产生性能开销。

我很想知道有关这些方法的反馈以及对替代方法的任何建议。

Answer 1

引用上面关于遍历堆的评论。

不同的 GC 以不同的方式执行此操作。

通常在遍历堆时复制收集器，它们不会遍历堆中的所有对象。相反，他们遍历堆中的 LIVE 对象。这意味着如果可以从“根”对象访问它，则该对象是 Activity 的。

因此，在这个阶段无论如何都必须接触所有 Activity 对象，因为它将它们从旧堆复制到新堆。一旦 Activity 对象的复制完成，旧堆中剩下的就是已经复制的对象，或者是垃圾。那时旧堆可以完全丢弃。

这种收集器的两个主要好处是它在复制阶段压缩堆，并且它只复制 Activity 对象。这对许多系统来说很重要，因为使用这种收集器，对象分配非常便宜，几乎不比增加堆指针高多少。当 GC 发生时，不会复制任何“死”对象，因此它们不会减慢收集器的速度。事实证明，在动态系统中，临时垃圾比长期存在的垃圾多得多。

此外，通过遍历 Activity 对象图，您可以看到 GC 如何“了解”每个对象，并跟踪它们以用于在复制期间执行的任何地址调整目的。

这不是深入讨论 GC 机制的论坛，因为这是一个非常重要的问题，但这是复制收集器如何工作的基础知识。

分代复制 GC 会将“较旧”的对象放在不同的堆中，这些对象最终被收集的频率低于“较新”的堆。该理论认为长期存在的对象被提升到老年代并且被收集的次数越来越少，从而提高了整体 GC 性能。