JVM - 内功修炼之内存分配与回收策略

Love The Way You Lie 2023-07-01 13:58 87阅读 0赞

### 文章目录 ###

*  JVM - 内功修炼之内存分配与回收策略
 *   *  1.HotSpot VM GC
     *   *  1.1 GC有几种？
         *   *  1.1.1 Partial GC
             *  1.1.2 Full GC
         *  1.2 GC触发条件
         *  1.3 谈一谈我对Minor GC、Major GC、Full GC的理解
     *  2.堆内存分配及分配规则
     *   *  2.1 对象优先在新生代的Eden区分配
         *  2.2 线程本地分配缓存区-TLAB
         *   *  2.2.1 TLAB是什么
             *  2.2.2 TLAB有什么缺点？
         *  2.3 大对象直接在老年代分配
         *   *  2.3.1 大对象是什么？
             *  2.3.2 垃圾收集器再回首
             *  2.3.3 大对象真的会直接在老年代分配吗？

# JVM - 内功修炼之内存分配与回收策略 #

> ** 看过前面几篇博客的同学应该已经对JVM以及其垃圾收集算法和垃圾回收器都有了一定的认识，而JVM中核心的自动内存管理其实从本质上主要解决了两个问题：一个是`对象内存分配`，另一个就是`对象内存回收`。接下来我们主要就是针对内存分配以及回收策略进行详细的介绍。**

## 1.HotSpot VM GC ##

>  在我们对内存管理进行了解之前，我们先来了解一个从我们刚刚接触Java这门语言就肯定听过的好东西-`GC`，这里就以我们平常使用的`HotSpot VM`对`GC`进行进一步的探索。

### 1.1 GC有几种？ ###

>  其实针对`HotSpot VM`实现来说，其`GC`主要分为两大类：`Partial GC`、`Full GC`。

#### 1.1.1 Partial GC ####

>  `Partial GC`：不对整个GC堆进行回收的一种模式
> 
> 1.  Young GC(Minor GC)：只收集young gen的GC。
> 2.  Old GC(Major GC)：只收集old gen的GC。只有CMS的concurrent collection是这个模式。
> 3.  Mixed GC：收集整个young gen以及部分old gen的GC。只有G1有这个模式。

#### 1.1.2 Full GC ####

>  `Full GC`：收集整个GC堆，包括young gen、old gen、perm gen（JDK1.8起移除永久代）等所有部分的模式。

### 1.2 GC触发条件 ###

