Java基础知识——JVM

红太狼 2023-03-13 06:08 1阅读 0赞

### 简介 ###

**JVM 是可运行 Java 代码的假想计算机，包括一套字节码指令集、一组寄存器、一个栈、一个垃圾回收，堆和一个存储方法域。JVM 是运行在操作系统之上的，它与硬件没有直接的交互**。运行过程： Java 源文件通过编译器，能够生产相应的.Class 文件，也就是字节码文件，而字节码文件又通过 Java 虚拟机中的解释器，编译成特定机器上的机器码 。即：**Java 源文件—>编译器—>字节码文件—>JVM—>机器码**，每种平台的解释器不同，但虚拟机相同，这就是Java能跨平台的原因，每个程序启动就会有一个相应的虚拟机实例，和程序的生命周期相同，随着程序的启动 / 结束而创建 / 销毁，且每个虚拟机间数据不共享  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70]

#### 虚拟机和物理机的区别 ####

这两种机器都有代码执行的能力，但是：

*  **物理机的执行引擎是直接建立在处理器、硬件、指令集和操作系统层面的**
 *  **虚拟机的执行引擎是自己实现的，因此可以自行制定指令集和执行引擎的结构体系，并且能够执行那些不被硬件直接支持的指令集格式**

#### JDK、JRE与JVM之间的区别 ####

*  **JDK全程为Java SE Development Kit（Java开发工具），提供了编译和运行Java程序所需的各种资源和工具，包括：JRE+java开发工具(javac、jps、jmap等)**
 *  **JRE全称为Java runtime environment（Java运行环境），包括：虚拟机+java的核心类库**
 *  **JVM是运行Java程序的核心虚拟机**

详细如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 1]

#### 常见Java虚拟机 ####

*  **Sun Classic VM**：已经淘汰，是世界上第一款商用虚拟机，只能使用纯解释器的方法来执行Java代码
 *  **Exact VM**：Exact Memory Management 准确式内存管理，编译器和解释器混合工作以及两级即时编译器
 *  **HotSpot VM**：**热点代码技术，使用最多的虚拟机产品，并非由Sun公司开发。官方JDK均采用HotSpot VM**
 *  **KVM**：kilobyte 简单、轻量、高度可移植，在手机平台运行，运行速度慢
 *  **JRockit**：BEA公司开发，是世界上最快的Java虚拟机，专注于服务端应用，全部靠编译器执行
 *  **J9**：IBM开发 原名：IBM Techn0ology for Java Virtual Machine IT4j
 *  **Davik**：不是java虚拟机，寄存器架构而不是栈结构，执行dex（dalvik Executable）文件
 *  **Microsoft JVM**：只能运行在windows下面
 *  **Azul VM Liquid VM**：高性能的java虚拟机，在HotSpot基础上改进，专用的虚拟机
 *  **Taobao VM**：淘宝公司开发

### JVM内存区域 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 2]  
**JVM 内存区域主要分为线程私有区域【程序计数器、虚拟机栈、本地方法区】、线程共享区域【JAVA 堆、方法区】、直接内存**

*  **线程私有数据区域生命周期与线程相同，依赖用户线程的启动 / 结束而创建 / 销毁**，在 Hotspot VM内，每个线程都与操作系统的本地线程直接映射， 因此这部分内存区域的存/否跟随本地线程的生/死对应
 *  **线程共享区域随虚拟机的启动 / 关闭而创建 / 销毁**
 *  **直接内存是操作系统直接的内存，并不是 JVM 运行时数据区的一部分，但也会被频繁的使用**。例如：在 JDK 1.4 引入的 NIO  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 3]

#### 程序计数器(线程私有) ####

**一块较小的内存空间, 是当前线程所执行的字节码的行号指示器，每条线程都要有一个独立的程序计数器，这类内存也称为“线程私有”的内存。正在执行 java 方法的话，计数器记录的是虚拟机字节码指令的地址（当前指令的地址）**。如果还是 Native 方法，则为空。这个内存区域是唯一一个在虚拟机中没有规定任何 OutOfMemoryError 情况的区域

#### 虚拟机栈(线程私有) ####

**是描述java方法执行的内存模型，每个方法在执行的同时都会创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息**。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程  
**栈帧（ Frame）是用来存储数据和部分过程结果的数据结构，同时也被用来处理动态链接(Dynamic Linking)、 方法返回值和异常分派（ Dispatch Exception）**。栈帧随着方法调用而创建，随着方法结束而销毁——无论方法是正常完成还是异常完成（抛出了在方法内未被捕获的异常）都算作方法结束

#### 本地方法区(线程私有) ####

**本地方法区和 Java Stack 作用类似，区别是虚拟机栈为执行 Java 方法服务，而本地方法栈则为Native 方法服务**，如果一个 VM 实现使用 C-linkage 模型来支持 Native 调用，那么该栈将会是一个 C 栈，但 HotSpot VM 直接就把本地方法栈和虚拟机栈合二为一

#### 堆（线程共享）运行时数据区 ####

是被**线程共享的一块内存区域**，创建的对象和数组都保存在 Java 堆内存中，也是垃圾收集器进行垃圾收集的最重要的内存区域。由于现代 VM 采用分代收集算法，因此 Java 堆从 GC 的角度还可以细分为: 新生代(Eden 区、From Survivor 区和 To Survivor 区)和老年代

#### 方法区 / 永久代（线程共享） ####

