JVM学习笔记

最新推荐文章于 2024-06-13 08:37:22 发布

lllms

最新推荐文章于 2024-06-13 08:37:22 发布

阅读量409

点赞数

分类专栏：笔记文章标签： java JVM

本文链接：https://blog.csdn.net/lms18811338696/article/details/123721654

版权

笔记专栏收录该内容

33 篇文章 2 订阅

订阅专栏

JVM

2021.12.20
编辑器：Typora

0、目录

文章目录

1、概述

实现的大致步骤：

首先从java源代码编译成为class文件，然后经过类加载器ClassLoader才能被加载到JVM内存结构中。
类都是放在方法区，类创建的实例对象都是放在Heap堆中，而堆中对象在调用方法时会用到：虚拟机栈，程序计数器，本地方法栈。
方法执行时的每行代码是由执行引擎中的解释器逐行进行执行，方法中频繁被调用的代码会被JIT即时编译器进行优化执行，GC垃圾回收会将Heap堆中不再使用的实例对象进行回收。
但是还有一些java代码不方便实现的功能，会调用本地方法接口去和底层操作系统进行交互。

2、内存结构

2.1、程序计数器

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fjcV7js3-1648127306114)(C:\Users\lms\Desktop\md\jvm\程序计数器1.png)]

图中的jvm指定不能直接交给cpu进行执行，必须先经过解释器将指令解析成为机器码，才能将其交给cpu进行执行。

而程序计数器就是用来记录下一条要执行的jvm指令的地址

特点:

线程私有
CPU会为每个线程分配时间片，当当前线程的时间片使用完以后，CPU就会去执行另一个线程中的代码，与此同时，当前线程的程序计数器会记录当前线程已经执行到的位置，等分到时间片之后再接着执行。
程序计数器是每个线程所私有的，当另一个线程的时间片用完，又返回来执行当前线程的代码时，通过程序计数器可以知道应该执行哪一句指令。

不会存在内存溢出

2.2、虚拟机栈

定义：

每个线程运行需要的内存空间，成为虚拟机栈
每个栈有多个栈帧组成，对应着每次调用方法时所占用的内存
栈帧可能包含有：方法参数，局部变量，返回的额地址等

每个线程只能有一个活动栈帧，对应着当前正在执行的方法

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-64o5SjYJ-1648127306115)(C:\Users\lms\Desktop\md\jvm\栈.png)]

问题辨析

垃圾回收是否涉及栈内存？
不需要。因为虚拟机栈中是由一个个栈帧组成的，在方法执行完毕后，对应的栈帧就会被弹出栈。所以无需通过垃圾回收机制去回收内存。垃圾回收主要用来处理堆中的实例对象。

栈内存的分配越大越好吗？
不是。因为物理内存是一定的，栈内存越大，可以支持更多次的递归调用，但是可执行的线程数就会越少，不推荐设置，使用默认即可。

方法内的局部变量是否是线程安全的？
变量是否被多个线程所共有
如果方法内局部变量没有逃离方法的作用范围，则是线程安全的
如果如果局部变量引用了对象，并逃离了方法的作用范围，则需要考虑线程安全问题

内存溢出

Java.lang.stackOverflowError 栈内存溢出

发生原因

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

线程运行诊断

CPU占用过高

Linux环境下运行某些程序的时候，可能导致CPU的占用过高，这时需要定位占用CPU过高的线程
top命令，查看是哪个进程占用CPU过高
ps H -eo pid, tid（线程id）, %cpu | grep 刚才通过top查到的进程号 通过ps命令进一步查看是哪个线程占用CPU过高
jstack 进程id 通过查看进程中的线程的nid，刚才通过ps命令看到的tid来对比定位，注意jstack查找出的线程id是16进制的，需要转换

2.3、本地方法栈

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

2.4、堆

2.4.1 定义

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

2.4.2 特点

所有线程共享，堆内存中的对象都需要考虑线程安全问题
有垃圾回收机制(堆中的对象如果没有在被引用，那么会被回收)

2.4.3 堆内存溢出

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

2.4.4 堆内存诊断(工具)

jps

jmap

jconsole

jvirsalvm

2.5、方法区

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fQOZPZwp-1648127306115)(C:\Users\lms\Desktop\md\jvm\方法区.png)]

2.5.1 内存溢出

1.8以前会导致永久代内存溢出

1.8以后会导致元空间内存溢出

1.6之前方法区是通过永久代实现的。

1.8之后使用的是元空间实现。

2.5.2 常量池

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

2.5.3 运行时常量池

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

2.5.4 常量池与串池的关系

串池StringTable

特征

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

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

// 串池：["a", "b", "ab"] 
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

# 上面java代码执行的过程：
1. 当执行到 ldc #2 时，会把符号 a 变为 “a” 字符串对象，并放入串池中（hashtable结构 不可扩容）

