JVM学习资料总结

爱被打了一巴掌 2023-01-17 07:35 152阅读 0赞

> 本博客是根据JVM【黑马程序员出品】教学视频学习所做的总结，为了自己更好的复习，从不同网站上进行搬移。  
> 原作者网址：[原作者网址][Link 1]

### Jvm学习目录 ###

*  一、什么是JVM
 *  二、内存结构
 *   *  1、程序计数器
     *  2、虚拟机栈
     *  3、本地方法栈
     *  4、堆
     *  5、方法区
     *  6、直接内存
 *  三、垃圾回收
 *   *  1、如何判断对象可以回收
     *  2、垃圾回收算法
     *  3、分代回收
     *  4、垃圾回收器

# 一、什么是JVM #

**定义**  
Java Virtual Machine，JAVA程序的**运行环境**（JAVA二进制字节码的运行环境）

**好处**  
一次编写，到处运行  
自动内存管理，垃圾回收机制  
数组下标越界检查

**比较**  
JVM JRE JDK的区别  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70]

# 二、内存结构 #

**整体架构**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 1]

## 1、程序计数器 ##

**作用**  
用于保存JVM中下一条所要执行的指令的地址

**特点**

*  线程私有
    
     *  CPU会为每个线程分配时间片，当当前线程的时间片使用完以后，CPU就会去执行另一个线程中的代码
     *  程序计数器是**每个线程所私有**的，当另一个线程的时间片用完，又返回来执行当前线程的代码时，通过程序计数器可以知道应该执行哪一句指令
 *  不会存在内存溢出

## 2、虚拟机栈 ##

**定义**

*  每个**线程**运行需要的内存空间，称为**虚拟机栈**
 *  每个栈由多个**栈帧**组成，对应着每次调用方法时所占用的内存
 *  每个线程只能有一个**活动栈帧**，对应着**当前正在执行的方法**

**演示**

public class Main { 
    	public static void main(String[] args) { 
    		method1();
    	}
    
    	private static void method1() { 
    		method2(1, 2);
    	}
    
    	private static int method2(int a, int b) { 
    		int c = a + b;
    		return c;
    	}
    }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 2]  
在控制台中可以看到，主类中的方法在进入虚拟机栈的时候，符合栈的特点

**问题辨析**

*  垃圾回收是否涉及栈内存？  
    ♦**不需要**。因为虚拟机栈中是由一个个栈帧组成的，在方法执行完毕后，对应的栈帧就会被弹出栈。所以无需通过垃圾回收机制去回收内存。
 *  栈内存的分配越大越好吗？  
    ♦不是。因为**物理内存是一定的**，栈内存越大，可以支持更多的递归调用，但是可执行的线程数就会越少。
 *  方法内的局部变量是否是线程安全的？  
    ♦如果方法内**局部变量没有逃离方法的作用范围**，则是线程**安全的**  
    ♦如果如果**局部变量引用了对象，并逃离了方法的作用范围**，则需要考虑线程安全问题

**内存溢出**  
Java.lang.stackOverflowError 栈内存溢出

**发生原因**

*  虚拟机栈中，**栈帧过多**（无限递归）
 *  **每个栈帧**所占用过大

**线程运行诊断**  
Linux环境下运行某些程序的时候，可能导致**CPU的占用过高**，这时需要定位占用CPU过高的线程

*  **top**命令，查看是哪个**进程**占用CPU过高
 *  **ps H -eo pid, tid（线程id）, %cpu | grep 刚才通过top查到的进程号**  
    通过ps命令进一步查看是哪个线程占用CPU过高
 *  **jstack 进程id**  
    通过查看进程中的线程的id，刚才通过ps命令看到的tid来对比定位，注意jstack查找出的线程id是**16进制的，需要转换**

## 3、本地方法栈 ##

一些带有**native关键字**的方法就是需要JAVA去调用本地的C或者C++方法，因为JAVA有时候没法直接和操作系统底层交互，所以需要用到本地方法

## 4、堆 ##

**定义**  
通过new关键字创建的对象都会被放在堆内存

**特点**

*  所有**线程共享**，堆内存中的对象都需要考虑线程安全问题
 *  有垃圾回收机制

**堆内存溢出**  
java.lang.OutofMemoryError ：java heap space. 堆内存溢出

**堆内存诊断**

jps
    
    jmap
    
    jconsole
    
    jvirsalvm