**即我们常说的永久代(Permanent Generation)，用于存储被 JVM 加载的类信息、常量、静态变量、即时编译器编译后的代码等数据**。HotSpot VM把GC分代收集扩展至方法区，即使用Java堆的永久代来实现方法区(注：**方法区是一个规范，永久代是实现方法，它们的关系类似于接口与实现类**)，这样 HotSpot 的垃圾收集器就可以像管理 Java 堆一样管理这部分内存，而不必为方法区开发专门的内存管理器(永久带的内存回收的主要目标是针对常量池的回收和类型的卸载, 因此收益一般很小)  
**运行时常量池（Runtime Constant Pool）是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述等信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中**。 Java 虚拟机对 Class 文件的每一部分（自然也包括常量池）的格式都有严格的规定，每一个字节用于存储哪种数据都必须符合规范上的要求，这样才会被虚拟机认可、装载和执行

### Java对象 ###

#### 对象的创建 ####

一个对象的创建过程：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 4]

#### 对象的结构 ####

##### Header（对象头） #####

自身运行时数据（32位~64位 MarkWord）：**哈希值**、**GC分代年龄**、**锁状态标志**、**线程持有锁**、**偏向线程ID**、**偏向时间戳**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 5]

##### 类型指针（什么类的实例） #####

**InstanceData**：数据实例，即对象的有效信息，相同宽度（如long和double）的字段被分配在一起，父类属性在子类属性之前  
**Padding**：占位符填充内存

#### 对象的访问定位 ####

对象的访问定位有两种方式：**句柄访问**和**直接指针访问**

##### 句柄访问 #####

Java堆中会划分出一块内存来作为句柄池，引用变量中存储的就是对象的句柄地址，而句柄中包含了对象实例数据和类型数据各自的具体地址信息。一个句柄又包含了两个地址，一个对象实例数据，一个是对象类型数据(这个在方法区中，因为类字节码文件就放在方法区中)

##### 直接指针访问 #####

引用变量中存储的就直接是对象地址了，在堆中不会分句柄池，直接指向了对象的地址，对象中包含了对象类型数据的地址。**HotSpot采用直接定位**

### JVM 运行时内存 ###

Java 堆从 GC 的角度还可以细分为: **新生代**(Eden 区、From Survivor 区和 To Survivor 区)和**老年代**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 6]

#### 新生代 ####

**是用来存放新生的对象**。一般占据堆的 1/3 空间。由于频繁创建对象，所以新生代会频繁触发MinorGC 进行垃圾回收。新生代又分为 **Eden** 区、**ServivorFrom**、**ServivorTo** 三个区

##### Eden 区 #####

**Java 新对象的出生地**（如果新创建的对象占用内存很大，则直接分配到老年代）。当 Eden 区内存不够的时候就会触发 MinorGC，对新生代区进行一次垃圾回收

##### ServivorFrom #####

上一次 GC 的幸存者，作为这一次 GC 的被扫描者

##### ServivorTo #####

保留了一次 MinorGC 过程中的幸存者

##### MinorGC 的过程（复制->清空->互换） #####

MinorGC 采用复制算法:

*  **eden、servicorFrom 复制到 ServicorTo，年龄+1**  
    首先，把 Eden 和 ServivorFrom 区域中存活的对象复制到 ServicorTo 区域（如果有对象的年龄以及达到了老年的标准，则赋值到老年代区），同时把这些对象的年龄+1（如果 ServicorTo 不够位置了就放到老年区）
 *  **清空 eden、servicorFrom**  
    然后，清空 Eden 和 ServicorFrom 中的对象
 *  **ServicorTo 和 ServicorFrom 互换**  
    最后，ServicorTo 和 ServicorFrom 互换，原 ServicorTo 成为下一次 GC 时的 ServicorFrom区

#### 老年代 ####

**主要存放应用程序中生命周期长的内存对象**  
老年代的对象比较稳定，所以 MajorGC 不会频繁执行。在进行 MajorGC 前一般都先进行了一次 MinorGC，使得有新生代的对象晋升入老年代，导致空间不够用时才触发。当无法找到足够大的连续空间分配给新创建的较大对象时也会提前触发一次 MajorGC 进行垃圾回收腾出空间  
MajorGC 采用标记清除算法：首先扫描一次所有老年代，标记出存活的对象，然后回收没有标记的对象。MajorGC 的耗时比较长，因为要扫描再回收。MajorGC 会产生内存碎片，为了减少内存损耗，我们一般需要进行合并或者标记出来方便下次直接分配。当老年代也满了装不下的时候，就会抛出 OOM（Out of Memory）异常

#### 永久代 ####

**指内存的永久保存区域，主要存放 Class 和 Meta（元数据）的信息,Class 在被加载的时候被放入永久区域，它和和存放实例的区域不同,GC 不会在主程序运行期对永久区域进行清理**。所以这也导致了永久代的区域会随着加载的 Class 的增多而胀满，最终抛出 OOM 异常

##### 永久代与元数据 #####

在 Java8 中，**永久代已经被移除，被一个称为“元数据区”（元空间）的区域所取代**。元空间的本质和永久代类似，元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。类的元数据放入 native memory, 字符串池和类的静态变量放入 java 堆中，这样可以加载多少类的元数据就不再由MaxPermSize 控制, 而由系统的实际可用空间来控制

### 垃圾回收与算法 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 7]

#### 确认回收垃圾 ####

##### 引用计数法 #####

**在 Java 中，引用和对象是有关联的。如果要操作对象则必须用引用进行。因此，很显然一个简单的办法是通过引用计数来判断一个对象是否可以回收**。简单说，即一个对象如果没有任何与之关联的引用，即他们的引用计数都不为 0，则说明对象不太可能再被用到，那么这个对象就是可回收对象

##### 可达性分析 #####

**为了解决引用计数法的循环引用问题，Java 使用了可达性分析的方法。通过一系列的“GC roots”对象作为起点搜索。如果在“GC roots”和一个对象之间没有可达路径，则认为该对象是不可达的**。要注意的是，不可达对象不等价于可回收对象，不可达对象变为可回收对象至少要经过两次标记过程。两次标记后仍然是可回收对象，则将面临回收

#### 标记清除算法（Mark-Sweep） ####

