JVM-垃圾回收

JVM很重要。尤其是GC算法。

程序计数器、虚拟机栈、本地方法栈。这几个区域完全不用管回收问题，因为方法结束或者线程结束的时候他们所占用的内存就自然跟着一起释放了，3个区域随线程而生，随线程而灭。所以我们只需要管堆和方法区。

1 如何判断垃圾

在 JVM 中，垃圾就是指的死亡对象所占据的堆空间( GC 是发生在堆空间中)，那么我们如果辨别一个对象是否死亡呢？

1.1 引用记数法

介绍：给对象中添加一个引用计数器，每当有一个地方引用他时，计数器值就+1；当引用失效时，计数器值就-1；任何时刻计数器为0的对象就是不可能在被使用。

优点：判定效率很高。

缺点：解决不了循环引用问题。

1.2 可达性分析法

【介绍】

通过一系列的GC Roots的对象作为起始点，从这些根节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。

【gc roots】

主要四种：

• 虚拟机栈引用的对象：各个线程使用的参数与局部变量引用的对象。

• 方法区静态属性引用的对象：静态属性引用的对象。

• 方法区常量引用的对象：比如字符串常量池里引用对象。

• 本地方法栈（JNI）引用的对象：引用的对象。

其他比如：

• 同步锁（synchronized）持有的对象：

• java虚拟机内部引用：比如基本数据类型class对象，常驻的异常对象。

2 四种引用

2.1 简单介绍

• 强引用：直接指向new出来的对象就是强引用，例如 Object obj = new Object()。当JVM的内存空间不足时，宁愿抛出OutOfMemoryError也不会回收强引用的存活着的对象 ！

• 软引用：当JVM认为内存空间不足时，就回去试图回收软引用指向的对象，也就是说在JVM抛出 OutOfMemoryError 之前，会去清理软引用对象。可以与引用队列 (ReferenceQueue) 联合使用，通过 get() 方法获取对象。

• 弱引用：不管内存空间足不足都会回收这个对象，同样也可以配合 ReferenceQueue 使用，通过 get() 方法获取对象。ThreadLocal 中的key就用到了弱引用。

• 虚引用：任何时候可能被GC回收，就像没有引用一样，无法通过get()获取对象，必须配合 ReferenceQueue 使用的。

2.2 使用场景

引用类型	使用场景
强引用	最常用使用方式，存在引用不进行垃圾回收时使用
软引用	一般用来实现内存敏感的缓存，如有空闲内存就保留缓存，当内存不足就清理掉，这样就保证使用缓存的同时不会耗尽内存。
弱引用	同样可以当做缓存使用
虚引用	主要用来跟踪对象被垃圾回收的活动，比如对象被回收后清理堆外内存（网络I/O时数据会在内核缓冲区中有存放，其关联的堆对象回收时通过ReferenceQueue感知到并释放内核缓存区内存）

2.3 ThreadLocal内存泄漏问题

【简单介绍】

ThreadLocal 是线程的本地变量，是线程独有的，不能与其他线程共享，这样就可以避免资源竞争带来的多线程的问题。这种解决多线程的安全问题和lock有本质的区别的:

• lock 的资源是多个线程共享的，ThreadLocal 是每个线程都有一个副本不用加锁。

• lock 是通过时间换空间的做法，ThreadLocal 是典型的通过空间换时间的做法。

【实现方式】

ThreadLocalMap 内部类有一个Entry 类，key是ThreadLocal 对象，value 就是你要存放的值，上面的代码value 存放的就是hello word。ThreadLocalMap 和HashMap的功能类似，但是实现上却有很大的不同：

1. HashMap 是通过链地址法解决hash冲突的问题 VS ThreadLocalMap 是通过开放地址法来解决hash冲突的问题

   1. hreadLocal 往往存放的数据量不会特别大，这个时候开放地址法简单的结构会显得更省空间

   2. 同时数组的查询效率也是非常高

