【面试总结】JVM虚拟机

内存泄漏与内存溢出：

内存泄漏：指申请到的对象，用完之后没有被回收，导致下次申请的时候这些内存空间无法访问。

内存溢出：指申请内存的时候，没有足够的内存空间供其使用，超过了内存的最大限度，出现了out of memory。（内存溢出就是你要求分配的内存超出了系统能给你的，系统不能满足需求，于是产生溢出）

内存泄漏最终会导致内存溢出。

内存溢出的原因：

• 内存中加载的数据量过于庞大，例：一次性从数据库中取出很多数据。
• 静态集合类使用完后，没有释放对变量的引用。如：HashMap ，vevtor中存储了对象，但是对象引用为null,这些静态集合类还引用这些对象，当申请过多时，会导致内存溢出。
• 代码中出现死循环，或者产生过多的重复我对象实体。
• 第三方软件，过多的jar包
• JVM启动参数过小

常见out of memory: java.lang.OutOfMemoryError: Java heap space,java.lang.OutOfMemoryError: PermGen space。

解决步骤如下：

1. 修改JVM启动参数，直接增加内存，-Xms（初始内存），-Xmx最大内存。
2. 打印GC日志，查看GC情况，-XX：-printGC Detail
3. 代码走查，检查是否用死循环或者重复申请对象的地方，找出可能溢出的地方。

实例：java.lang.OutOfMemoryError: Java heap space

• 堆内存溢出。
• 原因：一次性申请过多数据库数据，当一次查询10W条以上的数据时就会出现内存溢出
• 做法：（1）增加JVM内存，-Xms -Xmx （2）查看GC日志，有没发生GC （3）若年轻代或老年代空间不足，可以设置参数（4）还不行，使用分批查询，将50W数据分别10批分别取出

java.lang.OutOfMemoryError: PermGen space异常处理

• PermGen 为永久代，方法区，存放类信息，静态信息，当加载过多的类时候，报出内存溢出。
• 这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中
• 解决方法：-XX:PermSize=32M -XX:MaxPermSize=64M 

 

内存泄漏的原因：

• 静态集合类由于生命周期与应用程序一样长，当其中存放对象时，对象释放了，但是集合类还引用这对象，没有释放集合类，导致内存泄漏。解决方法：将集合类也释放掉 vector=null;
• 连接使用后为关闭，常用的数据库连接，IO连接等未释放也会导致内存泄漏.解决方法：关闭连接
• 监听器，释放对象后没有删除监听器  解决方法：删除监听器
• 单例对象，由于是静态对象，在整个生命周期都存在，若单例对象持有外部引用将导致内存泄漏。
• 内部类和外部模块等的引用：  内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。此外程序员还要小心外部模块不经意的引用，例如程序员A 负责A 模块，调用了B 模块的一个方法如： public void registerMsg(Object b); 这种调用就要非常小心了，传入了一个对象，很可能模块B就保持了对该对象的引用，这时候就需要注意模块B 是否提供相应的操作去除引用。

 

JVM内存模型：

• 程序计数器：是JVM中一段较小的内存空间，作用可以看做是当前线程执行字节码的行号指示器。字节码解释器的工作都要依靠修改这个计数器的值来完成，是线程隔离的空间，如果是native方法，计数器为0.也是唯一一个不会发生内存溢出的空间。
• 虚拟机栈：线程私有，声明周期与线程的周期相同，表示的是java方法执行的内存模型：每一个方法入栈的同时都会创建栈帧，用于保存局部变量表，操作栈，动态链接和方法出口等信息。方法的执行过程就对应了，栈帧入栈出栈的过程。局部变量表中存放编译期可知的基本数据类型和对象引用。

异常：当线程申请的栈深度超过最大深度，抛出stackoverflowerror.若栈可以扩展，当无法扩展时，抛出outofmemory。

• 堆（heap）:JVM中内存管理最大的一块内存。是线程之间共享，用于存放创建的对象的实例。也是GC发生的主要区域。由于目前jvm采用分代收集算法，java堆可以分为新生代和老年代。当无法申请内存时，抛出outofmemory。
• 老年代 ： 三分之二的堆空间
• 年轻代 ： 三分之一的堆空间  eden区： 8/10 的年轻代空间
• survivor0 : 1/10 的年轻代空间
• survivor1 : 1/10 的年轻代空间

方法区：线程共享，主要用于存放编译期加载的类信息，常量以及静态变量数据等。常量池--1.7之后，字符串常量池在队中。

运行时常量池：也是方法区的一部分，用于存放编译期生成的各种字面量和符号引用。

 

类加载过程：

加载-验证-准备-解析-初始化

• 加载：包括三个部分（1）通过类的全限定名获取其二进制字节流.class文件（2）通过二进制文件将类的静态存储结构转化为方法区运行时的数据结构（3）生成一个class文件作为该类的访问入口
• 验证：保证字节流文件符合jvm的规范。 文件格式验证。。
• 准备：为静态变量分配内存空间，以及赋初始值。这些内存都将在方法区中进行分配。准备阶段不分配类中的实例变量的内存，实例变量将会在对象实例化时随着对象一起分配在Java堆中。
• 解析：将类中的符号引用转化为直接引用（存储地址）
• 初始化：为静态变量赋正确的初始值，开始执行程序代码。

 

Minor GC和Full GC触发条件总结

GC机制

要准确理解Java的垃圾回收机制，就要从：“什么时候”，“对什么东西”，“做了什么”三个方面来具体分析。