最基础的垃圾回收算法，分为两个阶段，标注和清除。标记阶段标记出所有需要回收的对象，清除阶段回收被标记的对象所占用的空间。如图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 8]  
从图中我们就可以发现，该算法**最大的问题是内存碎片化严重**，后续可能发生大对象不能找到可利用空间的问题

#### 复制算法（copying） ####

为了解决 Mark-Sweep 算法内存碎片化的缺陷而被提出的算法。按内存容量将内存划分为等大小的两块。每次只使用其中一块，当这一块内存满后将尚存活的对象复制到另一块上去，把已使用的内存清掉，如图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 9]  
这种算法虽然实现简单，内存效率高，不易产生碎片，但是最大的问题是可用内存被压缩到了原本的一半。且存活对象增多的话，Copying 算法的效率会大大降低，新生代采用此种算法的原因是，新生代的对象百分之九十几的对象都是朝生夕死，所以以8：1：1的方式分了三个区，分别为Eden、From Survivor、To Survivor

#### 标记整理算法(Mark-Compact) ####

结合了以上两个算法，为了避免缺陷而提出。标记阶段和 Mark-Sweep 算法相同，标记后不是清理对象，而是将存活对象移向内存的一端。然后清除端边界外的对象。如图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 10]

#### 分代收集算法 ####

**分代收集法是目前大部分 JVM 所采用的方法，其核心思想是根据对象存活的不同生命周期将内存划分为不同的域，一般情况下将 GC 堆划分为老生代(Tenured/Old Generation)和新生代(Young Generation)**。老生代的特点是每次垃圾回收时只有少量对象需要被回收，新生代的特点是每次垃圾回收时都有大量垃圾需要被回收，因此可以根据不同区域选择不同的算法

##### 新生代与复制算法 #####

目前大部分 JVM 的 GC 对于新生代都采取 Copying 算法，因为新生代中每次垃圾回收都要回收大部分对象，即要复制的操作比较少，但通常并不是按照 1：1 来划分新生代。一般将新生代划分为一块较大的 Eden 空间和两个较小的 Survivor 空间(From Space, To Space)，每次使用Eden 空间和其中的一块 Survivor 空间，当进行回收时，将该两块空间中还存活的对象复制到另一块 Survivor 空间中  
![在这里插入图片描述][20200512134105662.png]

##### 老年代与标记整理算法 #####

而老年代因为每次只回收少量对象，因而采用标记整理算法(Mark-Compact)算法:

*  JAVA 虚拟机提到过的处于方法区的永久代(Permanet Generation)，它用来存储 class 类、常量、方法描述等。对永久代的回收主要包括废弃常量和无用的类
 *  对象的内存分配主要在新生代的 Eden Space 和 Survivor Space 的 From Space(Survivor 目前存放对象的那一块)，少数情况(大对象)会直接分配到老年代
 *  当新生代的 Eden Space 和 From Space 空间不足时就会发生一次 GC，进行 GC 后，Eden Space 和 From Space 区的存活对象会被挪到 To Space，然后将 Eden Space 和 From Space 进行清理，最后将 From Space 与 To Space 区域互换
 *  如果 To Space 无法足够存储某个对象，则将这个对象存储到老生代
 *  在进行 GC 后，使用的便是 Eden Space 和 To Space 了，如此反复循环
 *  当对象在 Survivor 区躲过一次 GC 后，其年龄就会+1。默认情况下年龄到达 15 的对象会被移到老生代中

### JAVA 四中引用类型 ###

#### 强引用 ####

在 Java 中最常见的就是强引用，把一个对象赋给一个引用变量，这个引用变量就是一个强引用。当一个对象被强引用变量引用时，它处于可达状态，它是不可能被垃圾回收机制回收的，即使该对象以后永远都不会被用到 JVM 也不会回收。**因此强引用是造成 Java 内存泄漏的主要原因之一**

#### 软引用 ####

软引用需要用 SoftReference 类来实现，对于只有软引用的对象来说，当系统内存足够时它不会被回收，**当系统内存空间不足时软引用对象会被回收**。软引用通常用在对内存敏感的程序中

#### 弱引用 ####

弱引用需要用 WeakReference 类来实现，它比软引用的生存期更短，**对于只有弱引用的对象来说，只要垃圾回收机制一运行，不管 JVM 的内存空间是否足够，总会回收该对象占用的内存**

#### 虚引用 ####

虚引用需要 PhantomReference 类来实现，它不能单独使用，必须和引用队列联合使用。**虚引用的主要作用是跟踪对象被垃圾回收的状态**

### GC 分代收集算法 VS 分区收集算法 ###

#### 分代收集算法 ####

**当前主流 VM 垃圾收集都采用”分代收集”(Generational Collection)算法, 这种算法会根据对象存活周期的不同将内存划分为几块**, 如 JVM 中的新生代、老年代、永久代，这样就可以根据各年代特点分别采用最适当的 GC 算法

*  在新生代-复制算法  
    每次垃圾收集都能发现大批对象已死, 只有少量存活. 因此选用**复制算法**, 只需要付出少量存活对象的复制成本就可以完成收集
 *  在老年代-标记整理算法  
    因为对象存活率高、没有额外空间对它进行分配担保, 就必须采用“**标记—清理**”或“**标记—整理**”算法来进行回收, 不必进行内存复制, 且直接腾出空闲内存

#### 分区收集算法 ####

**分区算法则将整个堆空间划分为连续的不同小区间, 每个小区间独立使用, 独立回收**。这样做的好处是可以控制一次回收多少个小区间 , 根据目标停顿时间, 每次合理地回收若干个小区间(而不是整个堆), 从而减少一次 GC 所产生的停顿

### GC 垃圾收集器 ###