## 5、方法区 ##

**结构**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 3]  
**内存溢出**

*  1.8以前会导致**永久代**内存溢出
 *  1.8以后会导致**元空间**内存溢出

**常量池**  
二进制字节码的组成：类的基本信息、常量池、类的方法定义（包含了虚拟机指令）

**可通过反编译来查看类的信息**

*  获得对应类的.class文件  
    ♦在JDK对应的bin目录下运行cmd，也可以在IDEA控制台输入  
    ![在这里插入图片描述][20210427224629515.png]  
    ♦ 输入 javac 对应类的绝对路径

F:\JAVA\JDK8.0\bin>javac F:\Thread_study\src\com\nyima\JVM\day01\Main.java

输入完成后，对应的目录下就会出现类的.class文件

*  在控制台输入 javap -v .class类的绝对路径

javap -v F:\Thread_study\src\com\nyima\JVM\day01\Main.class

*  然后能在控制台看到反编译以后类的信息了

♦类的基本信息:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 4]  
♦常量池  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 5]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 6]  
♦虚拟机中执行编译的方法  
（框内的是真正编译执行的内容，\#号的内容需要在**常量池中查找**）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 7]

**运行时常量池**

1.  常量池  
    ♦就是一张表（如上图中的constant pool），虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量信息
2.  运行时常量池  
    ♦常量池是.class文件中的，当该**类被加载以后**，它的常量池信息就会放入运行时常量池，并把里面的**符号地址变为真实地址**

**常量池与串池的关系**  
*串池StringTable*  
特征

*  常量池中的字符串仅是符号，只有在**被用到时才会转化为对象**
 *  利用串池的机制，来**避免重复创建字符串对象**
 *  字符串**变量拼接**的原理是**StringBuilder**
 *  字符串**常量拼接**的原理是**编译器优化**
 *  可以使用**intern方法**，主动将串池中还没有的字符串对象放入串池中
 *  **注意**：无论是串池还是堆里面的字符串，都是对象

用来放字符串对象且里面的**元素不重复**

public class StringTableStudy { 
    	public static void main(String[] args) { 
    		String a = "a"; 
    		String b = "b";
    		String ab = "ab";
    	}
    }

常量池中的信息，都会被加载到运行时常量池中，但这是**a b ab** 仅是常量池中的符号，**还没有成为java字符串**

0: ldc           #2                  // String a
    2: astore_1
    3: ldc           #3                  // String b
    5: astore_2
    6: ldc           #4                  // String ab
    8: astore_3
    9: return

当执行到 ldc \#2 时，会把符号 a 变为 “a” 字符串对象，并放入串池中（hashtable结构 不可扩容）  
当执行到 ldc \#3 时，会把符号 b 变为 “b” 字符串对象，并放入串池中  
当执行到 ldc \#4 时，会把符号 ab 变为 “ab” 字符串对象，并放入串池中

最终**StringTable \[“a”, “b”, “ab”\]**

注意：字符串对象的创建都是懒惰的，只有当**运行**到那一行字符串**且在串池中不存在**的时候（如 ldc \#2）时，该**字符串才会被创建并放入串池中。**

【举例1】使用拼接字符串变量对象创建字符串的过程

public class StringTableStudy { 
    	public static void main(String[] args) { 
    		String a = "a";
    		String b = "b";
    		String ab = "ab";
    		//拼接字符串对象来创建新的字符串
    		String ab2 = a+b; 
    	}
    }

反编译后的结果

Code:
          stack=2, locals=5, args_size=1
             0: ldc           #2                  // String a
             2: astore_1
             3: ldc           #3                  // String b
             5: astore_2
             6: ldc           #4                  // String ab
             8: astore_3
             9: new           #5                  // class java/lang/StringBuilder
            12: dup
            13: invokespecial #6                  // Method java/lang/StringBuilder."<init>":()V
            16: aload_1
            17: invokevirtual #7                  // Method java/lang/StringBuilder.append:(Ljava/lang/String
    ;)Ljava/lang/StringBuilder;
            20: aload_2
            21: invokevirtual #7                  // Method java/lang/StringBuilder.append:(Ljava/lang/String
    ;)Ljava/lang/StringBuilder;
            24: invokevirtual #8                  // Method java/lang/StringBuilder.toString:()Ljava/lang/Str
    ing;
            27: astore        4
            29: return