第一：“什么时候”即就是GC触发的条件。GC触发的条件有两种。（1）程序调用System.gc时可以触发；（2）系统自身来决定GC触发的时机。

系统判断GC触发的依据：根据Eden区和From Space区的内存大小来决定。当内存大小不足时，则会启动GC线程并停止应用线程。

第二：“对什么东西”笼统的认为是Java对象并没有错。但是准确来讲，GC操作的对象分为：通过可达性分析法无法搜索到的对象和可以搜索到的对象。对于搜索不到的方法进行标记。

第三：“做了什么”最浅显的理解为释放对象。但是从GC的底层机制可以看出，对于可以搜索到的对象进行复制操作，对于搜索不到的对象，调用finalize()方法进行释放。

具体过程：当GC线程启动时，会通过可达性分析法把Eden区和From Space区的存活对象复制到To Space区，然后把Eden Space和From Space区的对象释放掉。当GC轮训扫描To Space区一定次数后，把依然存活的对象复制到老年代，然后释放To Space区的对象。

对于用可达性分析法搜索不到的对象，GC并不一定会回收该对象。要完全回收一个对象，至少需要经过两次标记的过程。

第一次标记：对于一个没有其他引用的对象，筛选该对象是否有必要执行finalize()方法，如果没有执行必要，则意味可直接回收。（筛选依据：是否复写或执行过finalize()方法；因为finalize方法只能被执行一次）。

第二次标记：如果被筛选判定位有必要执行，则会放入FQueue队列，并自动创建一个低优先级的finalize线程来执行释放操作。如果在一个对象释放前被其他对象引用，则该对象会被移除FQueue队列。、、

 

 

 Minor GC ，Full GC 触发条件

Minor GC触发条件：当Eden区满时，触发Minor GC。

Full GC触发条件：

1、System.gc()方法的调用

 

此方法的调用是建议JVM进行Full GC,虽然只是建议而非一定,但很多情况下它会触发 Full GC,从而增加Full GC的频率,也即增加了间歇性停顿的次数。强烈影响系建议能不使用此方法就别使用，让虚拟机自己去管理它的内存，可通过通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。

2、老年代代空间不足

老年代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误：
java.lang.OutOfMemoryError: Java heap space 
为避免以上两种状况引起的Full GC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

3、永生区空间不足

JVM规范中运行时数据区域中的方法区，在HotSpot虚拟机中又被习惯称为永生代或者永生区，Permanet Generation中存放的为一些class的信息、常量、静态变量等数据，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下也会执行Full GC。如果经过Full GC仍然回收不了，那么JVM会抛出如下错误信息：
java.lang.OutOfMemoryError: PermGen space 
为避免Perm Gen占满造成Full GC现象，可采用的方法为增大Perm Gen空间或转为使用CMS GC。

4、CMS GC时出现promotion failed和concurrent mode failure

对于采用CMS进行老年代GC的程序而言，尤其要注意GC日志中是否有promotion failed和concurrent mode failure两种状况，当这两种状况出现时可能

会触发Full GC。
promotion failed是在进行Minor GC时，survivor space放不下、对象只能放入老年代，而此时老年代也放不下造成的；concurrent mode failure是在

执行CMS GC的过程中同时有对象要放入老年代，而此时老年代空间不足造成的（有时候“空间不足”是CMS GC时当前的浮动垃圾过多导致暂时性的空间不足触发Full GC）。
对措施为：增大survivor space、老年代空间或调低触发并发GC的比率，但在JDK 5.0+、6.0+的版本中有可能会由于JDK的bug29导致CMS在remark完毕

后很久才触发sweeping动作。对于这种状况，可通过设置-XX: CMSMaxAbortablePrecleanTime=5（单位为ms）来避免。

5、统计得到的Minor GC晋升到旧生代的平均大小大于老年代的剩余空间

这是一个较为复杂的触发情况，Hotspot为了避免由于新生代对象晋升到旧生代导致旧生代空间不足的现象，在进行Minor GC时，做了一个判断，如果之

前统计所得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间，那么就直接触发Full GC。
例如程序第一次触发Minor GC后，有6MB的对象晋升到旧生代，那么当下一次Minor GC发生时，首先检查旧生代的剩余空间是否大于6MB，如果小于6MB，

则执行Full GC。
当新生代采用PS GC时，方式稍有不同，PS GC是在Minor GC后也会检查，例如上面的例子中第一次Minor GC后，PS GC会检查此时旧生代的剩余空间是否

大于6MB，如小于，则触发对旧生代的回收。
除了以上4种状况外，对于使用RMI来进行RPC或管理的Sun JDK应用而言，默认情况下会一小时执行一次Full GC。可通过在启动时通过- java -

Dsun.rmi.dgc.client.gcInterval=3600000来设置Full GC执行的间隔时间或通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。

 

6、堆中分配很大的对象

 

所谓大对象，是指需要大量连续内存空间的java对象，例如很长的数组，此种对象会直接进入老年代，而老年代虽然有很大的剩余空间，但是无法找到足够大的连续空间来分配给当前对象，此种情况就会触发JVM进行Full GC。

为了解决这个问题，CMS垃圾收集器提供了一个可配置的参数，即-XX:+UseCMSCompactAtFullCollection开关参数，用于在“享受”完Full GC服务之后额外免费赠送一个碎片整理的过程，内存整理的过程无法并发的，空间碎片问题没有了，但提顿时间不得不变长了，JVM设计者们还提供了另外一个参数 -XX:CMSFullGCsBeforeCompaction,这个参数用于设置在执行多少次不压缩的Full GC后,跟着来一次带压缩的。

阅读更多