2. HashMap 里面的Entry 内部类的引用都是强引用 VS ThreadLocalMap里面的Entry 内部类中的key 是弱引用value 是强引用

【使用场景】

spring的@transaction注解里connection使用到了

【内存泄漏】

参考文档：http://www.likecs.com/show-108947.html

为什么会出现：ThreadLocal对象会被线程中ThreadLocalMap管理起来，ThreadLocalMap的生命周期跟Thread一样长，整个生命周期不使用的对象一直不回收的话，可能会导致内存泄漏。

JDK应对方式：key为弱引用 + value自动回收机制

• key弱引用：ThreadLocal的引用释放后，ThreadLocalMap上key是弱引用无法阻止ThreadLocal对象正常进行垃圾回收，避免出现内存泄漏。

• value自动回收：每次调用ThreadLocal类的get、set、remove这些方法的时候，都会清理过期的Entry。

key使用弱引用还会出现内存泄漏吗：会，因为value的引用为强引用，且value不一定被自动回收。

3 垃圾回收算法

3.1 标记清除

根据名称就可以理解该算法分为两个阶段：

    a. 标记阶段：标记出所有需要被回收的对象

    b. 清除阶段：回收被标记的对象所占用的空间。

【优点】

• 实现简单

【缺点】

• 产生内存碎片：回收后的区域内存并不是连续的，可能出现大对象找不到合适空间，从而频繁触发垃圾回收。

• 效率不可控：如果大量对象都是垃圾，那么需要逐个清除垃圾对象，导致效率较低。

3.2 标记复制

内存分为大小相同的两个区域，运行区域，预留区域，所有创建的新对象都分配到运行区域，当运行区域内存不够时，将运作区域中存活对象全部复制到预留区域，然后再清空整个运行区域内存，这时两块区域的角色也发生了变化，内存前后的状态参考下图：

【优点】

• 解决了内存碎片：垃圾回收后不会产生内存碎片。

• 执行效率高：新内存的分配只需要移动堆顶指针顺序分配即可。

【缺点】

• 空间浪费：需要预留一半的内存区域，浪费空间。

3.2 标记整理

标记阶段将存活的对象进行标记，在整理阶段将存活的对象向内存空间的一端移动，然后将存活对象边界以外的空间全部清空。

【优点】

• 解决了内存碎片：垃圾回收后不会产生内存碎片。

• 避免了空间浪费：不会想标记复制算法一样浪费存储空间。

【缺点】

• 存活对象多时效率低：当内存中存活对象多，而垃圾对象少时，要移动大量的存活对象才能换取少量的内存空间。

3.4 分代收集算法

这么多GC算法中，每种都有各自的优点和缺点，我们在使用的时候要根据不同的场景使用不同的算法（长生命周期、短生命周期、大对象、小对象），来实现垃圾回收。分代算法其实就是这样的，根据回收对象的特点进行选择，在JVM中年轻代适合使用复制算法，老年代适合使用标记整理算法。

4 JVM内存分代模型

为什么要说JVM的内存分代模型呢，因为内存分代和垃圾回收器的运行是有关系的，现在垃圾回收器除了G1外都是分代的。

在jvm的堆内存中有三个区域：默认情况下，新生代/老年代=1:2，eden/servivor=8:1:1

1. 新生代：用于存放新产生的对象。

2. 老年代：用于存放被长期引用的对象。

3. 永久带：用于存放Class，method元信息（1.8之后改为元空间）。

4.1 新生代

主要是用来存放新生的对象，一般占据堆的1/3空间。由于频繁创建对象，会频繁触发MinorGC进行垃圾回收。

新生代又分为 Eden区、ServivorFrom、ServivorTo三个区。

• Eden区：Java新对象的出生地，当Eden区内存不够的时候就会触发MinorGC，对新生代区进行一次垃圾回收。