>  上面我们对GC有了一个简单的认识，对于`Minor GC`来说，触发条件其实比较简单：当`young gen`中Eden区分配满时触发。由于`Young GC`后部分存活的对象会晋升至`old gen`，所以一般`Young GC`后`old gen`占有量会提升。  
>    
>  而`Full GC`则相对较复杂，这里给大家介绍一下我所了解的几种情况：
> 
> 1.  调用`System.gc()`：  
>        
>      这种方式应用程序只是建议虚拟机去执行`Full GC`，而虚拟器并不一定会去真正执行。可通过`-XX:+ DisableExplicitGC`来禁止RMI调用System.gc。  
>        
>      我们试想一个场景，假设总共有50M内存，第一次操作申请30M内存，操作完成后VM仍占有25M，此时再进行一次同样的操作申请30M则会出现OOM异常，大部分这种情况其实都发生在我们处理大数量级别的数据时，比如大数据量Excel操作。不过我们可以通过一些其他方式避免这种情况的发生比如调整整个虚拟机的配置。  
>        
>      随着JVM的发展，对于内存管理也在不断地优化，所以一般情况下仍不建议手动去调用`System.gc()`而是让虚拟机管理内存，最主要的原因就是其未知性、不可控性。但是它的存在也给一些特定情况提供了一种选择和可能性。  
>      
> 2.  老年代`(Old Generation)`空间不足：  
>        
>      老年代空间不足的原因有很多，比较常见的场景就是大对象在新生代无法分配从而直接进入老年代，或者长期存活的对象进入老年代等。对于大对象直接在老年代分配我们可以通过尽量不创建过大的对象或者数组去避免，或者通过`-Xmn`等参数调整新生代的容量，使对象在新生代被回收。另外还可以通过`-XX:MaxTenuringThreshold`参数将对象晋升老年代的阈值进行调整。  
>      
> 3.  永久代`(Permanet Generation)`空间不足：  
>        
>      我们都知道JDK1.8之前HotSpot虚拟机中是存在永久代的，而方法区正是基于永久代中实现的，其中会存储已被虚拟机加载的类信息(例：类版本号、方法、接口等)、常量、静态变量、即时编译器编译后的代码等数据。  
>        
>      如果系统中所需加载的类、反射的类或者调用的方法过多时，永久代是有可能被占满的。可以适当调整永久代空间避免该问题。  
>      
> 4.  空间分配担保失败`(promotion failed)`：  
>        
>      看过前面文章的同学已经知道了，采用复制算法的`Minor GC`需要老年代的空间作为担保，如果担保空间不足失败的话就会进行一次`Full GC`。这种情况也可以通过调整`survivor space`空间尽量避免。  
>      
> 5.  `Concurrent Mode Failure`：  
>        
>      首先从字面来看，就是并发模式的一种失败情况。我们知道当我们使用`CMS`收集器时分为很多阶段，其中一个阶段就是和用户线程并发执行GC操作，此时如果有对象正在晋升到老年代并老年代空间不足时，就会引发`Concurrent Mode Failure`，从而触发`Full GC`。这种情况同样也可以通过调整`survivor space`、`old gen`或调低并发GC频率尽量避免。  
>      
> 6.  统计比较晋升老年代平均大小和当前老年代剩余空间：  
>        
>      这种情况放在最后介绍主要是因为相比之前的几种情况稍微复杂一些。`Hotspot VM`为了避免当新生代对象晋升老年代时，由于老年代空间不足而出现晋升失败的现象，在进行`Minor GC`时，都会先去比较之前统计的`Minor GC晋升到老年代的平均大小`是否大于当前老年代的剩余空间，大于的话则不会触发`Young GC`而转为触发`Full GC`。  
>        
>      这里我们举个例子更加形象有助于大家理解。例如第一次触发`Minor GC`时，有10MB对象晋升到老年代，则第二次发生`Minor GC`时会先检查老年代剩余空间是否大于10MB，否则直接进行`Full GC`。

### 1.3 谈一谈我对Minor GC、Major GC、Full GC的理解 ###

>  其实当大家对JVM挖掘进行到这一步的时候，对于JVM自身的内容已经有了一定的认知并且有了自己的理解，从而在某种程度上对于同一个知识点会有分歧。这里我就先谈一谈最为容易理解的`Minor GC`。  
>  `Minor GC`其实也就是我们上面所描述的`Young GC`，这种GC策略指只发生在新生代上的垃圾回收，由于我们Java应用中大多数对象都具有朝存夕亡的特点，所以`Minor GC`发生地非常频繁，并且一般情况下回收速度都比较快。  
>    
>    
>  其实由于`HotSpot VM`发展了这么多年，对于很多概念性的名词大家可能都已经被弄混了，我也翻阅了一部分官方资料也没有找到详细的介绍。我个人的理解其实`Major GC`和`Full GC`在大部分情况下都是等价的，都是发生在老年代的GC。  
>    
>  当进行`Major GC`时，经常会伴随着至少一次`Minor GC`。当然这并不是一定的，例如在`Parallel Scavenge`收集器的收集策略中可以进行相应的直接进行`Major GC`的策略选择。而`Major GC`的速度一般会比`Minor GC`慢10倍以上，这个想必大家也通过各种资料了解到了。  
>    
>  而`Full GC`从命名上大家可能认为，这是一个回收整个GC堆的策略。但其实`Full GC`本身并不会先进行`Minor GC`，只不过我们可以通过配置指定让`Full GC`执行前先进行一次`Minor GC`。而这和我们上面讲的`Major GC`大部分情况下又很类似，主要是因为老年代中很多对象都会引用到新生代中的对象，先进行一次`Minor GC`可以提高之后老年代GC的回收效率。例如当我们老年代使用`CMS`时，可以通过设置`CMSScavengeBeforeRemark`使其在重新标记前先进行一次`Minor GC`。  
>    
>  `Minor GC`和`Major GC`其实我们可以看作是年轻代GC和老年代GC的俗称。而我们之前所了解的`Serial GC`、`Parallel GC`、`CMS`、`G1 GC`等收集器其实就是可以对应到某个`Young GC`和`Old GC`的算法组合。例如`CMS`并不完全等于`Full GC`或者`Major GC`，对其有深入了解的同学可能知道，`CMS`其实分为多个阶段，而只有`SST(stop the world)`阶段才被计入`Full GC`的次数和时间，而与应用业务线程并发执行的GC次数以及时间则不会被计入。

