深入理解JAVA虚拟机之JVM内存以及垃圾回收
JVM相关知识点
JVM内存
【方法区】 【虚拟机栈】 【本地方法栈】
【堆 heap】 【程序计数器】
【执行引擎】 【本地库接口】 【本地方法】
NIO 会使用操作系统的直接内存 通过 DirectByteBuffer 引用进行操作减少 内存和堆的复制
堆内存
【eden+from s0+ to s1】 【old generation】 【方法区 Permanent Generation】
【新生代】 【老年代】 【永久代】
(方法区:虚拟机加载的类的元数据信息：如常量、静态变量、即时编译器编译后的代码)
(hotspot 用永久代实现方法区，不过在jdk1.7也移除常量池。使用native memmory做方法区）
垃圾收集器和内存分配策略
哪些内存需要回收？
什么时候回收？
如何回收？
引用计数法
给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；
当引用失效时，计数器值就减1任何时刻计数器为0的对象就是不可能再被使用的。
存在问题：
主流的Java虚拟机里面没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间相互循环引用的问题。
可达性分析法
这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索
，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连
（用图论的话来说，就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的 。
GC Roots对象：
- 虚拟机栈（栈帧中的本地变量表）中引用的对象。
- 方法区中类静态属性引用的对象。
- 方法区中常量引用的对象。
- 本地方法栈中JNI（即一般说的Native方法）引用的对象。
对象销毁：
至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots
相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对
象是否有必要执行finalize（）方法
如果这个对象被判定为有必要执行finalize（）方法，那么这个对象将会放置在一个叫做
F-Queue的队列之中，并在稍后由一个由虚拟机自动建立的、 低优先级的Finalizer线程去执行
它。 这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束
一个对象的finalize（）方法只会执行一次
回收方法区 老年代GC
在方法区中进行垃圾收集的“性价比”一般比较低：在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收70%～95%的空间，而永久代的垃圾收集效率远低于此。
永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类
无用的类：
1. 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例
2. 加载该类的ClassLoader已经被回收
3. 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该
类的方法
**在大量使用反射、 动态代理、 CGLib等ByteCode框架、 动态生成JSP以及OSGi这类频繁**
**自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出**
垃圾收集算法
1.标记-清楚算法
如同它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象
缺点
一个是效率问题，标记和清除两个过程的效率都不高；另一个是
空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程
序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾
收集动作
2.复制算法
它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。 当这一块的内存用完了，就将还存
活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。 这样使得每次都是对整个半区进行内存回收
缺点
只是这种算法的代价是将内存缩小为了原来的一半，未免太高了一点。现在的商业虚拟机都采用这种收集算法来回收新生代
并不需要按照1:1的比例来划分内存空间，HotSpot虚拟机默认Eden和Survivor的大小比例是
8:1，也就是每次新生代中可用内存空间为整个新生代容量的90%
【Eden】【survivor1】【survivor2】
**当Survivor空间不够用时，需要依赖其他内存（这里
指老年代）进行分配担保（Handle Promotion）。**
3.标记-整理算法
标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存
活的对象都向一端移动，然后直接清理掉端边界以外的内存
适合老年代的GC收集
4.分代收集算法
当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，这种算
法并没有什么新的思想，只是根据对象存活周期的不同将内存划分为几块。 一般是把Java堆
分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。 在新生代
中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付
出少量存活对象的复制成本就可以完成收集。 而老年代中因为对象存活率高、 没有额外空间
对它进行分配担保，就必须使用“标记—清理”或者“标记—整理”算法来进行回收。
HotSpot算法实现
GC Roots 枚举根节点
OopMap数据结构：
并不需要一个不漏地检查完所有
执行上下文和全局的引用位置，虚拟机应当是有办法直接得知哪些地方存放着对象引用
安全点：
实际上，HotSpot也的确没有为每条指令都生成OopMap，前面已经提到，只是在“特定的
位置”记录了这些信息，这些位置称为安全点（Safepoint），即程序执行时并非在所有地方都
能停顿下来开始GC，只有在到达安全点时才能暂停。
主动式中断的思想是当GC需要中断线程的时候，不直接对线程操作，仅仅简单地设
置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。
轮询标志的地方和安全点是重合的，另外再加上创建对象需要分配内存的地方。
垃圾收集器
1.Serial收集器
这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集
程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。
2.ParNew收集器
ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之
外，其余行为包括Serial收集器可用的所有控制参数（例如：-XX：SurvivorRatio、 -XX：
PretenureSizeThreshold、 -XX：HandlePromotionFailure等）、 收集算法、 Stop The World、 对
象分配规则、 回收策略等都与Serial收集器完全一样，在实现上，这两种收集器也共用了相
当多的代码
3.Parallel Scavenge收集器
Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行
的多线程收集器
Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点
是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到
一个可控制的吞吐量（Throughput）。 所谓吞吐量就是CPU用于运行用户代码的时间与CPU总
消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚
拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。
停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高
吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不
需要太多交互的任务。
4.Serial Old收集器
Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整
理”算法。 这个收集器的主要意义也是在于给Client模式下的虚拟机使用。 如果在Server模式
下，那么它主要还有两大用途：一种用途是在JDK 1.5以及之前的版本中与Parallel Scavenge
收集器搭配使用[1]，另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent
Mode Failure时使用。
5.Parallel Old收集器
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。
这个收集器是在JDK 1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直
处于比较尴尬的状态。 原因是，如果新生代选择了Parallel Scavenge收集器，老年代除了
Serial Old（PS MarkSweep）收集器外别无选择（还记得上面说过Parallel Scavenge收集器无
法与CMS收集器配合工作吗？）。 由于老年代Serial Old收集器在服务端应用性能上的“拖
累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，由于
单线程的老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较
高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合“给力”。
6.CMS 收集器
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集
器。 目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重
视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。 CMS收集器就非常
符合这类应用的需求。
从名字（包含“Mark Sweep”）上就可以看出，CMS收集器是基于“标记—清除”算法实现
的，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为4个步骤，包括：
初始标记（CMS initial mark）
并发标记（CMS concurrent mark）
重新标记（CMS remark）
并发清除（CMS concurrent sweep）
7.G1收集器 （jdk1.7）
G1（Garbage-First）收集器是当今收集器技术发展的最前沿成果之一，早在JDK 1.7刚刚
确立项目目标，Sun公司给出的JDK 1.7 RoadMap里面，它就被视为JDK 1.7中HotSpot虚拟机
的一个重要进化特征。 从JDK 6u14中开始就有Early Access版本的G1收集器供开发人员实
验、 试用，由此开始G1收集器的“Experimental”状态持续了数年时间，直至JDK 7u4，Sun公
司才认为它达到足够成熟的商用程度，移除了“Experimental”的标识。
G1是一款面向服务端应用的垃圾收集器。 HotSpot开发团队赋予它的使命是（在比较长
期的）未来可以替换掉JDK 1.5中发布的CMS收集器。 与其他GC收集器相比，G1具备如下特
点。
并行与并发：G1能充分利用多CPU、 多核环境下的硬件优势，使用多个CPU（CPU或者
CPU核心）来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的
GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
分代收集：与其他收集器一样，分代概念在G1中依然得以保留。 虽然G1可以不需要其
他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已
经存活了一段时间、 熬过多次GC的旧对象以获取更好的收集效果。
空间整合：与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实
现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，但无论如何，这
两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。 这种
特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一
次GC。
可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关
注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一
个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实
时Java（RTSJ）的垃圾收集器的特征了。
在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这
样。 使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分
为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和
老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。
G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java
堆中进行全区域的垃圾收集。 G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的
空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时
间，优先回收价值最大的Region（这也就是Garbage-First名称的来由）。 这种使用Region划分
内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高
的收集效率。
Minor GC、Major GC和Full GC之间的区别
Full GC
- System.gc()方法的调用
此方法的调用是建议JVM进行Full GC,虽然只是建议而非一定,但很多情况下它会触发 Full GC,从而增加Full GC的频率,也即增加了间歇性停顿的次数。强烈影响系建议能不使用此方法就别使用，让虚拟机自己去管理它的内存，可通过通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。 - 老年代代空间不足
老年代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误：
Java.lang.OutOfMemoryError: Java heap space
为避免以上两种状况引起的Full GC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。 - 永生区空间不足
VM规范中运行时数据区域中的方法区，在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。 - 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）来避免。 - 统计得到的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。 - 堆中分配很大的对象
所谓大对象，是指需要大量连续内存空间的java对象，例如很长的数组，此种对象会直接进入老年代，而老年代虽然有很大的剩余空间，但是无法找到足够大的连续空间来分配给当前对象，此种情况就会触发JVM进行Full GC。
为了解决这个问题，CMS垃圾收集器提供了一个可配置的参数，即-XX:+UseCMSCompactAtFullCollection开关参数，用于在“享受”完Full GC服务之后额外免费赠送一个碎片整理的过程，内存整理的过程无法并发的，空间碎片问题没有了，但提顿时间不得不变长了，JVM设计者们还提供了另外一个参数 -XX:CMSFullGCsBeforeCompaction,这个参数用于设置在执行多少次不压缩的Full GC后,跟着来一次带压缩的。
扫一扫
157
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
