JVM入门

什么是JVM

定义

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

好处

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

内存结构

1、程序计数器

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

特点

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

2、虚拟机栈

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

问题辨析

垃圾回收是否涉及栈内存？

不需要。因为虚拟机栈中是由一个个栈帧组成的，在方法执行完毕后，对应的栈帧就会被弹出栈。所以无需通过垃圾回收机制去回收内存。

栈内存的分配越大越好吗？

不是。因为物理内存是一定的，栈内存越大，可以支持更多的递归调用，但是可执行的线程数就会越少。

方法内的局部变量是否是线程安全的？

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

内存溢出

Java.lang.stackOverflowError 栈内存溢出

发生原因

虚拟机栈中，栈帧过多（无限递归）
每个栈帧所占用过大
线程运行诊断
CPU占用过高

3、本地方法栈

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

4、堆

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

特点

所有线程共享，堆内存中的对象都需要考虑线程安全问题
有垃圾回收机制
堆内存溢出
java.lang.OutofMemoryError ：java heap space. 堆内存溢出

堆内存诊断

jps
jmap
jconsole
jvirsalvm

5、方法区

内存溢出

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

常量池

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

常量池

就是一张表（如上图中的constant pool），虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量信息

运行时常量池

常量池是.class文件中的，当该类被加载以后，它的常量池信息就会放入运行时常量池，并把里面的符号地址变为真实地址

串池StringTable

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

Jdk1.8


Jdk1.6

Jdk1.8 串池（StringTable）从方法区（永久代）移到堆中
Jdk1.6 运行时常量池（永久代）字符串常量池（永久代）
Jdk1.8 运行时常量池（元空间）串池（堆）

6、直接内存

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

文件读写流程

使用了DirectBuffer

直接内存是操作系统和Java代码都可以访问的一块区域，无需将代码从系统内存复制到Java堆内存，从而提高了效率

垃圾回收

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

引用计数法

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

可达性分析算法

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

五种引用

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

软引用
当GC Root指向软引用对象时，在内存不足时，会回收软引用所引用的对象
如果在垃圾回收时发现内存不足，在回收软引用所指向的对象时，软引用本身不会被清理
如果想要清理软引用，需要使用引用队列
大概思路为：查看引用队列中有无软引用，如果有，则将该软引用从存放它的集合中移除（这里为一个list集合）

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

虚引用

软引用和弱引用可以配合引用队列

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

虚引用和终结器引用在使用时会关联一个引用队列

2、垃圾回收算法

标记-清除

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

这里的腾出内存空间并不是将内存空间的字节清0，而是记录下这段内存的起始结束地址，下次分配内存的时候，会直接覆盖这段内存
缺点：容易产生大量的内存碎片，可能无法满足大对象的内存分配，一旦导致无法分配对象，那就会导致jvm启动gc，一旦启动gc，我们的应用程序就会暂停，这就导致应用的响应速度变慢

标记-整理

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

复制

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

3、分代回收

回收流程

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

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

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

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

4、垃圾回收器

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

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

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

4.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收集器的老年代版本
特点：同样是单线程收集器，采用标记-整理算法

4.2、吞吐量优先

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

Parallel Scavenge 收集器

与吞吐量关系密切，故也称为吞吐量优先收集器
特点：属于新生代收集器也是采用复制算法的收集器（用到了新生代的幸存区），又是并行的多线程收集器（与ParNew收集器类似）

Parallel Old 收集器

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

4.3、响应时间优先

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

CMS 收集器

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

特点：

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

应用场景：

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

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

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

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

G1收集器

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

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

适用场景

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

Young Collection (会STW)
(分区算法region)

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

Young Collection + CM(并发标记)

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

Mixed Collection

会对E S O 进行全面的回收：
最终标记
拷贝存活

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

Full GC

G1在老年代内存不足时（老年代所占内存超过阈值）
如果垃圾产生速度慢于垃圾回收速度，不会触发Full GC，还是并发地进行清理
如果垃圾产生速度快于垃圾回收速度，便会触发Full GC

Young Collection 跨代引用（老年代引用新生代）

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

Remark

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

但是在并发标记过程中，有可能A被处理了以后未引用C，但该处理过程还未结束，在处理过程结束之前A引用了C，这时就会用到remark

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

类加载与字节码技术

类加载阶段

加载，连接，初始化

加载

将类的字节码载入方法区（1.8后为元空间，在本地内存中）中，内部采用 C++ 的 instanceKlass 描述 java 类，它的重要 field 有：
_java_mirror 即 java 的类镜像，例如对 String 来说，它的镜像类就是 String.class，作用是把 klass 暴露给 java 使用
_super 即父类
_fields 即成员变量
_methods 即方法
_constants 即常量池
_class_loader 即类加载器
_vtable 虚方法表
_itable 接口方法

如果这个类还有父类没有加载，先加载父类
加载和链接可能是交替运行的

InstanceKlass和*.class(JAVA镜像类)互相保存了对方的地址
类的对象在对象头中保存了*.class的地址。让对象可以通过其找到方法区中的instanceKlass，从而获取类的各种信息

连接

验证
验证类是否符合 JVM规范，安全性检查
准备
为 static 变量分配空间，设置默认值
static变量在JDK 7以前是存储与instanceKlass末尾。但在JDK 7以后就存储在_java_mirror末尾了
static变量在分配空间和赋值是在两个阶段完成的。分配空间在准备阶段完成，赋值在初始化阶段完成
如果 static 变量是 final 的基本类型，以及字符串常量，那么编译阶段值就确定了，赋值在准备阶段完成
如果 static 变量是 final 的，但属于引用类型，那么赋值也会在初始化阶段完成
解析
将常量池中的符号引用解析为直接引用

初始化

初始化阶段就是执行类构造器clinit()方法的过程，虚拟机会保证这个类的『构造方法』的线程安全
clinit()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的
注意
编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问，如

发生时机

—类的初始化的懒惰的，以下情况会初始化

main 方法所在的类，总会被首先初始化
首次访问这个类的静态变量或静态方法时
子类初始化，如果父类还没初始化，会引发
子类访问父类的静态变量，只会触发父类的初始化
Class.forName
new 会导致初始化

—以下情况不会初始化

访问类的 static final 静态常量（基本类型和字符串）
类对象.class 不会触发初始化
创建该类对象的数组
类加载器的.loadClass方法
Class.forNamed的参数2为false时
验证类是否被初始化，可以看改类的静态代码块是否被执行

类加载器

Java虚拟机设计团队有意把类加载阶段中的“通过一个类的全限定名来获取描述该类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需的类。实现这个动作的代码被称为“类加载器”（ClassLoader）

类与类加载器

类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远超类加载阶段

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话可以表达得更通俗一些：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等

启动类加载器

可通过在控制台输入指令，使得类被启动类加器加载

拓展类加载器

如果classpath和JAVA_HOME/jre/lib/ext 下有同名类，加载时会使用拓展类加载器加载。当应用程序类加载器发现拓展类加载器已将该同名类加载过了，则不会再次加载

双亲委派模式

双亲委派模式，即调用类加载器ClassLoader 的 loadClass 方法时，查找类的规则

首先查找该类是否已经被该类加载器加载过了
如果没有被加载过
看是否被它的上级加载器加载过了，如果没有
看是否被启动类加载器加载过
如果还是没有找到，先让拓展类加载器调用findClass方法去找到该类，如果还是没找到，就抛出异常
然后让应用类加载器去找classpath下找该类