Java GC问题

面试过程中会经常问到的一些问题：

一.fullGC的触发条件有哪些？

1、调用System.gc()方法

2、老年代内存空间不足

3、永久代内存空间不足

4、统计得到MinorGC晋升到老年代的平均内存大小大于老年代的剩余空间；也就是在MinorGC时会做检测，如果超过，则立即进行fullGC。

5、堆中分配很大的对象，比如大数组（这种情况会直接进入老年代），需要大量连续的内存空间，而老年代虽然有很大的剩余空间，但是无法找到足够大的连续空间来分配给当前对象，则会触发fullGC。

二.CMS GC问题

在heap size<=3G的情况下完全不要考虑CMS GC，在heap size>3G的情况下也优先选择ParallelOldGC，而不是CMS GC，只有在暂停时间无法接受的情况下才考虑CMS GC（不过当然，一般来说在heap size>8G后基本上都得选择CMS GC，否则那暂停时间是相当吓人的，除非是完全不在乎响应时间的应用），这其实也是官方的建议（每年JavaOne的GC Tuning基本都会这么讲）。

1、触发比率不好设置 在JDK 1.6的版本中CMS GC的触发比率默认为old使用到92%时，假设3G的heap size，那么意味着旧生代大概就在1.5G--2.5G左右的大小，假设是92%触发，那么意味着这个时候旧生代只剩120M--200M的大小，通常这点大小很有可能是会导致不够装下新生代晋生的对象，因此需要调整触发比率，但由于heap size比较小，这个时候到底设置为多少是挺难设置的；

2、抢占CPU CMS GC大部分时间和应用是并发的，所以会抢占应用的CPU，通常在CMS GC较频繁的情况下，可以很明显看到一个CPU会消耗的非常厉害。 

3、YGC速度变慢 由于CMS GC的实现原理，导致对象从新生代晋升到旧生代时，寻找哪里能放下的这个步骤比ParallelOld GC是慢一些的，因此就导致了YGC速度会有一定程度的下降。

4、碎片问题带来的严重后果 CMS GC最麻烦的问题在于碎片问题，同样是由于实现原理造成的，CMS GC为了确保尽可能少的暂停应用，取消了在回收对象所占的内存空间后Compact的过程，因此就造成了在回收对象后整个old区会形成各种各样的不连续空间，自然也就产生了很多的碎片；碎片会造成什么后果呢，会造成例如明明旧生代还有4G的空余空间，而新生代就算全部是存活的1.5g对象，也还是会出现promotion failed的现象，而在出现这个现象的情况下CMS GC多数会采用Serial Full GC来解决问题。 碎片问题最麻烦的是你完全不知道它什么时候会出现，因此有可能会造成某天高峰期的时候应用突然来了个长暂停，于是就悲催了；

在大内存的情况下，CMS GC绝对是不二的选择，而且Java在面对内存越来越大的情况下，必须采用这种大部分时候不暂停应用的方式，否则Java以后就非常悲催了，G1GC在CMS GC的基础上，有了很多的进步，尤其是会做部分的Compact，但仍然碎片问题还是存在的

三.G1

G1垃圾回收器

G1垃圾回收器适用于堆内存很大的情况，他将堆内存分割成不同的区域，并且并发的对其进行垃圾回收。G1也可以在回收内存之后对剩余的堆内存空间进行压缩。并发扫描标记垃圾回收器在STW情况下压缩内存。G1垃圾回收会优先选择第一块垃圾最多的区域

通过JVM参数 –XX:+UseG1GC 使用G1垃圾回收器

四.JDK1.8为什么将永久代去掉了，使用元空间？

在JDK7之前的HotSpot虚拟机中，纳入字符串常量池的字符串被存储在永久代中，因此导致了一系列的性能问题和内存溢出错误。永久代的垃圾回收和老年代的垃圾回收是绑定的，一旦其中一个区域被占满，这两个区都要进行垃圾回收。但是有一个明显的问题，由于我们可以通过‑XX:MaxPermSize 设置永久代的大小，一旦类的元数据超过了设定的大小，程序就会耗尽内存，并出现内存溢出错误(OOM)

永久代中的元数据可能会随着每一次Full GC发生而进行移动。并且为永久代设置空间大小也是很难确定的，因为这其中有很多影响因素，比如类的总数，常量池的大小和方法数量等。

 

由于类的元数据分配在本地内存中，元空间的最大可分配空间就是系统可用内存空间。因此，我们就不会遇到永久代存在时的内存溢出错误，也不会出现泄漏的数据移到交换区这样的事情。最终用户可以为元空间设置一个可用空间最大值，如果不进行设置，JVM会自动根据类的元数据大小动态增加元空间的容量

元空间虚拟机采用了组块分配的形式，同时区块的大小由类加载器类型决定。类信息并不是固定大小，因此有可能分配的空闲区块和类需要的区块大小不同，这种情况下可能导致碎片存在。元空间虚拟机目前并不支持压缩操作，所以碎片化是目前最大的问题

五.GC监控有哪些方法？

常用jstat，jmap等，用于监控GC的情况。

使用方法 jstat -gcutil LVMID 间隔时间 执行次数（ 通过jps命令可拿到LVMID）

六. 数组多大放在 JVM 老年代

虚拟机提供了一个-XX:PretenureSizeThreshold参数

七.如果想不被 GC 怎么办

强引用

八.永久代对象如何GC？

永久代中保存的主要是已被虚拟机加载的类信息以及常量信息，因此永久代中垃圾回收主要包括两个部分：废弃的常量和无用的类。

1、废弃的常量：判断常量是否已废弃的方法与判断对象是否存活的方式类似，即发现如果没有任何对象引用常量池中的常量时，即可断定该常量是可以被回收的。

2、无用的类：判断一个类是否无用会比较复杂一点，需要从以下几个方面进行判断：

• 该类所有的实例已经被回收，也就是java堆中不存在该类的任何实例

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

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