## 2.堆内存分配及分配规则 ##

>  我们从之前几章可以了解到，在JVM中的一些内存分布结构，有新生代中的`Eden`、`Survivor From`、`Survivor To`以及`老年代`和`永久代(JDK1.8为Metaspace)`。其实对于整个分布我们已经有了一个清晰的认识，但是都是基于概念性的理解，这里我们就从实际出发去真正触摸到这些区域的分配规则。

### 2.1 对象优先在新生代的Eden区分配 ###

>  我们先来一个简单的例子，来感受一下JVM其实就在我们身边。先上一段朴素的代码。
> 
>     public class EdenAllocation { 
>     
>        public static final int byteSize = 1024 * 1024;
>     
>        public static void main(String[] args) { 
>            byte[] bytes = new byte[2 * byteSize];
>        }
>     }
> 
>  JVM提供了`-verbose:gc`、`-XX:+PrintGCDetails`参数可以开启打印GC时各内存区域的详细情况，在实际开发中我们可以将内存回收的日志打印到特定日志文件中然后进行单独分析，后面也会给大家介绍一些不错的在线分析的工具。这里我们先将参数加上然后运行程序。  
> ![在这里插入图片描述][20200326142147771.png]  
> ![在这里插入图片描述][20200326142816854.png]  
>  这里我们可以看到只有`Young Gen`中`Eden`区被使用了，这也能够验证我们所说的对象是会优先在新生代的Eden区上进行分配的。  
>    
>  这里我们再将例子进阶一下，将我们之前所了解到的知识点更加具体化。我们首先通过`-Xms20M -Xmx20M -Xmn10M`限制整个Java堆的初始大小为20M，并且最大内存也为20M，另外将新生代的大小设置为10M。  
> ![在这里插入图片描述][20200326143330849.png]  
>  我们先来看一种特殊的情况。
> 
>     public class EdenAllocation { 
>     
>        public static final int byteSize = 1024 * 1024;
>     
>        public static void main(String[] args) { }
>     }
> 
> ![在这里插入图片描述][20200326155518844.png]  
>  这里我们先解释一个之前的概念，就是Eden区和Survivor区我们之前知道是`8:1:1`，这里从`YoungGen`中我们可以很明显地看出实际上就是严格按照这个比例进行分配的，并且我们可以通过`-XX:SurvivorRatio`去控制其空间比例，这里我们先不进行修改。  
>    
>  我们可以看到当我们只声明了一个静态常量没有其他任何业务代码时此时年轻代仍然占有2647K的大小，那么我们对上面的程序进行一点修改再来看看结果如何。
> 
>     public class EdenAllocation { 
>     
>        public static final int byteSize = 1024 * 1024;
>     
>        public static void main(String[] args) { 
>            byte[] edenAllocation1 = new byte[2 * byteSize];
>            byte[] edenAllocation2 = new byte[2 * byteSize];
>            byte[] edenAllocation3 = new byte[2 * byteSize];
>       }
>     }
> 
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70]  
>  当我们进行程序修改后，GC日志发生了一些变化，我们一起来看一下。  
>    
>  首先我们之前知道了在没有其他业务代码时年轻代占有2M左右空间。然后我们修改了对应程序，当`edenAllocation1`和`edenAllocation2`分配完后，年轻代空间大概占有6M多。此时我们进行`edenAllocation3`的内存分配时发生了`Allocation Failure`触发了`Minor GC`，这是由于年轻代剩余可用空间已经不足以给`edenAllocation3`进行分配，而`edenAllocation1`和`edenAllocation2`仍然存活并且无法放入`Survivor`区，所以通过担保机制将`edenAllocation3`放至老年代中。  
>    
>  所以在这次GC结束后，通过日志也可以验证我们上面总结的整个流程。

### 2.2 线程本地分配缓存区-TLAB ###

