Jvm垃圾回收及内存分配

垃圾回收

垃圾回收

概述

Java里面垃圾收集通常被我们成为GC，Java虚拟机中：程序计数器，虚拟机栈，本地方法栈随着线程而生，随线程而灭，栈中的栈帧会随着方法的进入和退出，进行入栈和出栈的操作，会自动清理内存，所以垃圾回收主要针对的是 jvm中的堆内存和方法区

判断对象的存活

判断对象的存活有两种方法
1.引用计数器：给对象添加一个计数器，当一个地方引用他时计数器值+1，引用失效时计数器-1，当计数器为0时就可以回收特点：简单高效
2.可达性分析算法：把称为"GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径被称为引用链，当一个对象没有任何引用链相连的时候，说明对象是不可用的（相当于一颗多叉树，GC Roots是根目录，依次遍历他的每一层节点，没有被关联到的都是没有用的对象）
GC Roots对象包括下面几种：

虚拟机栈（栈帧中的本地变量表）中引用的对象
方法区中类静态属性引用的对象
方法区中常量引用的对象
本地方法栈中JNI（native方法）引用的对象

Java内置对象引用工具

1、强引用（Strong Reference）：只要强引用存在，GC不会回收，甚至OOM也在所不惜
2、软引用（Soft Reference）：在系统将要发生溢出之前才回收
3、弱引用（Weak Reference）：只能生存到下一次GC回收之前
4、虚引用（Phantom Reference）：仅仅是理论上存在，唯一的目的就是能在这个对象没收集器回收时收到一个通知

Java回收流程

即使在可达性分析算法中为不可达，也并非是“非死不可”，这时候它们暂时处于“缓刑”阶段，想要宣告一个对象死亡，至少要经过两次标记过程：
- 第一次标记：对象没有与GC Roots相连接的引用链，且finalize()方法被重写且没有被虚拟机调用过，将会被第一次标记，且放到F-Queue的队列之中，虚拟机会自动启动一个低优先级的Finalizer线程去执行对象finalize()方法。
- 第二次标记：finalize()方法将会是对象逃脱死亡的最后一次机会，GC将对F-Queue中的对象进行第二次小规模标记，如果对象依然没有GC Roots相连接的引用链，那么对象直接被回收。
回收方法区（永久代）主要回收废弃常量和无用的类，满足一下三个条件
- 该类的所有实例都已经被回收，也就是Java堆中不存在该类的任何实例
- 加载该类的ClassLoader北京北回收
- 该类对应的java.lang.Class对象没有被任何地方引用，无法在任何地方通过反射访问该类的方法

.垃圾回收算法

1.标记-清除算法

“标记-清除”算法是最基础的收集算法，算法分为“标记”和“清除”两个阶段：首先标记处所有需要回收的对象，在标记完成后统一回收
“标记-清除”算法主有两个缺点：1、效率问题，标记和清除两个过程的效率都不高。2、空间问题，标记清除之后会产生大量的不连续的内存碎片，空间碎片过多，会导致程序在运行时需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾回收动作。

2.复制算法

主要思想是把可用内存划分为大小相等的两块，每次只是用其中的一块，当这一块用完之后，就把存活的对象复制到另一块上面，然后再把已使用过的内存块一次清理掉，这样是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片的情况，实现简单，运行高效
缺点：复制算法把内存缩小为原来的一半，代价较高。

3.标记-整理算法
复制收集算法在对象存活率较高时就要执行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。
复制收集算法在对象存活率较高时就要执行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。

4.分代收集算法

根据对象的存活周期的不同把内存分为几块，一般是把堆分为新生代和老年代，这样可以根据各个年代的特点采用最适当的收集算法，在新生代中，每次垃圾收集时会有大批对象死去，少量存活，就选用复制算法，在老年代中，对象存活率高，没有额外空间进行分配担保，就必须使用“标记-清理”或者“标记-整理”算法进行回收

HotSpot的算法实现

