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虚拟机》,周志明

原文地址:https://www.cnblogs.com/happyflyingpig/p/7988958.html