标记整理为什么比复制算法效率低？（对象存活率很低）

假设标记整理指的是mark-sweep，复制指的是别的copying GC算法，比如semi-space或者mark-compact。 垃圾回收是一个系统，不仅仅是回收，而是“内存分配”、“垃圾鉴别”、“垃圾回收”三部分的有机的整体。 mark-sweep的效率低是低，具体指的是“分配”速度慢。mark-sweep必须使用自由列表（free-list）方式管理类存。即：把某个大小的内存块组织成一个列表，每次分配那么大的内存块时，从里面选一个能用的。但有复制的算法，比如semi-space，可以使用bump-pointer方式分配内存。也就是一开始就有一块连续的空间，用一个指针指向开头。不管分配多大的空间，都从那个指针位置连续分配。可以看出，bump-pointer的算法比semi-space简单得多，没有“确定对象大小”以及“查找列表”之类的动作。而mark-sweep之所以不能使用bump-pointer，就是因为bump-pointer必须整理内存碎片。因为没有free-list来组织空闲的空间，一旦连续空间的中间出现空洞，就分配不进去了。所以，所有bump-pointer的垃圾回收算法必须通过移动对象来整理碎片。semi-space把对象从旧空间移走，移动到另一块全新的连续空间里；而mark-compact会先计算出来每个对象最终会到什么位置，然后压缩当前空间（由于算法复杂，mark-compact速度很慢，但空间效率高）。 但mark-sweep的优势在于“回收”速度快。由于有free-list，一个对象死了，只要续到相应的free-list中就可以了。非常简单，不用移动对象或者整理碎片。 所以，mark-sweek分配慢，回收快；copying GC是分配快，回收慢。 如果从整个程序（包括mutator，就是正常执行的应用程序，也包括GC）整体来看，还是copying GC快。原因是，如果分配速度慢，会影响到正在执行的程序，毕竟“分配”是在应用程序执行过程中不断执行的（比如new表达式）。而且，bump-pointer的cache locality非常好。应用程序一般有一个模式：新分配的对象会很快很频繁地被使用；而且同时分配的几个对象也很可能会同时被使用。bump-pointer按程序顺序分配的对象一般是相邻的。所以对cache很友好。copying GC还有一个变种，就是generational GC。和semi-space类似，但年轻的一代空间很小，一旦满了立即回收。现实中，对象的“新生儿死亡率”非常高。所以，generational GC可以很快地很有效地清除掉大量“早死”的对象，使得“老一代”的垃圾回收压力降低。所以HotSpot JVM默认使用三代的generational GC，最老的一代使用的是非常慢但空间效率很高的mark-compact，但总体速度很快。 copying GC还有一个必要性，就是内存碎片整理。长时间运行的程序，内存会不断碎片化，这样，即使有内存，也分配不出来了。这对服务器很重要，人们都不希望服务器每隔一定时间就要重启吧。所以copying GC是非常必要的。 对于垃圾回收综述最好的，我觉得是Rifat Shahriyar博士的论文，系统地比较了各种分配、组织、回收的算法。 https://digitalcollections.anu.edu.au/handle/1885/99879

资料看JAVA虚拟机，讲的很清楚。 【 在 mandy4321 的大作中提到: 】 : 感觉他们都经过了标记，移动存活对象的阶段，区别只是前者在当前内存区域移动，后者移动到一块逻辑上新的区域（不知道理解对不对），看不出标记整理效率低在什么地方了，想了解底层的内存地址分配啥的，没找到好的资料。