通过拼接的方式来创建字符串的**过程**是：StringBuilder().append(“a”).append(“b”).toString()

最后的toString方法的返回值是一个新的字符串，但字符串的值和拼接的字符串一致，但是两个不同的字符串，**一个存在于串池之中，一个存在于堆内存（new 关键字）之中**

String ab = "ab";
    String ab2 = a+b;
    //结果为false,因为ab是存在于串池之中，ab2是由StringBuffer的toString方法所返回的一个对象，存在于堆内存之中
    System.out.println(ab == ab2);

--------------------

【举例2】使用拼接字符串常量对象的方法创建字符串

public class StringTableStudy { 
    	public static void main(String[] args) { 
    		String a = "a";
    		String b = "b";
    		String ab = "ab";
    		String ab2 = a+b;
    		//使用拼接字符串的方法创建字符串
    		String ab3 = "a" + "b";
    	}
    }

反编译后的结果

Code:
          stack=2, locals=6, args_size=1
             0: ldc           #2                  // String a
             2: astore_1
             3: ldc           #3                  // String b
             5: astore_2
             6: ldc           #4                  // String ab
             8: astore_3
             9: new           #5                  // class java/lang/StringBuilder
            12: dup
            13: invokespecial #6                  // Method java/lang/StringBuilder."<init>":()V
            16: aload_1
            17: invokevirtual #7                  // Method java/lang/StringBuilder.append:(Ljava/lang/String
    ;)Ljava/lang/StringBuilder;
            20: aload_2
            21: invokevirtual #7                  // Method java/lang/StringBuilder.append:(Ljava/lang/String
    ;)Ljava/lang/StringBuilder;
            24: invokevirtual #8                  // Method java/lang/StringBuilder.toString:()Ljava/lang/Str
    ing;
            27: astore        4
            //ab3初始化时直接从串池中获取字符串
            29: ldc           #4                  // String ab
            31: astore        5
            33: return

*  使用**拼接字符串常量**的方法来创建新的字符串时，因为**内容是常量**，**javac在编译期会进行优化**，结果已在编译期确定为ab，而创建ab的时候已经在串池中放入了“ab”，所以ab3直接从串池中获取值，所以进行的操作和 ab = “ab” 一致。
 *  使用**拼接字符串变量**的方法来创建新的字符串时，因为**内容是变量**，只能**在运行期确定它的值，所以需要使用StringBuilder来创建**

**intern方法 1.8**  
调用字符串对象的intern方法，会将该字符串对象尝试放入到串池中。

*  如果串池中没有该字符串对象，则放入成功
 *  如果有该字符串对象，则放入失败
 *  无论放入是否成功，都会返回**串池中**的字符串对象

**注意**：此时如果调用intern方法成功，堆内存与串池中的字符串对象是同一个对象；如果失败，则不是同一个对象

例1

public class Main { 
    	public static void main(String[] args) { 
    		//"a" "b" 被放入串池中，str则存在于堆内存之中
    		String str = new String("a") + new String("b");
    		//调用str的intern方法，这时串池中没有"ab"，则会将该字符串对象放入到串池中，此时堆内存与串池中的"ab"是同一个对象
    		String st2 = str.intern();
    		//给str3赋值，因为此时串池中已有"ab"，则直接将串池中的内容返回
    		String str3 = "ab";
    		//因为堆内存与串池中的"ab"是同一个对象，所以以下两条语句打印的都为true
    		System.out.println(str == st2);
    		System.out.println(str == str3);
    	}
    }

例2

public class Main { 
    	public static void main(String[] args) { 
            //此处创建字符串对象"ab"，因为串池中还没有"ab"，所以将其放入串池中
    		String str3 = "ab";
            //"a" "b" 被放入串池中，str则存在于堆内存之中
    		String str = new String("a") + new String("b");
            //此时因为在创建str3时，"ab"已存在与串池中，所以放入失败，但是会返回串池中的"ab"
    		String str2 = str.intern();
            //false
    		System.out.println(str == str2);
            //false
    		System.out.println(str == str3);
            //true
    		System.out.println(str2 == str3);
    	}
    }

**intern方法 1.6**  
调用字符串对象的intern方法，会将该字符串对象尝试放入到串池中

*  如果串池中没有该字符串对象，会将该字符串对象**复制一份**，再放入到串池中
 *  如果有该字符串对象，则放入失败
 *  无论放入是否成功，都会返回**串池中**的字符串对象

