黑马程序员jvm笔记（三）--垃圾回收部分心得

8.垃圾回收

8.1.如何判断对象可以垃圾回收？

有两种判断类是不是垃圾的办法 分别是 引用计数法和可达性分析。

引用计数法

引用计数法有个弊端，循环引用时，两个对象的计数都为1，导致两个对象都无法被释放

例如老师视频里举的例子：

A对象引用了B对象，同时B对象引用了A对象，导致了循环引用。

可达性分析（jvm使用）

• JVM中的垃圾回收器通过可达性分析来探索所有存活的对象
• 扫描堆中的对象，看能否沿着GC Roott对象为起点的引用链找到该对象，如果找不到，则表示可以回收

可达性分析测试方法：使用jmap工具

将这个快照文件放到eslipce的Memory Analysis里进行解析，得到

可以作为GC Root的对象

• 虚拟机栈（栈帧中的本地变量表）中引用的对象。
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• 本地方法栈中JNI（即一般说的Native方法）引用的对象

8.2.五种引用

强引用

只有GC Root都不引用该对象时，才会回收强引用对象

• 如上图B、C对象都不引用A1对象时，A1对象才会被回收

软引用

当GC Root指向软引用对象时，在内存不足时，会回收软引用所引用的对象

• 如上图如果B对象不再引用A2对象且内存不足时，软引用所引用的A2对象就会被回收

弱引用

只有弱引用引用该对象时，在垃圾回收时，无论内存是否充足，都会回收弱引用所引用的对象

• 如上图如果B对象不再引用A3对象，则A3对象会被回收

弱引用的使用和软引用类似，只是将 SoftReference 换为了 WeakReference

虚引用

当虚引用对象所引用的对象被回收以后，虚引用对象就会被放入引用队列中，调用虚引用的方法

• 虚引用的一个体现是释放直接内存所分配的内存，当引用的对象ByteBuffer被垃圾回收以后，虚引用对象Cleaner就会被放入引用队列中，然后调用Cleaner的clean方法来释放直接内存
• 如上图，B对象不再引用ByteBuffer对象，ByteBuffer就会被回收。但是直接内存中的内存还未被回收。这时需要将虚引用对象Cleaner放入引用队列中，然后调用它的clean方法来释放直接内存

终结器引用

所有的类都继承自Object类，Object类有一个finalize方法。当某个对象不再被其他的对象所引用时，会先将终结器引用对象放入引用队列中，然后根据终结器引用对象找到它所引用的对象，然后调用该对象的finalize方法。调用以后，该对象就可以被垃圾回收了

• 如上图，B对象不再引用A4对象。这是终结器对象就会被放入引用队列中，引用队列会根据它，找到它所引用的对象。然后调用被引用对象的finalize方法。调用以后，该对象就可以被垃圾回收了
• 终结器引用有可能造成终结器对象指向的对象迟迟不被回收，因为该对象只有finallize方法被调用，才会被回收，而调用fianlly对象的线程优先度很低，不建议使用。

附加：引用队列

• 软引用和弱引用可以配合引用队列
  • 在弱引用和虚引用所引用的对象被回收以后，会将这些引用放入引用队列中，方便一起回收这些软/弱引用对象
• 虚引用和终结器引用必须配合引用队列
  • 虚引用和终结器引用在使用时会关联一个引用队列

软引用和弱引用的用处

我们看一个例子：

结果：堆内存溢出

因为用的是强引用对象，此时5个4m的对象会将内存填满，导致内存溢出 gc无法将其回收。

此时我们要使用软引用对象或者弱引用对象，让GC清理时清理掉之前的软引用和弱引用指向的对象，防止内存溢出。

软引用处理

可以看到 前四个元素都被清除，就剩下最后一个元素。

相关代码：

public class Demo1 {
	public static void main(String[] args) {
		final int _4M = 4*1024*1024;
		//使用软引用对象 list和SoftReference是强引用，而SoftReference和byte数组则是软引用
		List<SoftReference<byte[]>> list = new ArrayList<>();
		SoftReference<byte[]> ref= new SoftReference<>(new byte[_4M]);
	}
}

弱引用处理

道理和软引用基本相似。

而上面的两种处理后，即使软引用对象的指向对象被删除，软引用对象本身的内存没被释放，我们需要引用队列来清除它。

相关代码：

public class Demo1 {
	public static void main(String[] args) {
		final int _4M = 4*1024*1024;
		//使用引用队列，用于移除引用为空的软引用对象
		ReferenceQueue<byte[]> queue = new ReferenceQueue<>();
		//使用软引用对象 list和SoftReference是强引用，而SoftReference和byte数组则是软引用
		List<SoftReference<byte[]>> list = new ArrayList<>();
		SoftReference<byte[]> ref= new SoftReference<>(new byte[_4M]);

		//遍历引用队列，如果有元素，则移除
		Reference<? extends byte[]> poll = queue.poll();
		while(poll != null) {
			//引用队列不为空，则从集合中移除该元素
			list.remove(poll);
			//移动到引用队列中的下一个元素
			poll = queue.poll();
		}
	}
}

8.3.垃圾回收算法