• ServivorTo：保留了一次MinorGC过程中的幸存者。

• ServivorFrom：上一次GC的幸存者，作为这一次GC的被扫描者。

问：新生代对象什么时候会放到老年代？

1. 大小判断：大对象直接进入老年代，仅serial、ParNew有该逻辑（且可配置是否开启）

2. 年龄判断：经过多次minor gc依然在survivor区存活，进入老年代（默认15岁）

3. 动态年龄判定：从年龄为1的对象开始累加，大于单survivor区的一半时，记这个年龄及大于该年龄的对象进入老年代

4. 空间判断：minor gc后，survivor区不足以存放存活对象，通过空间分配担保进入老年代

4.2 老年代及元空间

老年代：垃圾回收了很多次都没有把它回收掉的老对象，以及一些大的对象。

永久代与元空间：指内存的永久保存区域，主要存放Class和Meta（元数据）的信息。Class在被加载的时候被放入永久区域，它和存放实例的区域不同，GC不会在主程序运行期对永久区域进行清理。所以这也导致了永久代的区域会随着加载的Class的增多而胀满，最终抛出OOM异常。在Java8中，永久代已经被移除，被一个称为“元数据区”（元空间）的区域所取代。

• 元空间的本质和永久代类似：都是对JVM规范中方法区的实现。

• 元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。

5 垃圾收集器

衡量垃圾收集器的三项最重要的指标是：内存占用（Footprint）、吞吐量（Throughput）和延迟（Latency），三者共同构成了一个“不可能三角”。

5.1 Serial / Serial Old收集器

Serial是一个单线程的新生代收集器，采用复制算法。Serial Old是一个单线程的老年代收集器，采用标记-整理算法。

• 优点：简单高效，没有线程切换带来的开销；

• 缺点：进行垃圾收集时，必须暂停所有工作线程直到完成，停顿时间长；多核情况下无法充分使用资源。

• 使用场景：适合内存不大的情况；单核服务器；

5.2 ParNew/Serial Old

ParNew收集器起始就是Serial收集器的多线程版，是一个新生代收集器，采用复制算法。

• 优点：多核情况下，效率比Serial收集高

• 缺点：进行垃圾收集时，必须暂停所有工作线程直到完成，停顿时间长

• 使用场景：多核服务器

5.3 Parallel Scavenge/Parallel Old

Parallel 是一种以获取最高吞吐量为目标的收集器，吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间）。在系统吞吐量上有很大的优化，可以更高效利用CPU完成垃圾回收任务。Parallel Scavenge收集器是一个新生代的并行收集器，使用复制算法。Parallel Old收集器是一个老年代的并行收集器，使用标记-整理算法。

• 优点：吞吐量高，多核情况下能充分利用资源

• 缺点：进行垃圾收集时，必须暂停所有工作线程，直到完成，停顿时间长

• 使用场景：追求高吞吐量的服务，如：批处理等后台任务

5.4 CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的老年代收集器，使用标记-清除算法。

CMS 收集器主要包含4个阶段：

• 初始标记（CMS initial mark）：仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，需要停顿用户线程。

• 并发标记（CMS concurrent mark）：就是进行GC Roots Tracing的过程，不需要停顿用户线程。

• 重新标记（CMS remark）：修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，需要停顿用户线程，停顿时间比初始标记稍长，比并发标记短很多。

• 并发清除（CMS concurrent sweep）：清除垃圾对象。

• 优点：并发收集、清理低停顿

• 缺点：内存碎片多，导致应用程序变慢；浮动垃圾问题；

• 使用场景：适用于用户交互类的服务

【内存碎片问题】

CMS使用的是标记—清除算法来实现的，所以就存在内存碎片的问题。当空间碎片过多，内存分配速度变慢，同时可能导致无法分配大对象，这时不得不提前触发一次Full GC。

【为什么不能使用标记整理算法】