**注意**：此时无论调用intern方法成功与否，串池中的字符串对象和堆内存中的字符串对象**都不是同一个对象**

**StringTable 垃圾回收**  
StringTable在内存紧张时，会发生垃圾回收

**StringTable调优**

*  因为StringTable是由HashTable实现的，所以可以适当**增加HashTable桶**的个数，减少哈希碰撞来减少字符串放入串池所需要的时间

> \-XX:StringTableSize=xxxx

*  考虑是否需要将字符串对象入池  
    可以通过**intern方法减少重复入池**

## 6、直接内存 ##

*  属于操作系统，常见于NIO操作时，**用于数据缓冲区**
 *  分配回收成本较高，但读写性能高
 *  不受JVM内存回收管理

正常文件读写流程  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 8]  
使用了DirectBuffer  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 9]  
直接内存是操作系统和Java代码**都可以访问的一块区域**，无需将代码从系统内存复制到Java堆内存，从而提高了效率

**释放原理**  
直接内存的回收**不是通过JVM的垃圾回收**来释放的，而是通过unsafe.freeMemory来手动释放

//通过ByteBuffer申请1M的直接内存
    ByteBuffer byteBuffer = ByteBuffer.allocateDirect(_1M);

申请直接内存，但JVM并不能回收直接内存中的内容，它是如何实现回收的呢？

**allocateDirect的实现**

public static ByteBuffer allocateDirect(int capacity) { 
        return new DirectByteBuffer(capacity);
    }

DirectByteBuffer类

DirectByteBuffer(int cap) {    // package-private
        super(-1, 0, cap, cap);
        boolean pa = VM.isDirectMemoryPageAligned();
        int ps = Bits.pageSize();
        long size = Math.max(1L, (long)cap + (pa ? ps : 0));
        Bits.reserveMemory(size, cap);
    
        long base = 0;
        try { 
            base = unsafe.allocateMemory(size); //申请内存
        } catch (OutOfMemoryError x) { 
            Bits.unreserveMemory(size, cap);
            throw x;
        }
        unsafe.setMemory(base, size, (byte) 0);
        if (pa && (base % ps != 0)) { 
            // Round up to page boundary
            address = base + ps - (base & (ps - 1));
        } else { 
            address = base;
        }
        cleaner = Cleaner.create(this, new Deallocator(base, size, cap)); //通过虚引用，来实现直接内存的释放，this为虚引用的实际对象
        att = null;
    }

这里调用了一个Cleaner的create方法，且后台线程还会对虚引用的对象监测，如果虚引用的实际对象（这里是DirectByteBuffer）被回收以后，就会调用Cleaner的clean方法，来清除直接内存中占用的内存

public void clean() { 
           if (remove(this)) { 
               try { 
                   this.thunk.run(); //调用run方法
               } catch (final Throwable var2) { 
                   AccessController.doPrivileged(new PrivilegedAction<Void>() { 
                       public Void run() { 
                           if (System.err != null) { 
                               (new Error("Cleaner terminated abnormally", var2)).printStackTrace();
                           }
    
                           System.exit(1);
                           return null;
                       }
                   });
               }

对应对象的run方法

public void run() { 
        if (address == 0) { 
            // Paranoia
            return;
        }
        unsafe.freeMemory(address); //释放直接内存中占用的内存
        address = 0;
        Bits.unreserveMemory(size, capacity);
    }

**直接内存的回收机制总结**

*  使用了Unsafe类来完成直接内存的分配回收，回收需要主动调用freeMemory方法
 *  ByteBuffer的实现内部使用了Cleaner（虚引用）来检测ByteBuffer。一旦ByteBuffer被垃圾回收，那么会由ReferenceHandler来调用Cleaner的clean方法调用freeMemory来释放内存

# 三、垃圾回收 #

## 1、如何判断对象可以回收 ##

**引用计数法**  
弊端：循环引用时，两个对象的计数都为1，导致两个对象都无法被释放  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 10]  
**可达性分析算法**

*  JVM中的垃圾回收器通过可达性分析来探索所有存活的对象
 *  扫描堆中的对象，看能否沿着**GC Root对象为起点**的引用链找到该对象，如果找不到，则表示可以回收
 *  可以作为GC Root的对象  
    ♦虚拟机栈（栈帧中的本地变量表）中引用的对象。　  
    ♦方法区中类静态属性引用的对象  
    ♦方法区中常量引用的对象  
    ♦本地方法栈中JNI（即一般说的Native方法）引用的对象

**五种引用**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 11]

