本文共 1526 字，大约阅读时间需要 5 分钟。

这一部分内容是JVM继续深化部分，有需求想要了解的可以看一下，不然就是浪费时间了。

我们已经知道GC的主要工作区域是Java堆，对象的保存区域。下面就来闲扯一下我看书时找到的几个问题：

1.GC在回收的时候，是采用什么小窍门回收（算法）的？

2.GC是怎么确定要回收的内容的，不会导致回收多了或者少了？

3.GC具体执行回收操作的时候，它大概是怎么跑的？

4.现有的GC回收器分配内存的时候是怎么分配的，有什么原则？

第一个问题：

GC回收的时候，采用的方法根本上讲只有两种.

某位简单至上的算法工程师说：这个很简单吗，把需要清理的提前标记好，到了清理的时候直接回收标记的对象就好了。（标记--清除算法）

于是按照这种做法去实现，最后内存管理员跑过来说：简单是简单，你看清理完之后的空间就跟被狗啃了一样，继续分配新空间难度增加了。

看到这样的情况之后，某位思维缜密的算法工程师说：要不把空间均分成两份，只在一份上分配空间，同时做好回收标记，等到回收的时候，把不需要回收的复制到另外一半空间，直接把老的空间全部初始化清理。这样保证空间就跟新的一样，狗都不好意思下口。（复制算法）

旁边的财务看不下去了，说：这得奢侈到什么程度才能买两台服务器，用一台，然后一台当垃圾站。

看着这几位在这里撕逼，算法工程师老油子说：这两个想法都不错，要不干脆结合着一起用吧，先将不标记的内容往空间的一段移动，然后把剩下的全部清理掉。（标记--整理算法）

至于当前商业虚拟机采用的分代收集算法是划分空间成为新生代和老年代，对新生代采用复制算法，老年代采用标记--清除算法或者标记--整理算法。这个并不能算作一个算法，只能看做是前面算法的应用，至少我是这么看的。

第二个问题

由于Java堆区各种各样的对象大聚会，怎么确定对象是不是喝多了，这个问题很重要。在这个时候，负责招待的侍者观察到了一个现象：一段时间内没有点餐和用餐的对象有极高的可能性是喝多了。于是我们根据这个重要的现象，得到一个非常有意思的结论：凡是正在用餐和点餐的对象可以从其中少数几个点餐和用餐的对象遍历获得所有的正在用餐和点餐的对象。这样的话，只要确定几个非常稳定的几个点餐对象就好了。这几个重要并且稳定的对象是全局的引用、正在执行的上下文(对象方法的本地变量表)。

全局引用主要有常量或者静态变量，正在执行上下文主要包括方法的局部变量、方法信息、类信息等。

虽然我们现在知道了搜索的起点，可是要在很短的时间内从庞大的对象集合中分析出活动的对象还是很困难的。为了提高这个搜索的效率，技术部门的老油条说：既然时间有要求，那么就用空间换时间，预先将搜索区域变得有序。根据这个指导，JVM在加载class文件到java堆区的时候，计算出每个方法的本地变量表的偏移量，存储到一块空间上。当启动搜索的时候，不用去遍历，直接查找偏移量存在的空间，这会节省大量的时间。

综合上面的描述可以得到如何确定要回收/保留的对象。

第三个问题

第一个步骤是设定第二个问题中确定回收对象的过程

第二个步骤是在程序运行的某种稳定区域（例如：指令做循环、方法调用、异常跳转等）进行短暂的暂停整个GC工作的内存区域，启动搜索，获得需要保留的对象

第三个步骤是GC进行回收空间操作

第四个问题

由于现有的商业GC基本采用分代收集。所以在为新对象分配内存的时候，优先分配到新生代的空间中。当对象经历过一定次数的回收但仍然被使用时，它将会被转移到老年代空间中。老年代空间中的对象存活情况很稳定，需要回收的几率是很低的。新生代是新加载对象的主要区域，空间回收上使用非常狂野的复制算法；老年代比较稳定，使用很温和的标记--清除算法或者标记--整理算法。

转载地址：http://kzvdi.baihongyu.com/