Java 堆内存被划分为新生代和年老代两部分，新生代主要使用复制和标记-清除垃圾回收算法；年老代主要使用标记-整理垃圾回收算法，因此 java 虚拟中针对新生代和年老代分别提供了多种不同的垃圾收集器，JDK1.6 中 Sun HotSpot 虚拟机的垃圾收集器如下

#### Serial 垃圾收集器（单线程、复制算法） ####

Serial（英文连续）是最基本垃圾收集器，使用复制算法，曾经是JDK1.3.1 之前新生代唯一的垃圾收集器。Serial 是一个单线程的收集器，它不但只会使用一个 CPU 或一条线程去完成垃圾收集工作，并且在进行垃圾收集的同时，必须暂停其他所有的工作线程，直到垃圾收集结束。Serial 垃圾收集器虽然在收集垃圾过程中需要暂停所有其他的工作线程，但是它简单高效，对于限定单个 CPU 环境来说，没有线程交互的开销，可以获得最高的单线程垃圾收集效率，因此 Serial垃圾收集器依然是 java 虚拟机运行在 Client 模式下默认的新生代垃圾收集器  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 11]

#### ParNew 垃圾收集器（Serial+多线程） ####

ParNew 垃圾收集器其实是 Serial 收集器的多线程版本，也使用复制算法，除了使用多线程进行垃圾收集之外，其余的行为和 Serial 收集器完全一样，ParNew 垃圾收集器在垃圾收集过程中同样也要暂停所有其他的工作线程。  
ParNew 收集器默认开启和 CPU 数目相同的线程数，可以通过-XX:ParallelGCThreads 参数来限制垃圾收集器的线程数。【Parallel：平行的】ParNew虽然是除了多线程外和Serial 收集器几乎完全一样，但是ParNew垃圾收集器是很多 java虚拟机运行在 Server 模式下新生代的默认垃圾收集器  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 12]

#### Parallel Scavenge 收集器（多线程复制算法、高效） ####

Parallel Scavenge 收集器也是一个新生代垃圾收集器，同样使用复制算法，也是一个多线程的垃圾收集器，它重点关注的是程序达到一个可控制的吞吐量（Thoughput，CPU 用于运行用户代码的时间/CPU 总消耗时间，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)），高吞吐量可以最高效率地利用 CPU 时间，尽快地完成程序的运算任务，主要适用于在后台运算而不需要太多交互的任务。自适应调节策略也是 ParallelScavenge 收集器与 ParNew 收集器的一个重要区别

#### Serial Old 收集器（单线程标记整理算法 ） ####

Serial Old 是 Serial 垃圾收集器年老代版本，它同样是个单线程的收集器，使用标记-整理算法，这个收集器也主要是运行在 Client 默认的 java 虚拟机默认的年老代垃圾收集器。在 Server 模式下，主要有两个用途：

*  在 JDK1.5 之前版本中与新生代的 Parallel Scavenge 收集器搭配使用
 *  作为年老代中使用 CMS 收集器的后备垃圾收集方案

#### Parallel Old 收集器（多线程标记整理算法） ####

Parallel Old 收集器是Parallel Scavenge的年老代版本，使用多线程的标记-整理算法，在 JDK1.6才开始提供。在 JDK1.6 之前，新生代使用 ParallelScavenge 收集器只能搭配年老代的 Serial Old 收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量，Parallel Old 正是为了在年老代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，可以优先考虑新生代 Parallel Scavenge和年老代 Parallel Old 收集器的搭配策略

#### CMS 收集器（多线程标记清除算法） ####

Concurrent mark sweep(CMS)收集器是一种年老代垃圾收集器，其最主要目标是获取最短垃圾回收停顿时间，和其他年老代使用标记-整理算法不同，它使用多线程的标记-清除算法。最短的垃圾收集停顿时间可以为交互比较高的程序提高用户体验。CMS 工作机制相比其他的垃圾收集器来说更复杂，整个过程分为以下 4 个阶段：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 13]

*  初始标记  
    只是标记一下 GC Roots 能直接关联的对象，速度很快，仍然需要暂停所有的工作线程
 *  并发标记  
    进行 GC Roots 跟踪的过程，和用户线程一起工作，不需要暂停工作线程
 *  重新标记  
    为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程
 *  并发清除  
    清除 GC Roots 不可达对象，和用户线程一起工作，不需要暂停工作线程。由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS 收集器的内存回收和用户线程是一起并发地执行

#### G1 收集器 ####

Garbage first 垃圾收集器是目前垃圾收集器理论发展的最前沿成果，相比与 CMS 收集器，G1 收集器两个最突出的改进是：

*  **基于标记-整理算法，不产生内存碎片**
 *  **可以非常精确控制停顿时间，在不牺牲吞吐量前提下，实现低停顿垃圾回收**

步骤：初始标记、并发标记、最终标记和筛选回收  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 14]  
G1 收集器避免全区域垃圾收集，它把堆内存划分为大小固定的几个独立区域，并且跟踪这些区域的垃圾收集进度，同时在后台维护一个优先级列表，每次根据所允许的收集时间，优先回收垃圾最多的区域。区域划分和优先级区域回收机制，确保 G1 收集器可以在有限时间获得最高的垃圾收集效率

### 类文件结构 ###

#### 无关性 ####

Java语言选择了与操作系统和机器指令集无关的、平台中立的格式作为程序编译后的储存格式。Java虚拟机提供的语言无关性是指虚拟机不关心Class的来源是何种语言，只要能生成Class文件就够了。可以使用Binary Viewer等软件读取二进制文件  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 15]

#### Class文件结构 ####