>  在介绍`TLAB`之前我先来带大家回忆一个概念-`指针碰撞`，如果不记得的同学别急，这里我带大家一步步来回顾。而在讲`指针碰撞`之前先从我们编程的起源new对象开始。
> 
>     public class TlabAllocation{ 
>     
>        public void newObject(){ 
>     		User user = new User();
>     	}	
>     }
> 
>  这里我们来看一下，这里我们new了一个User对象，但是这种对象的作用域不会逃逸出方法外，关于`方法逃逸`和`栈上分配`后面会提到，大概意思就是说该类对象生命周期随着方法开始而开始，随着方法调用结束而结束，也就是随着栈帧的入栈创建、出栈销毁。  
>    
>  按照我们一般的想法来说，JVM中的对象都放在堆内存中，那么当方法结束了之后没有指向该对象的引用，该对象就需要被GC回收掉，而如果同时存在大量这种情况的话对于GC来说也是鸭梨山大的。  
>    
>  这里我们开始回想一下之前我们讲的指针碰撞，在[JVM - 探索HotSpot虚拟机中的对象][JVM - _HotSpot]中我们介绍过分配内存的几种方式，下面这张图不知道大家是否还有印象。  
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70 1]  
>  指针碰撞方式分配内存时，当我们申请新的内存空间时，只需将指针向空闲内存空间移动指定内存空间大小的位置即可。那么大家有没有思考过一个问题：如果线程A正在给A1对象分配内存，此时指针并未来得及修改，而线程B又正在为B1对象分配内存，那么线程A和线程B所引用的指针地址就相同了，这样是会出现问题的。解决这种情况的方式有很多，这里就来讲一讲我们这里的主角`TLAB`。

#### 2.2.1 TLAB是什么 ####

>  `TLAB`全称`Thread Local Allocation Buffer`，即线程本地分配缓存区，这是一个线程专属的内存分配区域。我们可以通过`-XX:UseTLAB`参数开启`TLAB`，当每个线程初始化时会给他额外申请一块指定大小的内存，这块内存区域只能被当前线程使用。通过这种方式每个线程就会拥有一个独立的内存空间，在进行内存分配时只在自己空间上分配而不会影响其他线程分配内存，既可以避免并发冲突的情况又可以提高分配效率。  
>    
>  `TLAB`的空间非常小，默认情况下占Eden区域的1%，我们可以通过`-XX:TLABWasteTargetPercent`调整TLAB所占Eden区域的百分比。另外我们可以通过`-XX:+PrintTLAB`来跟踪TLAB的情况。  
>    
>  我相信大家对`指针碰撞`其实已经很熟悉了，而TLAB的本质其实也是通过三个指针`(start、end、top)`来进行管理的。我们上面知道了线程初始化时会额外申请一块指定大小的内存，而`start`和`end`就是用来标记Eden区中某块连续区域被`TLAB`所使用的占位标记，而这块空间则不允许被其他线程使用。`top`指针则是用于这一块TLAB区域中分配对象使用，初始化时和`start`指向同一个位置，随着这块区域不停分配对象，`top`指针会逐步移向`end`指针所处位置，当达到某些条件时则会触发`TLAB refill`，关于更详细的内容大家有兴趣可以自行深入学习了解。

#### 2.2.2 TLAB有什么缺点？ ####

>  通过上面的了解，我们知道了`TLAB`确实给内存分配以及GC带来了很大的帮助，但是往往一件事的特性也可能会成为他的缺点。
> 
> 1.  上面我们介绍了`TLAB`的空间其实是非常小的，也就是说当一个线程申请了一块TLAB空间时其大小就固定了，假如此时需要给大对象进行分配时，则TLAB就无法分配成功了。
> 2.  另一种情况就是假如TLAB空间有10kb，已经占有6kb，此时需要为一个5kb的对象分配内存，发现剩余空间不足那么JVM是怎么处理的？其实对于TLAB有一个最大浪费空间的设置，当剩余空间(4kb)小于最大浪费空间(假设为5kb)则当前线程会重新在Eden区申请一个TLAB空间用于创建，若依然不够则会直接在Eden区分配；当剩余空间(4kb)大于最大浪费空间(假设为3kb)则直接在Eden区分配。
> 3.  正是因为上面这点存在，虽然解决了一些问题但又引发了其他问题。当这种重复申请的行为多了之后，首先造成的一个问题就是Eden区域空间不连续产生大量的空间碎片，另一个问题就是由于TLAB区域是允许浪费空间的，但是这部分压力会在短时间内施加给Eden区，从而可能会触发更多的GC。