2. 当执行到 ldc #3 时，会把符号 b 变为 “b” 字符串对象，并放入串池中

3. 当执行到 ldc #4 时，会把符号 ab 变为 “ab” 字符串对象，并放入串池中

- 最终串池中的内容为StringTable: [“a”, “b”, “ab”]

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

2.5.4.1 使用拼接字符串变量对象创建字符串的过程

public class StringTableStudy {
	public static void main(String[] args) {
		String a = "a";
		String b = "b";
		String ab = "ab";  // 执行完这一行后，串池中["a", "b", "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
# 通过拼接的方式来创建字符串的过程是：StringBuilder().append(“a”).append(“b”).toString()

# 最后的toString方法的返回值是一个新的字符串(String)，但字符串的值和拼接的字符串一致，但这是两个不同的字符串，一个存在于串池之中，一个存在于堆内存之中(ab2)
# 这里可以从 反编译的 第9行开始看到，显示new一个StringBuilder对象，然后在第13进行初始化，21，24进行append，最后使用toString()

案例分析

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

2.5.4.2 使用拼接字符串常量对象创建字符串的过程

public class StringTableStudy {
    public static void main(String[] args) {
        String a = "a";
        String b = "b";
        String ab = "ab";  // 串池["a","b","ab"]  
        String ab2 = a + b;  // 使用拼接字符串变量创建字符串，会存放在堆内存当中
        //使用拼接字符串的方法创建字符串
        String ab3 = "a" + "b";  // 使用拼接字符串常量进行创建字符串，会直接从串池中拿去 "ab"
    }
}

反编译后的结果

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在编译期会进行优化，ab3的结果已在编译期确定值为变量ab的内容，而创建ab变量的时候已经在串池中放入了“ab”，所以ab3直接从串池中获取值，所以进行的操作和 ab = “ab” 一致。

# 使用拼接字符串变量的方法来创建新的字符串时，因为内容是变量，只能在运行期确定它的值，所以需要使用StringBuilder来创建

最终结论

# 使用拼接字符串常量的方法来创建新的字符串时: 编译期会进行优化，确定值

# 使用拼接字符串变量的方法来创建新的字符串时: 运行期确定值

案例分析

String ab = "ab";
String ab3 = "a" + "b";
//结果为true,使用的是拼接字符串常量创建字符串，会在编译期进行优化，直接从串池中进行获取，所以引用的是同一个常量值
System.out.println(ab == ab3); // true

2.5.4.3 intern 1.8

# 调用字符串对象的intern方法，会将该字符串对象尝试放入到串池中:
	1. 如果串池中没有该字符串对象，则放入成功
	2. 如果有该字符串对象，则放入失败
	3. 无论放入是否成功，都会返回串池中的字符串对象

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

例1

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

例2

// 串池["ab", "a", "b"]     堆："ab"
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);
    }
}

2.5.4.4 intern 1.6

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

# 如果串池中没有该字符串对象，会将该字符串对象复制一份，再放入到串池中
# 如果有该字符串对象，则放入失败

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

StringTable 垃圾回收

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

StringTable调优

因为StringTable是由HashTable实现的，所以可以适当增加HashTable桶的个数，来减少字符串放入串池所需要的时间
-XX:StringTableSize=xxxx

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

2.6 直接内存

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

2.6.1 原理图

文件读写流程

- 解析: 在没有使用直接内存的时候，要读取磁盘中的文件，那么系统内存要先从磁盘中读取文件，然后java堆内存又从系统内存中读取相应的内容，最后才被内核态读取，那么在堆内存和系统内存交换的过程中，会造成时间消耗。

使用直接内存DirectBuffer

- 会在堆内存和系统内存中创建一个共享的内存空间，这样子，CPU就可以直接从Direct Memory中读取，解决解决了时间的消耗。
# 直接内存是操作系统和Java代码都可以访问的一块区域，无需将代码从系统内存复制到Java堆内存，从而提高了效率

2.6.2 释放原理

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

# 1. 通过ByteBuffer申请1M的直接内存

[ByteBuffer byteBuffer = ByteBuffer.allocateDirect(_1M);]

# 2. 申请直接内存，但JVM并不能回收直接内存中的内容，它是如何实现回收的呢？
# 3. 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);
}

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

# 使用了Unsafe类来完成直接内存的分配回收，回收需要主动调用freeMemory方法

# ByteBuffer的内部实现了使用Cleaner（虚引用）来检测ByteBuffer。一旦ByteBuffer被垃圾回收，那么会由ReferenceHandler来调用Cleaner的clean方法调用freeMemory来释放内存

3、垃圾回收

3.1 如何判断对象可以回收

3.1.1 引用计数法

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

3.1.2 可达性分析算法

# JVM中的垃圾回收器通过可达性分析来探索所有存活的对象