Java class文件是8位字节的二进制流，数据项按顺序存储在class文件中，相邻的项之间没有任何间隔，这样可以使class文件紧凑。占据多个字节空间的项按照高位在前的顺序分为几个连续的字节存放。在class文件中，**可变长度项的大小和长度位于其实际数据之前**。这个特性使得class文件流可以从头到尾被顺序解析，首先读出项的大小，然后读出项的数据。Class文件中有两种数据结构：无符号数和表。可以对比xml、json，二进制文件没有空格和换行，节省空间，提高性能，但放弃了可读性  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 16]

#### 魔数 ####

每个Java class文件的前4个字节被称为它的魔数（magic number）：0xCAFEBABE。**魔数的作用在于，可以轻松地分辨出Java class文件和非Java class文件**  
class文件的下面4个字节包含了主、次版本号。对于Java虚拟机来说，版本号确定了特定的class文件格式，通常只有给定主版本号和一系列次版本号后，Java虚拟机才能够读取class文件。如52对应JDK1.8

#### 常量池 ####

constant\_pool\_count和constant\_pool  
constant\_pool\_count：两个字节表示常量池的长度，编号从1开始  
CP\_info：每个常量池入口都从一个长度为一个字节的标志开始（tag），这个标志指出了列表中该位置的常量类型。JDK 1.7以后共有14种不相同表结构的数据。注：可以通过javap -verbose Demo.class命令来分析class文件  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 17]

#### 访问标志access\_flags ####

紧接常量池后的两个字节称为access\_flags，它展示了文件中定义的类或接口的几段信息，包括这个Class是类还是接口；是否定义为public类型；是否为abstrct类型；在access\_flags中所有未使用的位都必须由编译器置0，而且Java虚拟机必须忽略它  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 18]

#### 类索引 ####

接下来的两个字节为this\_class项，它是一个对常量池的索引。在this\_class位置的常量池入口必须为CONSTANT\_Class\_info表。该表由两个部分组成——标签和name\_index。标签部分是一个具有CONSTANT\_Class值的常量，在name\_index位置的常量池入口为一个包含了类或接口全限定名的CONSTANT\_Utf8\_info表  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 19]  
父类索引与接口索引集合同理

#### 字段表集合 ####

紧接在interfaces后面的是对在该类或者接口中所声明的字段的描述。首先是名为fields\_count的计数，它是类变量和实例变量的字段的数量总和。在这个计数后面的是不同长度的field\_info表的序列（fields\_count指出了序列中有多少个field\_info表）。在fields列表中，不列出从超类或者父接口继承而来的字段。字段表结构如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 20]

#### 方法表集合 ####

紧接着fields后面的是对在该类或者接口中所声明的方法的描述。只包括在该类或者接口中显式定义的方法  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 21]

#### 属性表集合 ####

在Class文件、字段表、方法表中都可以携带自己的属性表集合。相对于其它表，属性表的限制相对较小，不再要求各个属性表有严格的顺序，可以写入自定义的属性信息，JVM也预定义了21项属性表。对于每个属性，它的名称需要从常量池中引入一个CONSTANT\_Utf8\_info类型的常量来表示，而属性值的结构则完全自定义，只需要一个u4的长度属性去说明属性值所占用的位数即可，一个属性表结构如下图所示：  
![在这里插入图片描述][20200514140259156.png]

### 字节码指令 ###

Java虚拟机的指令由一个字节长度的、代表着某种特定操作含义的数字(称为操作码，Opcode)以及跟随其后的零至多个代表此操作所需参数(称为操作数，Operands)而构成。操作码的长度为1个字节，因此最大只有256条，是基于栈的指令集架构

#### 字节码与数据类型 ####

在Java虚拟机的指令集中，大多数的指令都包含了其操作所对应的数据类型信息。iload中的i表示的是int。i代表对int类型的数据操作，ｌ代表long，s代表short，b代表byte，c代表char，f代表float，d代表double，a代表reference。也有不包含类型信息的：goto与类型无关；Arraylength操作数组类型

#### 加载与存储指令 ####

加载和存储指令用于将数据在栈帧中的局部变量表和操作数栈之间来回传输，这类指令包括：

1.  将一个局部变量加载到操作栈：iload
2.  将一个数值从操作数栈存储到局部变量表：istore
3.  将一个常量加载到操作数栈：bipush
4.  扩充局部变量表的访问索引的指令：wide

#### 运算指令 ####

运算或算术指令用于对两个操作数栈上的值进行某种特定运算，并把结果重新存入到操作栈顶。大体上算术指令可以分为两种：对整型数据进行运算的指令与对浮点型数据进行运算的指令，无论是哪种算术指令，都使用Java虚拟机的数据类型，由于没有直接支持byte、short、char和boolean类型的算术指令，对于这类数据的运算，应使用操作int类型的指令代替。注：e = a + b + c + d +e，操作数栈的深度依然是2

#### 类型转换指令 ####

类型转换指令可以将两种不同的数值类型进行相互转换，这些转换操作一般用于实现用户代码中的显示类型转换操作，或者用来处理字节码指令中数据类型相关指令无法与数据类型一一对应的问题  
宽化类型处理：int i= 1；long l = i；  
窄化类型处理：User user = new User(); Object obj = user;  
处理窄化类型转换时，必须显式地使用转换指令来完成，这些转换指令包括：i2b、i2c、i2s、l2i、f2i、f2l、d2i、d2l和d2f

#### 对象创建与访问指令 ####

虽然类实例和数组都是对象，但Java虚拟机对类实例和数组的创建与操作使用了不同的字节码指令。对象创建后，就可以通过对象访问指令获取对象实例或者数组实例中的字段或者数组元素，这些指令如下：

*  创建类实例的指令：new；
 *  创建数组的指令：newarray、anewarray、multianewarray；
 *  访问类字段(static字段，或称类变量)和实例字段(非static字段，或称实例变量)的指令：getstatic、putstatic、getfield、putfield；
 *  把一个数组元素加载到操作数栈的指令：baload、caload、saload、iaload、laload、faload、daload、aaload；
 *  将一个操作数栈的值存储到数组元素中的指令：bastore、castore、sastore、iastore、fastore、dastore、aastore；
 *  取数组长度的指令：arraylength；
 *  检查类实例类型的指令：instanceof、checkcast