**1. 强引用**

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

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

**2. 软引用**

*  当GC Root指向软引用对象时，在**内存不足时**，会回收软引用所引用的对象  
    如上图如果B对象不再引用A2对象且内存不足时，软引用所引用的A2对象就会被回收

软引用的使用

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();
    		}
    	}
    }

**大概思路为**：查看引用队列中有无软引用，如果有，则将该软引用从存放它的集合中移除（这里为一个list集合）

**3. 弱引用**

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

如上图如果B对象不再引用A3对象，则A3对象会被回收弱引用的使用和软引用类似，只是将 SoftReference 换为了WeakReference

**4. 虚引用**

*  当虚引用对象所引用的对象被回收以后，虚引用对象就会被放入引用队列中，调用虚引用的方法
 *  虚引用的一个体现是释放直接内存所分配的内存，当引用的对象ByteBuffer被垃圾回收以后，虚引用对象Cleaner就会被放入引用队列中，然后调用Cleaner的clean方法来释放直接内存

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

**5. 终结器引用**

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

如上图，B对象不再引用A4对象。这是终结器对象就会被放入引用队列中，引用队列会根据它，找到它所引用的对象。然后调用被引用对象的finalize方法。调用以后，该对象就可以被垃圾回收了

**6. 引用队列**

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

## 2、垃圾回收算法 ##

**标记-清除**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 12]  
**定义**：标记清除算法顾名思义，是指在虚拟机执行垃圾回收的过程中，先采用标记算法确定可回收对象，然后垃圾收集器根据标识清除相应的内容，给堆内存腾出相应的空间

*  这里的腾出内存空间并不是将内存空间的字节清0，而是记录下这段内存的起始结束地址，下次分配内存的时候，会直接**覆盖**这段内存

**缺点**：容易产生大量的**内存碎片**，可能无法满足大对象的内存分配，一旦导致无法分配对象，那就会导致jvm启动gc，一旦启动gc，我们的应用程序就会暂停，这就导致应用的响应速度变慢

**标记-整理**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 13]  
标记-整理 会将不被GC Root引用的对象回收，清楚其占用的内存空间。然后整理剩余的对象，可以有效避免因内存碎片而导致的问题，但是因为整体需要消耗一定的时间，所以效率较低

**复制**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 14]

将内存分为等大小的两个区域，FROM和TO（TO中为空）。先将被GC Root引用的对象从FROM放入TO中，再回收不被GC Root引用的对象。然后交换FROM和TO。这样也可以避免内存碎片的问题，但是会占用双倍的内存空间。

## 3、分代回收 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 15]

**回收流程**  
新创建的对象都被放在了**新生代的伊甸园**中  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 16]  
当**伊甸园**中的内存不足时，就会进行一次垃圾回收，这时的回收叫做 **Minor GC**

*  Minor GC 会将伊甸园和幸存区FROM存活的对象先复制到 幸存区 TO中， 并让其寿命加1，再交换两个幸存区  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 17]  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 18]  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 19]
 *  再次创建对象，若新生代的伊甸园又满了，则会**再次触发 Minor GC**（会触发 stop the world，暂停其他用户线程，只让垃圾回收线程工作），这时不仅会回收伊甸园中的垃圾，还会回收幸存区中的垃圾，再将活跃对象复制到幸存区TO中。回收以后会交换两个幸存区，并让幸存区中的对象寿命加1

如果幸存区中的对象的**寿命超过某个阈值**（最大为15，4bit），就会被**放入老年代**中

如果新生代老年代中的内存都满了，就会**先触发Minor GC，再触发Full GC**，扫描新生代和老年代中所有不再使用的对象并回收

**GC 分析**  
**大对象处理策略**

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

**线程内存溢出**

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

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

## 4、垃圾回收器 ##

**4.1 相关概念**

*  并行收集：指多条垃圾收集线程并行工作，但此时**用户线程仍处于等待状态。**
 *  并发收集：指用户线程与垃圾收集线程同时工作（不一定是并行的可能会交替执行）。**用户程序在继续运行**，而垃圾收集程序运行在另一个CPU上
 *  吞吐量：即CPU用于**运行用户代码的时间**与CPU**总消耗时间**的比值（吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 )），也就是。例如：虚拟机共运行100分钟，垃圾收集器花掉1分钟，那么吞吐量就是99%