# 扫描堆中的对象，看能否沿着GC Root对象为起点的引用链找到该对象，如果找不到，则表示可以回收

# 可以作为GC Root的对象:
	- 虚拟机栈（栈帧中的本地变量表）中引用的对象。　
	- 方法区中类静态属性引用的对象
	- 方法区中常量引用的对象
	- 本地方法栈中JNI（即一般说的Native方法）引用的对象

3.1.3 五种引用

# 实线表示强引用
# 其他为：软引用，弱引用，虚引用，终结器引用

3.1.3.1 强引用

# 只有GC Root都不引用该对象时，才会回收强引用对象,如上图B、C对象都不引用A1对象时，A1对象才会被回收.

3.1.3.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.1.3.3 弱引用

# 只有弱引用引用该对象时，只要出现垃圾回收，无论内存是否充足，都会回收弱引用所引用的对象，如上图如果B对象不再引用A3对象，则A3对象会被回收

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

# 软引用和弱引用的区别：（出现垃圾回收时）
	1. 只有在内存空间不足的情况下，才会去回收弱引用。
	2. 无论内存是否充足，弱引用都会别回收。

3.1.3.4 虚引用

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

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

3.1.3.5 终结器引用

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

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

3.1.3.6 引用队列

# 软引用和弱引用可以配合引用队列
	- 在弱引用和虚引用所引用的对象被回收以后，会将这些引用放入引用队列中，方便一起回收这些软/弱引用对象

# 虚引用和终结器引用必须配合引用队列
	- 虚引用和终结器引用在使用时会关联一个引用队列

3.2 垃圾回收算法

3.2.1 标记-清除法

定义

标记清除算法*顾名思义，是指在虚拟机执行垃圾回收的过程中，先采用标记算法确定可回收对象，然后垃圾收集器根据标识清除相应的内容，给堆内存腾出相应的空间
这里的腾出内存空间并不是将内存空间的字节清0，而是记录下这段内存的起始结束地址，下次分配内存的时候，会直接覆盖这段内存

缺点：

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

3.2.2 标记-整理法

会将不被GC Root引用的对象回收，清除其占用的内存空间。然后整理剩余的对象，可以有效避免因内存碎片而导致的问题，但是因为整体需要消耗一定的时间，所以效率较低

3.2.3 复制法

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

3.3 分代垃圾回收

3.3.1 回收流程

新创建的对象都被放在了新生代的伊甸园中

当伊甸园中的内存不足时，就会进行一次垃圾回收，这时的回收叫做 Minor GC
Minor GC 会将伊甸园和幸存区FROM存活的对象先复制到 幸存区 TO中，并让其寿命加1，再交换两个幸存区

再次创建对象，若新生代的伊甸园又满了，则会再次触发 Minor GC（会触发 stop the world，暂停其他用户线程，只让垃圾回收线程工作），这时不仅会回收伊甸园中的垃圾，还会回收幸存区中的垃圾，再将活跃对象复制到幸存区TO中。回收以后会交换两个幸存区，并让幸存区中的对象寿命加1

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

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

3.3.2 GC分析

大对象处理策略

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

线程内存溢出(OOM)

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

3.4 垃圾回收器

3.4.1 相关概念

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

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

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

3.4.2 串行

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

开启串行垃圾回收的命令：

Serial：工作在新生代（复制）
SerialOld：老年代（标志整理算法）

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

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

3.4.2.1 Serial 收集器

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

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

3.4.2.2 ParNew 收集器

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

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

3.4.2.3 Serial Old 收集器

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

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

3.4.3 吞吐量优先

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

3.4.3.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 直接设置吞吐量的大小

3.4.3.2 Parallel Old 收集器

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

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

3.4.4 响应时间优先

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

3.4.4.1 CMS 收集器

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

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

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

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

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

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

3.4.5 G1

定义：

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

适用场景

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

相关参数：JDK8 并不是默认开启的，所需要参数开启

3.4.5.1 G1垃圾回收阶段

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

3.4.5.2 Young Collection

新生代的垃圾回收

分区算法region

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

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

会STW

新生成的对象会放置在伊甸园中，出现了新生代的垃圾回收，部分对象被回收，一部分转到幸存区，发生幸存区的垃圾回收时，部分幸存区对象会升到老年代，没到年龄的幸存区对象继续转到下一个幸存区。

3.4.5.3 Young Collection + CM

CM：并发标记

在 Young GC （新生代垃圾回收）时会对 GC Root 进行初始标记
在老年代占用堆内存的比例达到阈值时，对其进行并发标记（不会STW），阈值大小用户可以根据实际情况来进行设定

3.4.5.4 Mixed Collection

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

最终标记
拷贝存活

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

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

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

3.4.5.5 Full GC