#### 操作数栈管理指令 ####

如同操作一个普通数据结构中的堆栈那样，Java虚拟机提供了一些用于直接操作操作数栈的指令，包括：

*  将操作数栈的栈顶一个或两个元素出栈：pop、pop2；（不常用）
 *  复制栈顶一个或两个数值并将复制值或双份的复制值重新压入栈顶：dup、dup2、dup\_x1、dup2\_x1、dup\_x2、dup2\_x2；
 *  将栈最顶端的两个数值互换:swap

#### 控制转移指令 ####

控制转移指令可以让Java虚拟机有条件或无条件地从指定的位置指令而不是控制转移指令的下一条指令继续执行程序，从概念模型上理解，可以认为控制转移指令就是在有条件或无条件地修改PC寄存器的值。如：goto等

#### 方法调用 ####

*  invokevirtual:用于调用对象的实例方法，根据对象的实际类型进行分派(虚方法分派)，这也是Java语言中最常见的方法分派方式
 *  invokeinterface:用于调用接口方法，它会在运行时搜索一个实现了这个接口方法的对象，找出适合的方法进行调用
 *  invokespecial：用于调用一些需要特殊处理的实例方法，包括实例初始化方法、私有方法和父类方法
 *  invokestatic:用于调用类方法(static 方法)

#### 异常处理指令 ####

在Java程序中显示抛出异常的操作（throw语句）都由athrow指令来实现，除了用throw语句显示抛出异常情况之外，Java虚拟机规范还规定了许多运行时异常会在其他Java虚拟机指令检测到异常状况时自动抛出。而在Java虚拟机中，**处理异常(catch语句)不是由字节码指令来实现的，而是采用异常表来完成的**

### 类加载 ###

JVM 类加载机制分为五个部分：**加载**，**验证**，**准备**，**解析**，**初始化**，下面我们就分别来看一下这五个过程  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 22]

##### 加载 #####

加载是类加载过程中的一个阶段，**这个阶段会在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的入口**。注意这里不一定非得要从一个 Class 文件获取，这里既可以从 ZIP 包中读取（比如从 jar 包和 war 包中读取），也可以在运行时计算生成（动态代理），也可以由其它文件生成（比如将 JSP 文件转换成对应的 Class 类）

##### 验证 #####

这一阶段的主要目的是为了**确保 Class 文件的字节流中包含的信息是否符合当前虚拟机的要求**，并且不会危害虚拟机自身的安全

##### 准备 #####

准备阶段是正式为类变量分配内存并设置类变量的初始值阶段，即**在方法区中分配这些变量所使用的内存空间**。注意这里所说的初始值概念，比如一个类变量定义为：  
`public static int v = 8080;`  
**实际上变量 v 在准备阶段过后的初始值为 0 而不是 8080**，将 v 赋值为 8080 的 put static 指令是程序被编译后，存放于类构造器<client>方法之中。但是注意如果声明为：  
`public static final int v = 8080;`  
在编译阶段会为 v 生成 ConstantValue 属性，在准备阶段虚拟机会根据 ConstantValue 属性将 v赋值为 8080

##### 解析 #####

解析阶段是指**虚拟机将常量池中的符号引用替换为直接引用的过程**。符号引用就是 class 文件中的：

CONSTANT_Class_info
    CONSTANT_Field_info
    CONSTANT_Method_info

等类型的常量

*  符号引用  
    符号引用与虚拟机实现的布局无关，**引用的目标并不一定要已经加载到内存中。各种虚拟机实现的内存布局可以各不相同**，但是它们能接受的符号引用必须是一致的，因为符号引用的字面量形式明确定义在 Java 虚拟机规范的 Class 文件格式中
 *  直接引用  
    **直接引用可以是指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。如果有了直接引用，那引用的目标必定已经在内存中存在**

##### 初始化 #####

**初始化阶段是类加载最后一个阶段，前面的类加载阶段之后，除了在加载阶段可以自定义类加载器以外，其它操作都由 JVM 主导**。到了初始阶段，才开始真正执行类中定义的 Java 程序代码

#### 类构造器<client> ####

**初始化阶段是执行类构造器<client>方法的过程**。<client>方法是由编译器自动收集类中的类变量的赋值操作和静态语句块中的语句合并而成的。虚拟机会保证子<client>方法执行之前，父类的<client>方法已经执行完毕，如果一个类中没有对静态变量赋值也没有静态语句块，那么编译器可以不为这个类生成<client>()方法。注意以下几种情况不会执行类初始化：

1.  通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化
2.  定义对象数组，不会触发该类的初始化
3.  常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，不会触发定义常量所在的类
4.  通过类名获取 Class 对象，不会触发类的初始化
5.  通过 Class.forName 加载指定类时，如果指定参数 initialize 为 false 时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对类进行初始化
6.  通过 ClassLoader 默认的 loadClass 方法，也不会触发初始化动作

#### 类加载器 ####

虚拟机设计团队把加载动作放到 JVM 外部实现，以便让应用程序决定如何获取所需的类，JVM 提供了 3 种类加载器：

*  **启动类加载器(Bootstrap ClassLoader)**  
    负责加载 JAVA\_HOME\\lib 目录中的，或通过-Xbootclasspath 参数指定路径中的，且被虚拟机认可（按文件名识别，如 rt.jar）的类
 *  **扩展类加载器(Extension ClassLoader)**  
    负责加载 JAVA\_HOME\\lib\\ext 目录中的，或通过 java.ext.dirs 系统变量指定路径中的类库
 *  **应用程序类加载器(Application ClassLoader)**  
    负责加载 用户路径（classpath） 上的类库。JVM 通过双亲委派模型进行类的加载，当然我们也可以通过继承java.lang.ClassLoader 实现自定义的类加载器  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 23]

