我阅读了大量有关 Java SE 6 和 7 的 HotSpot GC 的文档。在讨论获取连续空闲内存区域的策略时，提出了两种“竞争”方法:Evacuation(通常应用于年轻一代)，其中 Activity 对象从'from'复制到空的'to'和Compaction(CMS的后备)，其中 Activity 对象被移动到碎片区域内的一侧以形成连续的 block 使用未使用的内存。
这两种方法都与“Activity 集”的大小成正比。不同之处在于疏散需要比现场集 x2 倍的空间，而压实则不需要。
为什么我们根本需要 Evacuation 技术？需要完成的复制量是相同的，但是它需要保留更多的堆大小，并且不允许更快的重新映射的引用资料。
是的:疏散可以并行执行(而压缩不能，或者至少不那么容易)但是这个特性从未被提及并且似乎并不那么重要(考虑到重新映射比移动要昂贵得多)。
最佳答案
一个大问题是，对于“疏散”，腾出的空间实际上是空的，而对于“压缩”，一些其他对象 Y 可能会移动到对象 X 所在的空间。这使得更正指针变得更加困难，因为不能简单地使用指针指向无效位置这一事实来提示需要更新它的代码。并且不能将“转发指针”存储在“无效”位置。
这大大降低了 GC 的并发性——应用程序必须处于“GC 卡住”状态的时间更长。
关于java - 垃圾收集中疏散和压缩之间的根本区别是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20829813/