**4.2 串行**

*  单线程
 *  内存较小，个人电脑（CPU核数较少）  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 20]  
    **安全点**：让其他线程都在这个点停下来，以免垃圾回收时移动对象地址，使得其他线程找不到被移动的对象

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

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

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

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

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

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

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

**4.6 吞吐量优先**

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

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

**特点**：

*  属于新生代收集器也是采用复制算法的收集器（用到了新生代的幸存区），又是并行的多线程收集器（与ParNew收集器类似）
 *  该收集器的目标是达到一个可控制的吞吐量。还有一个值得关注的点是：**GC自适应调节策略**（与ParNew收集器最重要的一个区别）

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

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

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

**4.6.2 Parallel Old 收集器**  
是Parallel Scavenge收集器的老年代版本  
特点：多线程，采用\*\*标记-整理算法（\*\*老年代没有幸存区）

**4.7 响应时间优先**

*  多线程
 *  堆内存较大，多核CPU
 *  尽可能让单次STW时间变短（尽量不影响其他线程运行）  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 22]

**CMS 收集器**  
Concurrent Mark Sweep，一种以获取**最短回收停顿时间为目标**的**老年代**收集器  
**特点**：基于**标记-清除**算法实现。并发收集、低停顿，但是会产生内存碎片  
**应用场景**：适用于注重服务的响应速度，希望系统停顿时间最短，给用户带来更好的体验等场景下。如web程序、b/s服务

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

*  **初始标记**：标记GC Roots能直接到的对象。速度很快但是仍存在Stop The World问题
 *  **并发标记**：进行GC Roots Tracing 的过程，找出存活对象且用户线程可并发执行
 *  **重新标记**：为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。仍然存在Stop The World问题
 *  **并发清除**：对标记的对象进行清除回收

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

**4.8 G1**  
**4.8.1 定义**：Garbage First  
JDK 9以后默认使用，而且替代了CMS 收集器  
![在这里插入图片描述][20210507220802999.png]

**4.8.2 适用场景**

*  同时注重吞吐量和低延迟（响应时间）
 *  **超大堆内存**（内存大的），会将堆内存划分为多个大小相等的区域
 *  整体上是**标记-整理**算法，两个区域之间是**复制**算法

**4.8.3 相关参数**：JDK8 并不是默认开启的，所需要参数开启  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 23]  
**4.8.4 G1垃圾回收阶段**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 24]  
新生代伊甸园垃圾回收—–>内存不足，新生代回收+并发标记—–>回收新生代伊甸园、幸存区、老年代内存——>新生代伊甸园垃圾回收(重新开始)

**1.Young Collection**

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

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

*  会STW  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 25]  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 26]  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 27]  
    **2.Young Collection + CM**

CM：并发标记

*  在 Young GC 时会对 GC Root 进行**初始标记**
 *  在老年代占用堆内存的比例达到阈值时，对进行**并发标记**（不会STW），阈值可以根据用户来进行设定  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 28]

**3.Mixed Collection混合回收**

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

*  最终标记
 *  拷贝存活

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

**问**：为什么有的老年代被拷贝了，有的没拷贝？  
**答**：因为指定了最大停顿时间，如果对所有老年代都进行回收，耗时可能过高。为了保证时间不超过设定的停顿时间，**会回收最有价值的老年代**（回收后，能够得到更多内存）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 29]  
**4.Full GC**

G1在老年代内存不足时（老年代所占内存超过阈值）

*  如果垃圾产生速度慢于垃圾回收速度，不会触发Full GC，还是并发地进行清理
 *  如果垃圾产生速度快于垃圾回收速度，便会触发Full GC

**5.Young Collection 跨代引用**

*  新生代回收的跨代引用（老年代引用新生代）问题  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 30]
 *  卡表与Remembered Set  
    Remembered Set 存在于E中，用于保存新生代对象对应的脏卡  
    **脏卡**：O被划分为多个区域（一个区域512K），如果该区域引用了**新生代**对象，则该区域被称为脏卡
 *  在引用变更时通过post-write barried + dirty card queue
 *  concurrent refinement threads 更新 Remembered Set

**6.Remark**【…】  
重新标记阶段