#### 双亲委派 ####

**当一个类收到了类加载请求，他首先不会尝试自己去加载这个类，而是把这个请求委派给父类去完成，每一个层次类加载器都是如此，因此所有的加载请求都应该传送到启动类加载中，只有当父类加载器反馈自己无法完成此请求时**(在它的加载路径下没有找到所需加载的Class)，**子类加载器才会尝试自己去加载**  
**采用双亲委派的一个好处是类不会被不同加载器重复加载**，比如加载位于 rt.jar 包中的类 java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个 Object 对象  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 24]

### 内存模型 ###

#### 什么是内存模型 ####

**Java虚拟机的规范，用来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各个平台下都能达到一致的并发效果**。即在多线程读写共享数据时（成员变量、数组）时，对数据的可见性、有序 性、和原子性的规则和保障

#### 内存模型的目标 ####

**定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出这样的底层细节**。此处的变量包括实例字段、静态字段和构成数组对象的元素，但是不包括局部变量和方法参数，因为这些是线程私有的，不会被共享，所以不存在竞争问题

#### 主内存与工作内存 ####

**所有的变量都存储在主内存，每条线程还有自己的工作内存，保存了被该线程使用到的变量的主内存副本拷贝。线程对变量的所有操作（读取、赋值）都必须在工作内存中进行，不能直接读写主内存的变量。不同的线程之间也无法直接访问对方工作内存的变量，线程间变量值的传递需要通过主内存**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 25]

#### 内存间的交互操作 ####

一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存，Java内存模型定义了8种操作：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 26]

#### 原子性、可见性、有序性 ####

*  原子性：**对基本数据类型的访问和读写是具备原子性的**。对于更大范围的原子性保证，可以使用字节码指令monitorenter和monitorexit来隐式使用lock和unlock操作。这两个字节码指令反映到Java代码中就是同步块——synchronized关键字。因此synchronized块之间的操作也具有原子性
 *  可见性：**当一个线程修改了共享变量的值，其他线程能够立即得知这个修改**。Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取之前从主内存刷新变量值来实现可见性的。volatile的特殊规则保证了新值能够立即同步到主内存，每次使用前立即从主内存刷新。synchronized和final也能实现可见性。final修饰的字段在构造器中一旦被初始化完成，并且构造器没有把this的引用传递出去，那么其他线程中就能看见final字段的值
 *  有序性：Java程序的有序性可以总结为一句话: **如果在本线程内观察，所有的操作都是有序的**（线程内表现为串行的语义）；**如果在一个线程中观察另一个线程，所有的操作都是无序的**（指令重排序和工作内存与主内存同步延迟线性）

#### volatile ####

关键字volatile是Java虚拟机提供的最轻量级的同步机制。当一个变量被定义成volatile之后，具备两种特性：

*  **保证此变量对所有线程的可见性**。当一条线程修改了此变量的值，新值对于其他线程是可立即得知。而普通变量做不到这一点。
 *  **禁止指令重排序优化**。普通变量仅仅能保证在该方法执行过程中，得到正确结果，但是不保证程序代码的执行顺序

#### volatile并发下不一定安全 ####

volatile变量在各个线程的工作内存，不存在一致性问题（各个线程的工作内存中volatile变量，每次使用前都要刷新到主内存）。但是Java里面的运算并非原子操作，导致volatile变量的运算在并发下一样是不安全的

#### 为什么使用volatile ####

**在某些情况下，volatile同步机制的性能要优于锁（synchronized关键字），但是由于虚拟机对锁实行的许多消除和优化，所以相对而言也快不了多少**。volatile变量读操作的性能消耗与普通变量几乎没有差别，但是写操作则可能慢一些，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行

### 锁优化 ###

JDK1.6的一个重要主题，就是高效并发。HotSpot虚拟机开发团队在这个版本上，实现了各种锁优化：

*  **适应性自旋**
 *  **锁消除**
 *  **锁粗化**
 *  **轻量级锁**
 *  **偏向锁**

#### 自旋锁 ####

互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性带来很大压力。同时很多应用共享数据的锁定状态，只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得。先不挂起线程，等一会儿。例如，如果物理机器有一个以上的处理器，能让两个或以上的线程同时并行执行，让后面请求锁的线程稍等一会，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放。为了让线程等待，我们只需让线程执行一个忙循环（自旋）

##### 自旋的缺点 #####

自旋等待本身虽然避免了线程切换的开销，但**它要占用处理器时间**。所以如果锁被占用的时间很短，自旋等待的效果就非常好；如果时间很长，那么自旋的线程只会白白消耗处理器的资源。所以自旋等待的时间要有一定的限度，如果自旋超过了限定的次数仍然没有成功获得锁，那就应该使用传统的方式挂起线程了

#### 自适应自旋 ####

自旋的时间不固定了，而是**由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定**

*  如果一个锁对象，自旋等待刚刚成功获得锁，并且持有锁的线程正在运行，那么虚拟机认为这次自旋仍然可能成功，进而运行自旋等待更长的时间
 *  如果对于某个锁，自旋很少成功，那在以后要获取这个锁，可能省略掉自旋过程，以免浪费处理器资源

有了自适应自旋，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测就会越来越准确，虚拟机也会越来越聪明

#### 锁消除 ####

锁消除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但被检测到不可能存在共享数据竞争的锁进行消除。主要根据**逃逸分析**。程序员怎么会在明知道不存在数据竞争的情况下还使用同步呢？因为很多不是程序员自己想加入的

#### 锁粗化 ####

原则上，同步块的作用范围要尽量小。但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作在循环体内，频繁地进行互斥同步操作也会导致不必要的性能损耗。**锁粗化就是增大锁的作用域**