SerialGC
- 新生代内存不足发生的垃圾回收 — minor gc
- 老年代内存不足发生的垃圾回收 — full gc
ParallelGC
- 新生代内存不足发生的垃圾回收 — minor gc
- 老年代内存不足发生的垃圾回收 — full gc
CMS
- 新生代内存不足发生的垃圾回收 — minor gc
- 老年代内存不足
G1
- 新生代内存不足发生的垃圾回收 — minor gc
- 老年代内存不足

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

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

3.4.5.6 Young Collection 跨代引用

新生代回收的跨代引用（老年代引用新生代）问题

卡表与Remembered Set
- Remembered Set 存在于E（伊甸园）中，用于保存新生代对象对应的脏卡
  - 脏卡：O（老年代）被划分为多个区域（一个区域512K），如果该区域引用了新生代对象，则该区域被称为脏卡。
在引用变更时通过post-write barried（写屏障） + dirty card queue（脏卡队列）
concurrent refinement threads 更新 Remembered Set

3.4.5.7 Remark

重新标记阶段

在垃圾回收时，收集器处理对象的过程中
黑色：已被处理，需要保留的灰色：正在处理中的白色：还未处理的

但是在并发标记过程中，有可能A被处理了以后还未引用C（也就是C最后会被A引用，但是刚开始的时候A并未引用它），而该处理过程还未结束，在处理过程结束之前A引用了C，这时就会用到remark。

过程如下：

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

3.4.5.8 JDK 8u20 字符串去重

开启设置：-XX: +UseStringDeduplication 默认开启
在该jdk的这个版本中，添加了字符串去重的功能

String s1 = new String("hello"); // 底层使用的是字符数组: char[] = {'h','e','l','l','o'}
String s2 = new String("hello"); // char[] = {'h','e','l','l','o'}

过程

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

优点与缺点:

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

3.4.5.8 JDK 8u40 并发标记类卸载

在并发标记阶段结束以后，就能知道哪些类不再被使用。如果一个类加载器的所有类都不在使用，则卸载它所加载的所有类
开启参数设置：-XX: ClassUnloadingWithConcurrentMark 默认开启

3.4.5.9 JDK 8u60 回收巨型对象

一个对象大于region的一半时，就称为巨型对象
G1不会对巨型对象进行拷贝
回收时被优先考虑
G1会跟踪老年代所有 incoming 引用，如果老年代 incoming 引用为0的巨型对象就可以在新生代垃圾回收时处理掉

3.5 垃圾回收调优

查看虚拟机参数的命令：

"C:\Program Files\Java\jdk1.8.0_60\bin\java" -XX:+PrintFlagsFinal -version | findstr "GC"

结果：

uintx AdaptiveSizeMajorGCDecayTimeScale         = 10                  {product}
uintx AutoGCSelectPauseMillis                   = 5000                {product}
bool BindGCTaskThreadsToCPUs                   = false                {product}
uintx CMSFullGCsBeforeCompaction                = 0                   {product}
uintx ConcGCThreads                             = 0                   {product}
bool DisableExplicitGC                         = false                {product}
bool ExplicitGCInvokesConcurrent               = false                {product}
bool UseParallelGC                            := true                 {product}
bool UseParallelOldGC                          = true                 {product}
bool UseSerialGC                               = false                {product}
.........
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

预备知识:

掌握GC相关的VM参数，会基本的空间调整
掌握相关的工具
明白一点：调优跟应用、环境有关，没有放之四海而皆准的法则

3.5.1 调优领域

内存
锁竞争
CPU占用
IO
GC

3.5.2 确定目标

【低延迟】还是【高吞吐量】？选择合适的GC回收器。

CMS 、G1、 ZGC （低延迟，响应时间优先）
ParallelGC （高吞吐量）
Zing

# 1. 如果是科学运算，追求的是高吞吐量，相对来说，对于响应时间不是特别关心，此时追求的就是高吞吐量的垃圾回收器。

# 2. 如果是互联网项目，那么响应时间就是一个非常重要的一个指标，因为每次进行垃圾回收延长了响应时间，就可能会给用户带来不好的体验。

3.5.3 最快的GC是不发生GC

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

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

3.5.4 新生代调优

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

3.5.5 幸存区调优

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

4、类加载与字节码技术

实现的大致步骤：

首先从java源代码编译成为class文件，然后经过类加载器ClassLoader才能被加载到JVM内存结构中。
类都是放在方法区，类创建的实例对象都是放在Heap堆中，而堆中对象在调用方法时会用到：虚拟机栈，程序计数器，本地方法栈。
方法执行时的每行代码是由执行引擎中的解释器逐行进行执行，方法中频繁被调用的代码会被JIT即时编译器进行优化执行，GC垃圾回收会将Heap堆中不再使用的实例对象进行回收。
但是还有一些java代码不方便实现的功能，会调用本地方法接口去和底层操作系统进行交互。