在垃圾回收时，收集器处理对象的过程中  
黑色：已被处理，需要保留的 灰色：正在处理中的 白色：还未处理的  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 31]  
但是在**并发标记**过程中，有可能A被处理了以后未引用C，但该处理过程还未结束，在处理过程结束之前A引用了C，这时就会用到remark

过程如下

*  之前C未被引用，这时A引用了C，就会给C加一个写屏障，写屏障的指令会被执行，将C放入一个队列当中，并将C变为 处理中 状态
 *  在并发标记阶段结束以后，重新标记阶段会STW，然后将放在该队列中的对象重新处理，发现有强引用引用它，就会处理它  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 32]

**JDK 8u20 字符串去重**

**过程**

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

**优点与缺点**

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

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

**JDK 8u60 回收巨型对象**

*  一个对象大于region的一半时，就称为巨型对象
 *  G1不会对巨型对象进行拷贝
 *  回收时被优先考虑
 *  G1会跟踪老年代所有incoming引用，如果老年代incoming引用为0的巨型对象就可以在新生代垃圾回收时处理掉  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 33]

[Link 1]: https://nyimac.gitee.io/2020/07/03/JVM%E5%AD%A6%E4%B9%A0/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70]: /images/20221021/b29683de57bb483eae0cf75364f8a5b3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 1]: /images/20221021/99bdebc6ae3042989c0af07a7e066864.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 2]: /images/20221021/d8d297b0dfdd49d1a48bc30ad0442a0c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 3]: /images/20221021/d54bc56357ae481c9ef853b708904f94.png
[20210427224629515.png]: /images/20221021/632b18eba878472ebc8773c0265fb39f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 4]: /images/20221021/cc63a1e732dd40bd82815d5d3b8f3250.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 5]: /images/20221021/f832dd6c301b4d98b735390ac271b4c0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 6]: /images/20221021/9b461f9ad8a748769d2dbf8cd821ef4e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 7]: /images/20221021/77223b68efbc48ebb9686fae977d6163.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 8]: /images/20221021/8d27eed5369943aebc7f7021d4bcddf0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 9]: /images/20221021/d9e67c5e13d645e2bb8ef4f4df46a143.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 10]: /images/20221021/f581c8955e41432d9b5fe110936ec35b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 11]: /images/20221021/4f2e588ab88544f888b8bcb7d5ef51fc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 12]: /images/20221021/7c8acbef50964285ac67afd6a7514080.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 13]: /images/20221021/51bd79fde42e4e48a396ed44d47e1c61.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 14]: /images/20221021/1fc0379101b94f938ba5baab558770d7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 15]: /images/20221021/b6427b9b0afd4a989ca3fdee7ccecc06.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 16]: /images/20221021/fb3b09443ff543c2b6cb38e344f91bd9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 17]: /images/20221021/8379fd0cb32d4fdc95545700b96c6914.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 18]: /images/20221021/41e1a24142504d489b1f5f52ced4405c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 19]: /images/20221021/7e2e0b17169d447d96c0f6dfadcb94ed.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 20]: /images/20221021/e74def5fd1204b5b93d3794ff4e2adde.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 21]: /images/20221021/50d6c57f24be46459d0940ee6441c342.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 22]: /images/20221021/7f404514d58a45cca2235ad6c3f6434f.png
[20210507220802999.png]: /images/20221021/7a371b8630b34129b6ea459c47dad7b3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 23]: /images/20221021/454aac97d1b543bf84ddc06d334231b2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 24]: /images/20221021/cb7e77c7ac23436a8711c24913ae1d60.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 25]: /images/20221021/c47c967bf80e46d7adcaaa1a6b75af1d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 26]: /images/20221021/fbd68d7315cb4060b04d2a20e9ae616e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 27]: /images/20221021/d9cf4fc88b0e40f489decba59f4930e9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 28]: /images/20221021/53503a7fe9234477bdb5592ed101f0c3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 29]: /images/20221021/661831624cab42da922975a7bbfe78b4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 30]: /images/20221021/3d64b1fe034846b3848613d0a0ee574e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 31]: /images/20221021/d29f1540ebcd4fcbb8be1e1e428965f5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 32]: /images/20221021/693a057e2d054adca0c9f8cd6672edcd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODk2MTM2_size_16_color_FFFFFF_t_70 33]: /images/20221021/4c78eba6d15847d9b5d68a1f0d7e51f0.png