标记-清除法

定义：标记清除算法顾名思义，是指在虚拟机执行垃圾回收的过程中，先采用标记算法确定可回收对象，然后垃圾收集器根据标识清除相应的内容，给堆内存腾出相应的空间

标记-整理法

复制法

复制算法过程

8.4分代回收

jvm将堆内存分为新生代和老年代 ，新生代的幸存区用的是复制算法，老年代用的是标记-整理算法

详细过程为：

8.5.GC分析

大对象处理策略

当遇到一个较大的对象时，就算新生代的伊甸园为空，也无法容纳该对象时，会将该对象直接晋升为老年代

线程内存溢出

某个线程的内存溢出了而抛异常（out of memory），不会让其他的线程结束运行

这是因为当一个线程抛出OOM异常后，它所占据的内存资源会全部被释放掉，从而不会影响其他线程的运行，进程依然正常

附录:垃圾回收相关参数

含义                                      参数
堆初始大小                 -Xms
堆最大大小                -Xmx 或 -XX:MaxHeapSize=size
新生代大小                -Xmn 或 (-XX:NewSize=size + -XX:MaxNewSize=size )
幸存区比例            （动态） -XX:InitialSurvivorRatio=ratio 和 -XX:+UseAdaptiveSizePolicy
幸存区比例                -XX:SurvivorRatio=ratio
晋升阈值                  -XX:MaxTenuringThreshold=threshold
晋升详情                  -XX:+PrintTenuringDistribution
GC详情                   -XX:+PrintGCDetails -verbose:gc
FullGC前MinorGC          -XX:+ScavengeBeforeFullGC

8.6.垃圾回收器

并行收集：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。

并发收集：指用户线程与垃圾收集线程同时工作（不一定是并行的可能会交替执行）。用户程序在继续运行，而垃圾收集程序运行在另一个CPU上

吞吐量：即CPU用于运行用户代码的时间与CPU总消耗时间的比值（吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 )），也就是。例如：虚拟机共运行100分钟，垃圾收集器花掉1分钟，那么吞吐量就是99%

8.6.1.串行

• 单线程
• 内存较小，个人电脑（CPU核数较少）

安全点：让其他线程都在这个点停下来，以免垃圾回收时移动对象地址，使得其他线程找不到被移动的对象

因为是串行的，所以只有一个垃圾回收线程。且在该线程执行回收工作时，其他线程进入阻塞状态

Serial 收集器

Serial收集器是最基本的、发展历史最悠久的收集器

特点：单线程、简单高效（与其他收集器的单线程相比），采用复制算法。对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程手机效率。收集器进行垃圾回收时，必须暂停其他所有的工作线程，直到它结束（Stop The World）

ParNew 收集器

ParNew收集器其实就是Serial收集器的多线程版本

特点：多线程、ParNew收集器默认开启的收集线程数与CPU的数量相同，在CPU非常多的环境中，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。和Serial收集器一样存在Stop The World问题

Serial Old 收集器

Serial Old是Serial收集器的老年代版本

特点：同样是单线程收集器，采用标记-整理算法

8.6.2.吞吐量优先

• 多线程
• 堆内存较大，多核CPU
• 单位时间内，STW（stop the world，停掉其他所有工作线程）时间最短
• JDK1.8默认使用的垃圾回收器

Parallel Scavenge 收集器

与吞吐量关系密切，故也称为吞吐量优先收集器

特点：属于新生代收集器也是采用复制算法的收集器（用到了新生代的幸存区），又是并行的多线程收集器（与ParNew收集器类似）

该收集器的目标是达到一个可控制的吞吐量。还有一个值得关注的点是：GC自适应调节策略（与ParNew收集器最重要的一个区别）

GC自适应调节策略：Parallel Scavenge收集器可设置-XX:+UseAdptiveSizePolicy参数。当开关打开时不需要手动指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRation）、晋升老年代的对象年龄（-XX:PretenureSizeThreshold）等，虚拟机会根据系统的运行状况收集性能监控信息，动态设置这些参数以提供最优的停顿时间和最高的吞吐量，这种调节方式称为GC的自适应调节策略。

Parallel Scavenge收集器使用两个参数控制吞吐量：

• XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间
• XX:GCRatio 直接设置吞吐量的大小

Parallel Old 收集器

是Parallel Scavenge收集器的老年代版本

特点：多线程，采用标记-整理算法（老年代没有幸存区）

8.6.3.响应时间优先

• 多线程
• 堆内存较大，多核CPU
• 尽可能让单次STW时间变短（尽量不影响其他线程运行）

CMS 收集器

Concurrent Mark Sweep，一种以获取最短回收停顿时间为目标的老年代收集器

特点：基于标记-清除算法实现。并发收集、低停顿，但是会产生内存碎片

应用场景：适用于注重服务的响应速度，希望系统停顿时间最短，给用户带来更好的体验等场景下。如web程序、b/s服务

CMS收集器的运行过程分为下列4步：

初始标记：标记GC Roots能直接到的对象。速度很快但是仍存在Stop The World问题

并发标记：进行GC Roots Tracing 的过程，找出存活对象且用户线程可并发执行