GC停顿（Stop The Word）：暂停所有Java执行线程，进行可达性分析工作。之所以需要暂停所有Java运行线程，是因为需要保证在GC过程中，不能出现对象引用关系变化，保证分析结果的准确性。
枚举根节点:将GC Roots的节点保存在OopMap中，在GC时不用重新遍历（可能耗时）GC Roots 根节点，而是直接通过OopMap获取。不是每条指令都生成OopMap，只是在特定的位置记录。可作为GCRoots的节点主要在全局性的引用（如常量和类静态属性）与执行上下文（例如栈帧中的本地变量表），在类加载完成的时候，虚拟机就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会特定的记录下栈和寄存器中哪些位置是引用。
安全点：并不是每条指令都生成OopMap，只是在特定的的位置记录这些信息，这些位置称为安全点，既程序执行时并非在所有的地方都停顿下来开始GC，只在到达安全点的时候才能暂停
- 安全点的两种方案抢先式中断：发生GC时先把所有线程全部中断掉，如果发现线程中断的地方不在安全点上，就恢复线程让他跑到安全点上
- 主动式中断：当GC需要中断线程的时候，不直接对线程进行操作，仅仅简单设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起
- 安全点特征位置：方法调用，循环跳转，异常跳转，
安全区域：安全区域是指在一段代码中，引用关系不会发生变化，在这个区域中的任意地方GC都是安全的。主要针对处于Sleep状态和Blocked状态的线程，当线程离开安全区域时，它需要检查系统是否已经完成了根节点枚举（或者整个GC过程），如果GC没完成，则需要等待直到收到可以离开安全区域为止。

垃圾收集器

Serial收集器
- 单线程收集器，最基本的收集器，当他在进行垃圾回收时，必须暂停其他所有的工作线程，直到他收集结束
- 应用场景：虚拟机运行在Client模式下的默认的新生代收集器。
- 原因：简单而高效，没有线程交互的开销，可以获得最高的单线程效率。用户桌面应用场景中，分配给虚拟机管理的内存（新生代）一般只有几十兆到一两百兆。客户端的停顿时间控制在几十毫秒最多一百毫秒内，只要不是频繁发生，这点停顿是可以接受的。

ParNew收集器
- ParNew收集器是Serial收集器的多线程版本，其余行为和Serial一样
- 应用场景：Server模式下首选的新生代收集器，一个与性能无关但重要的原因是，除了Serial，只有他能与GMS收集器配合工作
Parallel Scavenger收集器
- 新生代收集器，使用复制算法，它的特点和关注点是吞吐量吞吐量=用户运行代码时间/(运行用户代码时间+垃圾收集时间)
- 特点：它可以达到一个可控制的吞吐量，吞吐量即cpu用于运行用户代码时间与cpu总消耗时间的比值
- 应用场景：适合在后台运算而不需要太多交互的任务
- Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，-XX:MaxGCPauseMillis参数控制最大垃圾收集停顿时间，-XX:GCTimeRatio参数直接设置吞吐量大小。参数-XX:+UseAdaptiveSizePolicy是一个开关参数，当这个参数打开后，就不需要手工指定新生代的大小、Eden和Survivor的比例、晋升老年代对象的大小等细节参数，虚拟机会根据当前系统的运行情况收集性能监控信息，动态地调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略。GC自适应的调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。
Serial Old收集器
- Serial Old收集器是Serial收集器的老年代版本，同样是一个单线程收集器，使用“标记-整理”算法
- 应用场景：Client模式下的虚拟机。如果使用在Server模式下，那它主要还有两大用途途：1.JDk1.5及之前的版本中与Parallel Scavenge收集器搭配使用，2.作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。
Parallel Old收集器
- Parallel Scavenger收集器的老年代版本使用多线程和“标记-整理”算法
GMS收集器
- CMS收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的JAVA应用集中在互联网网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望停顿越短越好，以给用户带来较好的用户体验。CMS收集器就非常符合这类的应用需求。
- CMS（concurrent Mark Sweep）是基于“标记--清除”算法实现的，它的运作过程分为四个步骤：
- 1.初始标记仅仅标记一下GC Roots能直接关联到的对象，速度很快
- 2.并发标记进行GC RootsTracing的过程
- 3.重新标记为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。此阶段的停顿时间比初始标记阶段长比并发标记短。
- 4.并发清除
- 初始标记和重新标记仍然需要StopTheWorld但是并发标记和并发清除过程可以和用户线程一起工作，总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
- 缺点：1.CMS收集器对CPU资源非常敏感2.CMS收集器无法处理浮动垃圾，可能出现cconcurrent Mode Failure而导致另一次Full GC的产生 3.产生大量的空间碎片
G1收集器
- 并行与并发：充分利用多核环境减少停顿时间，
- 分代收集：不需要配合其它收集器
- 空间整合：整体上看属于标记整理算法，局部（region之间）数据复制算法，运作期间不会产生空间碎片
- 停顿可预测，建立可以预测的停顿时间模型。
- 内存管理：
  - 将整个java堆划分为多个大小形同的区域region，新生代和老年代都是region的集合。可以有计划的避免在全区域内进行垃圾收集。
  - 回收方式：跟踪每一个region里面的垃圾堆积的价值大小（回收所得的空间大小以及所需耗费时间的经验值），维护一个优先列表，每次根据允许的回收时间，优先回收价值最大的region（GI名字由来）
  - region之间的引用，新生代和老年带之间的引用根据remebered set来避免全盘扫描，每一个region都维护一个remebered set，
  - 初始标记->并发标记->最终标记->筛选回收

