JVM学习——垃圾回收GC（学习过程）

JVM学习-垃圾回收（GC）

2020年02月19日06:03:56，开始学习垃圾回收，学习资料来源（张龙老师的JVM课程）

JVM内存数据区域知识复习

学习垃圾回收之前，要对JVM内部的内存区域有详细的了解。先对相关内存区域的内容知识进行复习和总结，为垃圾回收的学习奠定基础。

image-20200219060429726

灰色区域是线程共享

白色区域为线程隔离

image-20200219064036596

image-20200219064120088

image-20200219064229291

引用占用4个字节，空对象占用8个字节。

方法执行结束后，对应的栈Stack中的变量马上回收，但是Heap中的对象要等到GC来回收。

JVM垃圾回收（Garbage Collection）

理论知识

JVM垃圾回收（GC）模型

  1. 垃圾判断算法
  2. GC算法
  3. 垃圾回收器的实现和选择

垃圾判断算法

  1. 引用计数算法（Reference Counting）
  2. 根搜索算法 （GC Roots Tracing）

引用计数算法

image-20200219064625169

对象循环引用的问题结束： A引用B，B又引用A。就算没有外部引用。但是又状态一直为1，这样的就回收不了了。

image-20200219064807017

当然，还是可以通过其他手段来规避他的这个缺点的。

根搜索算法

![image-20200219070328494](/Users/shangyifeng/Library/Application Support/typora-user-images/image-20200219070328494.png)

image-20200219070437201

方法区

image-20200219070745942

垃圾回收（GC）算法

  1. 标记-清除算法（Mark-Sweep）
  2. 标记-整理算法（Mark-compact）
  3. 复制算法（Copying）
  4. 分代算法（Generational）:几乎所有虚拟机都会采用这个算法

为什么复制算法在新生代用的多呢？因为java大多是的java对象都是招生熄灭的。可被回收的并不多。老年代的生命周期较长，所以不方便使用复制算法。

所以老年代采用标记清楚和标记整理算法

标记-清楚算法（Mark-Sweep）

image-20200219071343749

标记-清楚算法：的执行原理图如下所示

如有以下这些对象

image-20200219072023671

Runtime Stack 虚拟机栈是根搜索算法的入口

image-20200219072122102

先标记

image-20200219072157821

F - J 之间有循环引用。 但是 D-G -F-J-M 都是需要被回收掉的。绿色的都是还要 保留的。

流程执行完之后就是如下所示

再清除

image-20200219072245947

image-20200219072301392

复制（Copying）搜集算法

image-20200219072438309

实现简单，运行高效：但是：需要将内存缩小为原来的一般，代价高昂。

image-20200219072606909

现在主要用来回收 新生代

image-20200219073336674

在老年代中，一般不能直接选用这种算法。（因为老年代的存活率高 ）

复制搜集算法的示意图

  1. 把A- C=复制

image-20200219073521882

把相互引用的都给复制

image-20200219073711606

余下的没有被复制，会被连锅端掉

image-20200219073746128

复制搜集算法优点

image-20200219073803923

标记-整理算法

image-20200219073918760

如下为执行示意图

标记移动。腾出来连续的空间。没有内存碎片。就是有点慢。

image-20200219073959046

image-20200219074030501

分代收集算法（Generational Collecting）

image-20200219074425744

新生代 和 老年代 的定义

新生代：部分刚新生的对象，没有用的

老年代：经历多次垃圾回收，还会保留

image-20200219074816247

JVM6时候的参考（现在已经没有永久代了）

image-20200219074836178

image-20200219075017841

为什么说只会浪费百分之十呢，这里二娃给我讲述的

这次 设置了2个Survivor是非常巧妙的。第一次的时候，8+1 被使用。复制完之后。放入另外一个Survivor。然后下一次的时候。8+另外一个1，把对象复制到1上。所以就完成了，轮流替换。每次被闲置的就会只有一个占用百分之10的Survivor来准备接受要复制的对象。over。

image-20200219075635735

JVM启动的时候可以根据程序的需要，选择一定的需求所对应的垃圾收集器和对应的垃圾收集算法。

image-20200219075742489

内存相关概念

内存结构

image-20200219075826778

内存分配

image-20200219080003520

内存回收

image-20200219080025676

强引用，软引用，弱引用，虚引用

image-20200219080154476

软引用：内存不够的时候，一会被会GC，长期不用也会被收集

垃圾收集算法

image-20200219080244760

黄色区域应用在年轻代

灰色区域应用在老年代

GC触发的时机

image-20200219080326960

尽量避免对Full GC的使用，因为全局GC调用的时候，会停滞所有的义务代码执行。

MinorGC是一定会有的。

垃圾回收器

垃圾回收器理论分析

没有万能的垃圾回收器，交互性和吞吐率是不兼容的，没有银弹

image-20200219080629770

垃圾收集器的“并行”和“并发”

image-20200219081106164

让用户线程处于等待状态是一个很恐怖的事情。

收集器

Serial收集器

STW（Stop The World） 暂停所有的工作线程