重新标记：为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。仍然存在Stop The World问题

并发清除：对标记的对象进行清除回收

CMS收集器的内存回收过程是与用户线程一起并发执行的

8.6.4.G1垃圾回收器

定义：

Garbage First

JDK 9以后默认使用，而且替代了CMS 收集器

8.6.5.垃圾回收阶段

新生代伊甸园垃圾回收—–>内存不足，新生代回收+并发标记—–>回收新生代伊甸园、幸存区、老年代内存——>新生代伊甸园垃圾回收(重新开始）

Young Collection

分区算法region

分代是按对象的生命周期划分，分区则是将堆空间划分连续几个不同小区间，每一个小区间独立回收，可以控制一次回收多少个小区间，方便控制 GC 产生的停顿时间

E：伊甸园 S：幸存区 O：老年代

• 会STW

图示为伊甸园到幸存者区到老年代的分区图示。

Young Collection + CM

CM：并发标记

• 在 Young GC 时会对 GC Root 进行初始标记
• 在老年代占用堆内存的比例达到阈值时，对进行并发标记（不会STW），阈值可以根据用户来进行设定

Mixed Collection

会对E S O 进行全面的回收

• 最终标记
• 拷贝存活

-XX:MaxGCPauseMills:xxx 用于指定最长的停顿时间

问：为什么有的老年代被拷贝了，有的没拷贝？

因为指定了最大停顿时间，如果对所有老年代都进行回收，耗时可能过高。为了保证时间不超过设定的停顿时间，会回收最有价值的老年代（回收后，能够得到更多内存）

fullGC

8.6.6.跨代引用

新生代的跨代引用：当我们要对新生代进行垃圾回收时，我们要寻找新生代的根对象，而新生代的根对象往往在老年代里，而遍历老年代所有对象又费时费力。

所以，我们采用卡表机制，将老年代对象细分，分为很多卡，当有引用了新生代对象，就把对应的卡标记为脏卡，这样，就只用关注脏卡区域就行了。

8.6.7.remark

重新标记阶段

在垃圾回收时，收集器处理对象的过程中

黑色：已被处理，需要保留的 灰色：正在处理中的 白色：还未处理的

remark的问题阐述：首先，明确一点概念，垃圾回收器处理对象只会逐个处理，已经处理过的路径，不会再对其重复处理。

于是就存在一个问题，某一c对象被b对象取消引用，同时并发标记时，用户线程调用了已经处理过的a对象又对c进行引用。而此时c仍被标记为清理对象，而a又不会被垃圾回收。

之后c会因为被标记为无引用被回收掉（实际上被引用），而引起损失。

于是，垃圾回收器有一个remark机制来处理这个问题，当对象引用改变时，会对他进行一个写屏障，然后stm，将它放进处理队列里，重新判断，标记它的引用。

8.7.JDK 8u20字符串去重

过程

• 将所有新分配的字符串（底层是char[]）放入一个队列
• 当新生代回收时，G1并发检查是否有重复的字符串
• 如果字符串的值一样，就让他们引用同一个字符串对象
• 注意，其与String.intern的区别
  • intern关注的是字符串对象
  • 字符串去重关注的是char[]
  • 在JVM内部，使用了不同的字符串标

优点与缺点

• 节省了大量内存
• 新生代回收时间略微增加，导致略微多占用CPU

8.8.JDK 8u40 并发标记类卸载

在并发标记阶段结束以后，就能知道哪些类不再被使用。如果一个类加载器的所有类都不在使用，则卸载它所加载的所有类

8.9.JDK 8u60 回收巨型对象

9.GC 调优(了解程度)

查看虚拟机参数命令

"F:\JAVA\JDK8.0\bin\java" -XX:+PrintFlagsFinal -version | findstr "GC"

可以根据参数去查询具体的信息

调优领域

• 内存
• 锁竞争
• CPU占用
• IO
• GC

确定目标

低延迟/高吞吐量？ 选择合适的GC

• CMS G1 ZGC
• ParallelGC
• Zing

最快的GC是不发生GC

首先排除减少因为自身编写的代码而引发的内存问题

• 查看Full GC前后的内存占用，考虑以下几个问题
  • 数据是不是太多？
  • 数据表示是否太臃肿
    • 对象图
    • 对象大小
  • 是否存在内存泄漏

新生代调优

• 新生代的特点
  • 所有的new操作分配内存都是非常廉价的
    • TLAB
  • 死亡对象回收零代价
  • 大部分对象用过即死（朝生夕死）
  • MInor GC 所用时间远小于Full GC
• 新生代内存越大越好么？
  • 不是
    • 新生代内存太小：频繁触发Minor GC，会STW，会使得吞吐量下降
    • 新生代内存太大：老年代内存占比有所降低，会更频繁地触发Full GC。而且触发Minor GC时，清理新生代所花费的时间会更长
  • 新生代内存设置为内容纳[并发量*(请求-响应)]的数据为宜

幸存区调优

• 幸存区需要能够保存 当前活跃对象+需要晋升的对象
• 晋升阈值配置得当，让长时间存活的对象尽快晋升