JVM-垃圾收集过程的内存管理

JDK1.7 JVM的垃圾收集算法有

1. 标记-清除算法；

2. 复制算法；在商业虚拟机都是使用这种算法来回收新生代的

3. 标记-整理算法；

4、分代收集算法；

JDK1.7 JVM的垃圾收集器有

1. Serial收集器 -- 复制算法

2. parNew收集器 -- 复制算法

3. parallel scavenges收集器 -- 复制算法

4. serial old收集器 -- 标记整理算法

5. parallel old收集器-- 标记整理算法

6. CMS收集器-- 标记-清除算法

7. G1收集器 -- 标记整理算法

垃圾收集的过程:

　　HosSpot JVM要判断对象的是"活的" 还是 "死的" 用的是“可达性分析算法”，如果经过 “可达性分析算法” 发现没有与 GC Roots 相连接的引用链，那就会被第一次标记并且进行筛选，筛选的条件是次对象是否有必要执行 finalize() 方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，就被视作 “没有必要执行”。

　　如果这个对象被判定为有必要执行finalize()方法，那么这个对象将被放置在F-Queue队列中，GC将会对F-Queue中的对象进行第二次小规模的标记(如果在调用finalize()方法时重新与引用链上的任何对象建立关联，那么在第二次标记时就会被移除 “即将回收” 的集合)，当被两次标记后，就认定这个对象是 “死了”

　　下面就来看看"对象死了"后内存分配与回收策略

　　对象的内存分配就是往堆上分配，主要分配在Eden区，当Eden区没有足够的空间时，会发起一次MinorGC,如果对象在Eden出生并经过第一次MinorGC后仍然存活，并且能够被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1，对象在Survivor区中每“熬过”一次MinorGC,年龄就加1岁，当年龄(默认15岁)增加到一定程度就将被晋升到老年代中。

Survivor区的作用是什么？

　　Survivor分为两块，一块是From区，GC日志中是S1。一块是To区，GC日志中是S2(From区和To区的大小是一致的)。Survivor的作用是为了减缓对象进入老年代。对象最活跃的地方应该就是在新生代。

方法区什么时候被回收？

　　永久代的垃圾收集主要回收两部分内容：废弃常量和无用类。会搜狐废弃常量与回收Java堆中的对象非常类似。以常量池中字面量回收为例，如果一个字符串 “abc” 已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，也就是没有任何String的对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果这时发生内存回收，而且必要的话，这个“abc”常量就会被系统清理出常量池。常量池中其他类（接口）、方法、字段符号引用也与此类似。

　　类满足了下面三个条件就算是无用类：

　　　　★该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。

　　　　★加载该类的ClassLoader已经被回收

　　　　★该类对应的java.lang.Class 对象没有再任何地方被引用，无法在任何地方通过反射访问该类的方法。

　　虚拟机“可以”对满足上面三个条件的无用类进行回收（注意是“可以”而不是和对象一样，不使用了就必然会回收）。是否对无用类进行回收，HotSpot虚拟机提供了 -Xnoclassgc 参数进行控制，还可以使用 -verbpse:class 以及 -XX:+TraceClassLoading 、-XX:+TraceClassUnLoading 查看类加载和卸载信息，其中 -verbpse:class 和 -XX:+TraceClassLoading 可以再Product版的虚拟机中使用，-XX:+TraceClassUnLoading 参数需要FastDebug版的虚拟机支持

参考：

　　【1】《深入理解Java虚拟机》，周志明