#### 轻量级锁 ####

在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗

#### 偏向锁 ####

消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。即在无竞争的情况下，**把整个同步都消除掉**。这个锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要同步

### 虚拟机工具 ###

Sun公司自带了许多虚拟机工具，在bin目录下，其exe文件所依赖的源码在tools.jar包下，利用jar包中的文件可自己开发

#### jps ####

jps（Java process status）可查看本地虚拟机唯一id lvmid (local virtual machine id)  
![在这里插入图片描述][20200514113131112.png]  
还可加入参数 -m 运行时传入主类的参数、-v 虚拟机参数、-l 运行的主类全名 或者jar包名称  
![在这里插入图片描述][2020051411315867.png]

#### jstat ####

监视虚拟机运行时的状态信息，包括监视类装载、内存、垃圾回收、jit编译信息。官方文档有操作命令：[https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jstat.html][https_docs.oracle.com_javase_8_docs_technotes_tools_unix_jstat.html]  
`jstat -gcutil 8176 1000 10 //检测进程号为8176的Java进程，每隔1000毫秒执行一次，执行十次`  
![在这里插入图片描述][20200514113740937.png]

#### jinfo ####

实时查看和调整虚拟机的各项参数  
![在这里插入图片描述][20200514113955956.png]  
第一条指令为：8176该进程是否启用Serial垃圾回收，输出-，表示不启用  
第二条指令为：8176该进程是否启用G1垃圾回收，输出+，表示启用  
还有很多查看和调整的参数，可自行查阅

#### jmap ####

命令jmap是一个多功能的命令。它可以生成 java 程序的 dump 文件， 也可以查看堆内对象示例的统计信息、查看 ClassLoader 的信息以及 finalizer 队列。可实现与-XX:+HeapDumpOnOutOfMemoryError相同的效果

#### jhat ####

JVM heap Analysis Tool（分析堆）十分占据内存与CPU，使用较少

#### jstack ####

生成线程快照，定位线程长时间停顿的原因

#### JConsole ####

JConsole是一种基于JMX的可视化监视、管理工具可进行**内存管理**、**线程管理**、**查看死锁**等

#### VisuaIVM ####

VisuaIVM(All-in-One Java Troubleshooting Tool)是一款免费的，**集成了多个 JDK 命令行工具的可视化工具**，它提供强大的分析能力，对 Java 应用程序做性能**分析**和**调优**。这些功能包括生成和**分析海量数据**、**跟踪内存泄漏**、**监控垃圾回收器**、**执行内存和 CPU 分析**，同时它还支持在 MBeans 上进行浏览和操作。**是目前为止功能最强大的运行监测和故障处理工具**，可在IDEA上安装一个 VisualVM Launcher 插件，方便直接启动该工具

### 参考资料 ###

《深入理解 Java 虚拟机》

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70]: /images/20230312/be13934e5e0a49b0b5072dc69f84c8e5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 1]: /images/20230312/df01871b2ea34c3aa8902643ae751388.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 2]: /images/20230312/c0a5eacf26664ac6b00fabdb73ff3f8b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 3]: /images/20230312/59e08b1ee57b4a2f98fa93813b5e293e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 4]: /images/20230312/45afcf796c9742d1af0def977fba9ec4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 5]: /images/20230312/487913a0328c40c7babb2ccc45ee5d30.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 6]: /images/20230312/51022da90bfd4cda825383f27834f8e0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 7]: /images/20230312/09ee1331cfe64372b1073b4fd6d0647d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 8]: /images/20230312/4181ecbc03534527bf7a52df0b48a7a4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 9]: /images/20230312/7555599e2b2d48d9b12c3e9abc7d788d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 10]: /images/20230312/e9bbacd392a14eca8b7ef352ee161ffd.png
[20200512134105662.png]: /images/20230312/8e0174214bbb4a29850bf7614243e7bb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 11]: /images/20230312/fb017b3eea74426cb29e336318b85158.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 12]: /images/20230312/c590fb03b3a04b25b8b955a769aefbeb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 13]: /images/20230312/337e0c33119d45448b19cad71a33ea63.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 14]: /images/20230312/d76bcce456364886ab3a412cf14d8a8e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 15]: /images/20230312/9c87ccc4ac8a44d7a7348af3e89d24f8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 16]: /images/20230312/141acbae39604170ace2bdbff779ef9f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 17]: /images/20230312/41b53c0966dd4ef88117276228c3f86f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 18]: /images/20230312/12cf2ef649e04ab59d416fc7e5e40409.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 19]: /images/20230312/f470157ec581471396f36d8e617fe7c7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 20]: /images/20230312/7c1362caa78048539c9cbc696953c52f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 21]: /images/20230312/09db1ea74e534887a561264a43a2c896.png
[20200514140259156.png]: /images/20230312/7b920104cd0c415fa249d063dd781409.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 22]: /images/20230312/772daf9231084b7ebb5236a3e39e13af.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 23]: /images/20230312/cd9811bf65ad4aebb3f599c0e6ab8604.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 24]: /images/20230312/e23e4208e0db45c2afb6ac5d97da2b33.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 25]: /images/20230312/852ca16547054f1793ce86f716cb020d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 26]: /images/20230312/f33172612991424cbdf929baee6adf1e.png
[20200514113131112.png]: /images/20230312/5d520d6185d04cc09cf5c24dac111979.png
[2020051411315867.png]: /images/20230312/cfcb4a566f664c0e9e3bd39f46a3b52f.png
[https_docs.oracle.com_javase_8_docs_technotes_tools_unix_jstat.html]: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jstat.html
[20200514113740937.png]: /images/20230312/c296369124dc42eda70bcf023fed6394.png
[20200514113955956.png]: /images/20230312/292002b8e88d418ca840ea3533cc219a.png