虚拟机运行Client模式下的默认收集器

image-20200219081155185

image-20200219081227092

单线程的GC。

ParNew收集器

Serial的多线程版本。其他都一样

image-20200219081416624

image-20200219081532679

Parallel Scavenge收集器

image-20200219081637673

允许较长较长时间的STW。

Serial Old收集器

image-20200219081722260

Parallel Old收集器

image-20200219081731864

image-20200219081742646

CMS收集器：实现非常复杂的收集器

image-20200219094602469

image-20200219094637936

image-20200219094655006

image-20200219094720256

image-20200219094735395

综上，PPT 都需要自己详细读读。

再次回顾一下JVM的内存数据区域的分配情况

image-20200219092857424

  1. Oracle的HotSpot虚拟机，将 java虚拟机方法栈和本地方法栈放在同一个地方
  2. 程序计数器是唯一一个没有要求说必须要使用GC垃圾回收的地方。
  3. 白色的地方是线程独有的

总结

  • 垃圾判断算法

    • 引用计数算法
    • 根搜索算法

  • 垃圾回收GC算法（常见的）

    • 标记-清除算法
    • 标记-整理算法
    • 复制算法（8-1-1）
    • 分代算法（综合前面几种，针对不同的类型，采用不同的算法）

  • 垃圾收集器

    • Serial
    • ParNew
    • Parallel Scavenger (PS (jdk1.8默认的新生代垃圾收集器)）
    • Parallel Old（ParOld jdk1.8默认的老年代垃圾收集器）
    • Serial Old
    • CMS

Java内存泄露的经典原因

  1. 对象定义在错误的范围（Wrong Scope）
  2. 异常（Exception）处理不当
  3. 集合数据管理不当

对象定义在错误的范围

image-20200219095147567

从成员变量 移动到 局部变量。 （布局就不一样了。变量会被及时回收）

异常处理不当

image-20200219095332632

异常处理的不到位，关闭流的操作，应该放置在finally里面。

image-20200219095408581

集合数据管理不当

image-20200219095427055

垃圾回收日志（GC Log）

上案例:

image-20200219100059547

这里需要注意点是：数组是原生数据类型。 数组里面的默认值都是0。如果是引用类型的数组，里面的值都为null。

程序初始：

平淡无奇

image-20200219100226243

输出结果：平淡无奇：

image-20200219100816679

接下来添加一定的JVM参数，进行启动，就变得大不一样

JVM参数加 -verbise:gc ： 添加垃圾回收GC的详细信息

JVM参数加 Xms20M Xmx20m：分别表示堆容量的初始值和最大值，一般都设置为一样。固定位20M

JVM参数加-XMn10M：表示新生代的容量大小为10M

JVM参数加-XX:+PrintGCDetails：打印GC的详细信息

JVM参数加-XX:SurvivorRatio=8：表示Even空间和Survivor的比例是8：1：1

image-20200219100657109

运行结果：只有GC详情，但是未执行GC

这东西都是：-XX:+PrintGCDetails 打印的，还没有展现GC、

在程序中，再加入一行 代码，再加一个数组（大小就到达GC临界点）

image-20200219101210887

运行结果：GC就出来了

image-20200219101121573

image-20200219101313534

随着程序的变化，内存空间的修改。会导致不同的打印结果出现。

GC：表示 minor GC ,后面数据的含义和格式

​ Allocation Failure:分配失败

​ PSYoungGen：年轻代 PS（Parallel Scavenger 收集器）。

​ 执行前-执行后(总容量)：（7694k->624k(9216k)）

​ 执行GC之前堆的大小-执行后的存活对象的大小（堆的大小）：（5656k->4728k(19456k)）

image-20200219102735659

4104k对应的，正好是老年代新增的 大小。（从新生代释放出来，进入老年代）

Full GC 会导致程序暂停 （2，2，2，2 会出现Full GC， 2，2，3，3 反而不会进入Full GC）

没进入Full GC的原因：当新生代已经无法容纳要生成的对象的时候，直接放入老年代

验证的概念如下：GC的触发时机

image-20200219101421689

对于网上的文章或者概念，还有书本等等。里面的内容都是不确定是对的，唯一能验证概念的，就是通过代码，通过数据去看结论。

JVM参数

image-20200219094720256

image-20200219094735395

java -XX:+PrintCommandLineFlags -version ：输出启动参数和java版本

image-20200219110007233

-XX:+UseParallelGC : 默认使用的GC是 Parallel

-XX:PretenureSizeThreshold=4194304:大小阈值设置，设置超过多大值时直接在老年代进行分配。

超过这个值之后，就不会在新生代去创建，直接进行入老年代

设置好上述参数，然后执行下面程序：

image-20200219112038982

但是:并不是上面的参数结论的作用。所以，一般结论正确与否，还是需要通过代码来确定正确性。

是因为：上述概念是需要使用 Serial 垃圾回收器。

所以再加一个参数：-XX:+UseSerialGC设置项目启动之后使用的GC是Serial垃圾回收器

image-20200219113314931

老年代占用5M：直接就是程序定义的对象的大小：说明直接进入老年代。

使用可视化工具查看垃圾回收

image-20200219114409701

这里可视化工具提供的手动按钮是 Full GC （System.gc()）

image-20200219114515452

image-20200219114528973

关于System.gc()的补充，我们手动调用gc或者自己执行gc方法的时候，我们只是告诉了JVM需要执行垃圾回收，但是至于什么时候回收，是由JVM决定的。

如果我们不告诉JVM需要GC的话，只有在创建新的对象的时候才有可能去校验是否需要垃圾回收。因为只有在创建对象的时候会导致堆内存的增加。

这就是System.get（）方法存在的意义和价值：在没有对象创建的时候触发垃圾回收。

jmc查看的可视化

image-20200219114902217

image-20200219115251845

FromSurvivor和ToSurvivor的角色的切换

如果频繁切换，那么会通过一定的算法转移到老年代。

-XX:MaxTenuringThreshold=5:在可以自动调节对象晋升(Promote)到老年代阈值的GC中设置该阈值的最大值。

设置可以晋升到老年代的最大存活年龄。该参数的默认值为15，CMS中默认值为6，G1中默认为15（在JVM汇总，该数值是由4个bit来表示的，所以最大值为1111，即15）

-XX:+PrintTenuringDistribution：打印出年龄为n的字节对象

经历了多次GC后，存货的对象会在FromSurvivor和ToSurvivor的角色之间来回切换。而这里面的一个前提则是这两个空间有足够的大小来存放这些数据，在这些算法中。会计算每个对象年龄的大小，如果达到某个年龄后发现总大小已经大于了Survivor空间的50%，那么这时候就需要调整阈值，不能再继续等到默认的15此GC后才完成晋升，因为这样会导致Survivor空间不足，所以需要调整阈值，让这些存货对象尽快完成晋升。

Survivor空间不足是很严重的。

image-20200219121330920

image-20200219121345626

运行结果：

image-20200219121422183

threshold的动态调整

image-20200219130642857

image-20200219130751220

这个时候运行，没有问题。

接下来添加JVM参数

XX:TargetSurviorRatio=60 ：占据百分之60，会重新计算阈值

XX:+PrintGCDateStamps:打印JVM运行的时间戳

XX:+UseConcMarkSweepGC: 老年代使用CMS

XX:+UserParNewGC:新生代使用ParNew

XX:MaxTenuringThreshold=3:最大年龄为3，就得去老年代了

image-20200219131136864

运行结果

image-20200219131207830

image-20200219132004058

image-20200219132049706

这里，下面的图，只有age=1的，说明，age=1,=2,=3的已经被全部放入老年代当中。

image-20200219131906826

枚举根节点

image-20200219154558522

OopMap数据结构

安全点： Safepoint

image-20200219154756567

安全点：程序执行并非在所有地方都能停顿下来开始GC，只有在达到安全点时才能暂停。

image-20200219154809669

image-20200219155750717

抢断式中断：JVM中断

主动式中断：轮询标志的地方和安全点是重合的。现在自己中断自己。

image-20200219160034945

安全区域

image-20200219160331233

image-20200219161026460

Safe Region

CMS垃圾回收器详解

将CMS垃圾回收器学完之后，需要大力度的学习一下G1垃圾回收器。

典故：CMS研究的人离职了，新来的人怎么也看不懂C++的源码。

CMS：Concurrent Mark Sweep 并发标记清除

image-20200219162027113

并发的含义：垃圾收集的线程可以和用户的业务线程同时执行。

标记和清除：说明CMS是采用标记和清除来完成的。

标记：标记的是哪些对象依然是属于存活状态。哪些是需要清除的对象。

清除：清除掉垃圾的对象。

image-20200219162510850

初始标记：

并发标记：

重新标记：为了修正并发期间因用户线程继续运作而导致的变动的部分。

并发清除：

CMS收集器运作步骤：

image-20200219162739106

初始标记：STW，没有用户线程

并发标记：可以和用户线程同时执行

重新标记：STW，没有用户标记

并发清理：可以和用户线程同时执行

重置线程：恢复到初始状态

CMS收集器的优点和缺点

优点：

image-20200219163126923

停顿：指的是用户线程停顿

缺点：

image-20200219163151757

空间分配担保：新生代容纳不了，直接扔给老年代，这就叫老年代担保。

image-20200219163505962

CMS收集器收集步骤：

image-20200219163917024

不带Concurrent，会导致用户线程暂停

image-20200219164301754

image-20200219164418340

image-20200219165516791

image-20200219165709071

image-20200219165754883

image-20200219165840708

到此：标记完成。接下来调用清理算法。

image-20200219165907894

image-20200219165926941

image-20200219165958257

image-20200219170028823

用程序去认识CMS垃圾收集器

程序代码

image-20200219174208582

虚拟机参数

image-20200219174226957

运行结果：

image-20200219174525991

posted @ 2020-02-23 11:44  dawa大娃bigbaby  阅读(598)  评论(1)  编辑  收藏  举报