清理阶段是并发清理，其他线程还在运行，如果进行内存整理的话会影响用户线程的指向的对象信息。

5.5 G1收集器

关键词：追求停顿时间、Region分区、筛选回收、复制和整理算法

G1（Garbage-First）是一款同时适用于新生代和老年代的收集器，他采用了另外一种完全不同的方式组织堆内存，堆内存被划分为多个大小相等的内存块（Region），每个Region是逻辑连续的一段内存。每个Region被标记了E、S、O和H四种角色，其中H代表Humongous，这表示这些Region存储的是巨型对象，当新建对象大小超过Region大小一半时，直接在新的一个或多个连续Region中分配，并标记为H。

与CMS相比，其优点如下：

• G1在GC过程中会进行整理内存，不会产生很多内存碎片

• G1的STW更可控，可以指定可期望的GC停顿时间

采用算法：G1从整体来看是基于标记-整理算法实现的收集器，从局部（两个Region之间）上来看是基于复制算法实现的。

三种gc：

• Young GC：选定所有年轻代里的Region。通过控制年轻代的region个数，即年轻代内存大小，来控制young GC的时间开销，标记复制算法。

•  Mixed GC：回收所有年轻代里的Region，外加根据策略统计得出收集收益高的若干老年代Region（在用户指定的开销目标范围内条件判断）。 

• full gc：如果对象内存分配速度过快，mixed gc来不及回收，导致老年代被填满，就会触发一次full gc，G1的full gc算法就是单线程执行的serial old gc，会导致异常长时间的暂停时间，需要尽可能的避免full gc.

整体流程：

• 初始标记（Initial Marking）：完成标记GC ROOTS 直接可达的对象，需要停顿用户线程(STW)，耗时很短。

• 并发标记（Concurrent Marking）：从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，可与用户程序并发执行。当对象图扫描完成以后，还要重新处理SATB记录下的在并发时有引用变动的对象。

• 最终标记（Final Marking）：用于处理并发阶段结束后仍遗留下来的最后那少量的SATB记录，这阶段需要停顿用户线程(STW)，但是可并行执行。

• 筛选回收（Live Data Counting and Evacuation）：对Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来生成回收计划，然后将存活对象放到空闲Region中，在清理掉所有的旧Region，这阶段因为需要移动对象，所以会造成停顿用户线程(STW)。

6 JVM调优

6.1 什么时候需要调优

• Full GC 次数频繁；比如每天进行full gc甚至多次full gc

• GC 停顿时间过长（超过1秒）；

• 应用出现OutOfMemory 等内存异常；

6.2 调优思路

• 选择合适垃圾收集器：追求高吞吐量可选择Parallel相关收集器，追求短停顿时间可选择CMS和G1

• 避免频繁full gc：即避免周期短的对象进入老年代，因为full gc成本高耗时长，方式有

  • 年龄判断着手：合理设置进入老年代的年龄，比如默认是15岁，可根据实际情况调整

  • 大小判断着手：对于serail和parnew收集器可设置大对象直接进入老年代，但这是有风险的，可能导致频繁full gc。所以Parallel相关、CMS、G1都不支持该策略

  • 动态年龄与空间判断着手：合理设置新生代大小与eden/Servivor区比例

• 调整gc的频次：调整堆空间与新生代、老年代大小

• 避免内存泄漏：比如ThreadLocal可能导致内存泄漏

6.3 调优步骤

现状分析->指定目标->初步确认调优参数->压测与调整->确认最终参数

Question

1. GC roots有哪些？讲讲可达性分析算法

2. 多大对象会被扔到老年代？答：这种策略只针对serail和parNew算法，且默认是不会使用该策略，需要进行手动参数配置

3. 吞吐量优先和响应优先的垃圾回收器有那些？答：吞吐量优先的有Parallel相关，响应优先的有CMS、G1

4. CMS流程及缺点？答：四个环节，内存碎片与浮动垃圾