### 2.3 大对象直接在老年代分配 ###

#### 2.3.1 大对象是什么？ ####

>  要说大对象直接在老年代分配，那我们首先就要知道大对象到底是什么？  
>    
>  我们所说的`大对象`其实就是指需要大量`连续内存空间`的对象，我们比较熟悉的就是长数组或者字符串，这也就是我们为什么使用数组来进行示例的原因，对于控制内存空间大小比较明显。过多的大对象其实对JVM的内存分配来说其实是一件不好的事情，尤其是生命周期特别短的大对象更是JVM的天敌，经常出现过多的大对象很容易导致内存有不少空间但是不得不提前触发GC来完成分配。

#### 2.3.2 垃圾收集器再回首 ####

>  这里为什么我要再提垃圾收集器，主要原因当然是接下来我们所要涉及的内容与其关系紧密，并且我个人认为概念性的知识与实践的碰撞才能够让仍更加深刻认识和记忆这个知识点，这里恰到好处。  
>    
>  相信有心的同学应该已经注意到了，在我们之前的例子中并没有对特定垃圾回收器进行限制，但是对于我们接下来的理解必须先来熟悉一下我们所使用的环境到底使用的是何种垃圾回收器组合。  
>    
>  我们通过`java -XX:+PrintCommandLineFlags -version`命令来看一看到底我们的环境真实的情况是怎样的。
> 
>     -XX:InitialHeapSize=133473088 // 初始堆大小
>     -XX:MaxHeapSize=2135569408  // 最大堆大小
>     -XX:+PrintCommandLineFlags 
>     -XX:+UseCompressedClassPointers // 默认开启类指针压缩
>     -XX:+UseCompressedOops // 默认开启对象指针压缩
>     -XX:-UseLargePagesIndividualAllocation 
>     -XX:+UseParallelGC // 默认使用Parallel垃圾收集器
>     java version "1.8.0_131"
>     Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
>     Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
> 
>  这里我们只看我们这里要了解的关键信息`-XX:+UseParallelGC`，那么这对应的是哪种GC组合呢？
> 
> <table> 
>  <thead> 
>   <tr> 
>    <th>UseGC</th> 
>    <th>Young Gen</th> 
>    <th>Old Gen</th> 
>    <th>描述</th> 
>   </tr> 
>  </thead> 
>  <tbody> 
>   <tr> 
>    <td>UseSerialGC</td> 
>    <td>Serial</td> 
>    <td>Serial Old</td> 
>    <td></td> 
>   </tr> 
>   <tr> 
>    <td>UseParNewGC</td> 
>    <td>ParNew</td> 
>    <td>Serial Old</td> 
>    <td></td> 
>   </tr> 
>   <tr> 
>    <td>UseConcMarkSweepGC</td> 
>    <td>ParNew</td> 
>    <td>CMS</td> 
>    <td></td> 
>   </tr> 
>   <tr> 
>    <td>UseParallelGC</td> 
>    <td>Parallel Scavenge</td> 
>    <td>Parallel Old</td> 
>    <td></td> 
>   </tr> 
>   <tr> 
>    <td>UseParallelOldGC</td> 
>    <td>Parallel Scavenge</td> 
>    <td>Parallel Old</td> 
>    <td><a href="https://www.cnblogs.com/kelthuzadx/p/10924117.html" rel="nofollow">UseParallelGC和UseParallelOldGC的区别</a></td> 
>   </tr> 
>  </tbody> 
> </table>
> 
>  这也就和我们之前打印的GC日志相印证了。  
> ![在这里插入图片描述][20200327182033921.png]

#### 2.3.3 大对象真的会直接在老年代分配吗？ ####