垃圾回收的几种类型

从年轻代空间回收内存被称为 Minor GC，有时候也称之为 Young GC。
- 当 JVM 无法为一个新的对象分配空间时会触发 Minor GC，比如当 Eden 区满了。所以 Eden 区越小，越频繁执行 Minor GC。
- 当年轻代中的 Eden 区分配满的时候，年轻代中的部分对象会晋升到老年代，所以 Minor GC 后老年代的占用量通常会有所升高。
- \质疑常规的认知，所有的MinorGC都会触发Stop-The-World，停止应用程序的线程。对于大部分应用程序，停顿导致的延迟都是可以忽略不计的，因为大部分 Eden 区中的对象都能被认为是垃圾，永远也不会被复制到Survivor区或者老年代空间。如果情况相反，即Eden区大部分新生对象不符合GC条件（即他们不被垃圾回收器收集），那么 Minor GC 执行时暂停的时间将会长很多（因为他们要JVM要将他们复制到 Survivor 区或老年代）。
从老年代空间回收内存被称为 Major GC，有时候也称之为 Old GC。
- 许多 Major GC 是由 Minor GC 触发的，所以很多情况下将这两种 GC 分离是不太可能的。
- Minor GC作用于年轻代，MajorGC作用于老年代。分配对象内存时发现内存不够，触发MinorGC。MinorGC会将对象移到老年代中，如果此时老年代空间不够，那么触发 Major GC。因此才会说，许多 Major GC 是由 Minor GC 引起的。
Full GC 是清理整个堆空间 —— 包括年轻代、老年代和永久代（如果有的话）。因此 Full GC 可以说是 Minor GC 和 Major GC 的结合。
- 当准备要触发一次 Minor GC 时，如果发现年轻代的剩余空间比以往晋升的空间小，则不会触发 Minor GC 而是转为触发 Full GC。因为JVM此时认为：之前这么大空间的时候已经发生对象晋升了，那现在剩余空间更小了，那么很大概率上也会发生对象晋升。既然如此，那么我就直接帮你把事情给做了吧，直接来一次 Full GC，整理一下老年代和年轻代的空间。另外，即在永久代分配空间但已经没有足够空间时，也会触发 Full GC。

内存分配

对象优先在Eden分配，当没有足够空间分配时将进行一次Minor GC
大对象直接进入老年代 -XX：PretenureSizeThreshold 参数进行设置，大于这个设置值的对象直接在老年代分配
长期存活的对象将进入老年代虚拟机给每一个对象定义一个对象年龄计数器，如果对象在Eden出生并经历过第一次Minor GC依然存活且能被Survivor容纳将被移动到Survivor空间，将年龄设置为1 然后每熬过一次MinorGc 年龄+1 到相应的年龄后进入老年代通过-XX：MaxTenuringThreshold设置阈值
动态对象年龄判断如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于改年龄的对象可以直接进入老年代