>  我们在上面`2.1 对象优先在新生代的Eden区分配`中提到了一个例子，当分配三个2M大小的数组时，会触发一次GC将年轻代中已经分配内存的两个数组晋升到老年代中，大家印象不深刻的可以往回看一看。这里我们在不修改垃圾收集器的情况下将他做一个简单的修改。
> 
>     public class EdenAllocation { 
>     
>        public static final int byteSize = 1024 * 1024;
>     
>        public static void main(String[] args) { 
>            byte[] edenAllocation1 = new byte[2 * byteSize];
>            byte[] edenAllocation2 = new byte[2 * byteSize];
>            byte[] edenAllocation3 = new byte[4 * byteSize];
>        }
>     }
> 
>  当我们将第三个数组改为`4MB`那么效果是不是也一样呢？  
> ![在这里插入图片描述][2020032717054088.png]  
>  这里我们看到，并没有触发GC机制，在我们看是将`edenAllocation3`作为大对象直接放在老年代中进行分配了。通过JVM文档得知其提供了`-XX:PretenureSizeThreshold`参数可用于调整对象直接在老年代分配的阈值，这么做的目的是为了避免在Eden区和两个Survivor区之间进行大量内存复制的操作，那么我们添加这个参数看一下效果`-verbose:gc -XX:+PrintGCDetails -Xms20M -Xmx20M -Xmn10M -XX:PretenureSizeThreshold=5242880`，这里主要注意一点该参数不支持直接配置M单位级别数值，这里我们配置为5 x 1024 x 1024。  
> ![在这里插入图片描述][20200327184521905.png]  
>  按照理解，超过5M大小则直接在老年代分配，而我们这个例子似乎应该会进行一次GC才对？其实不然，大家是否还记得`Parallel Scavenge`收集器是一款专注于吞吐量的垃圾收集器，其实它有一套自己独立的大对象分配规则。那么这里我们将垃圾收集器指定为`Serial`试一下效果如何，这里我们先不去修改PretenureSizeThreshold参数，`-verbose:gc -XX:+PrintGCDetails -Xms20M -Xmx20M -Xmn10M -XX:+UseSerialGC`。  
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70 2]  
>  首先第一点这里我们可以看到框起来的年轻代和老年代标识已经变更，并且触发了一次GC。那么我们来设置一下`XX:PretenureSizeThreshold=3145728`。  
> ![在这里插入图片描述][20200327185122843.png]  
>  这一次GC没有发生，当一个大对象达到了其设定的阈值时，不管年轻代中是否能够分配都会直接在老年代中分配，这里我们用`SerialGC`进行了验证，至于其他的大家有兴趣可以自己去检验。而`Parallel Scavenge`收集器是根据我们`“碰巧”`设置的4MB为阈值去区分大对象还是有其一套独特的算法和规定这个大家可以自己去深入探索。  
>    
>  尽管很多同学平时出于各种原因会尽可能去避免修改一些JVM的相关配置害怕出现各种自己不熟悉的问题，但是内存回收和垃圾收集器在很多时候都是影响系统性能和并发能力的重要因素之一。而JVM提供各种各样的收集器和调节参数，就是因为各种业务场景需要不同的组合选择才能达到最优的性能。  
>    
>  所以对于JVM来说，并没有固定的收集器、参数组合以及最优的调优方式，也就不会存在一定性的内容分配和回收策略。而我们去学习这些知识、了解各种设计的优劣，就是因为JVM给了我们一片天地，我们不仅仅是只为生存(也就是使用)，而更长远的则是需要我们去创造(根据实际需要进行调整和尝试)。

[20200326142147771.png]: https://img-blog.csdnimg.cn/20200326142147771.png
[20200326142816854.png]: https://img-blog.csdnimg.cn/20200326142816854.png
[20200326143330849.png]: https://img-blog.csdnimg.cn/20200326143330849.png
[20200326155518844.png]: https://img-blog.csdnimg.cn/20200326155518844.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200326161441307.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ=,size_16,color_FFFFFF,t_70
[JVM - _HotSpot]: https://blog.csdn.net/u013985664/article/details/102999472
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200326190145661.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ=,size_16,color_FFFFFF,t_70
[20200327182033921.png]: https://img-blog.csdnimg.cn/20200327182033921.png
[2020032717054088.png]: https://img-blog.csdnimg.cn/2020032717054088.png
[20200327184521905.png]: https://img-blog.csdnimg.cn/20200327184521905.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/2020032718494155.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM5ODU2NjQ=,size_16,color_FFFFFF,t_70
[20200327185122843.png]: https://img-blog.csdnimg.cn/20200327185122843.png