JVM 详解

引言

　　本文主要介绍，有关JVM（Java Visual Mechine Java虚拟机）的知识。

运行时数据区

什么是运行时数据区

　　通过命令行javac，对 *.java源文件 进行编译；然后在由命令 java 运行 *.java，而java源码文件进行编译成class文件，计算机将class文件打散放入JVM数据区中。如下图所示

运行时怎么划分数据区？

class文件中到底有多少数据类型？

　　对象、常量、静态变量、普通的成员变量、方法、局部变量、父类……

怎么划分数据区？

　　在对应的官方文档中（按JavaSE 1.8为例），按照 2.5. Run-Time Data Areas 中描述的可以分为以下几个数据区

　　2.5.1. The PC Register 计数器

　　2.5.2. Java Virtual Machine Stacks 虚拟机栈

　　2.5.3. Heap 堆

　　2.5.4. Method Area 方法区

　　2.5.5. Run-Time Constant Pool 运行常量池

　　2.5.6. Native Method Stacks 方法栈

Heap 堆

　　Heap 堆 --> 用于存储Java对象 (对象/数组)

 Method Area 方法区

　　Method Area 方法区 --> 用于存储 类的信息、常量、变量、编译后的代码

 　　方法的执行移动是由线程执行的：线程执行方法的过程可以用一个数据结构来表示【先进后出】——栈

Java Virtual Machine Stacks 虚拟机栈

　　一个线程可以表示一个虚拟机栈，而方法的执行可以通过压栈的方式进行，具体如下图所示：

　　具体虚拟机栈的工作，可以讲class文件进行反编译，可以看到计算机指令的全过程（字节码指令会把一行代码拆分为很多步骤）。  javap -c *.class，至于指令具体的内容可参考官方文档中对应语言的含义

　　栈帧：包含局部变量表、操作数栈

The PC Register 计数器

　　每个线程有个计数器 --> 用于存储当前线程栈执行所在的位置 ：这样可以很好的防止当线程中途断开或等待时，再次执行时候，不必要重头开始执行

Run-Time Constant Pool 运行常量池

 　　用以下图解来了解整个运行时数据区：

 Q：JDK 8 中 还有方法区么？

　　方法区包含了运行常量池，JDK 1.7 之前 --> Perm Space 永久代  JDK 1.8 之后 --> Meta Space 元空间

垃圾回收器

　　原因：我有一块内存区域（java线程启动的时候），存着存着，发现不够用了？  ----> 报错 OutOfMemeryError ？ 万一这个内存区域中有些数据已经没有用了呢？

　　这里就引入了“垃圾回收算法”来进行垃圾回收

垃圾回收

　　1. 运行时数据：内存模型设计

 

　　2. 垃圾对象判断

　　　　1. 引用计数法：但有弊端（当出现循环引用的时候，如果两者都是垃圾，但该算法不会判断为两者是垃圾，而一直保留着）

　　　　2. 可达性分析：GC 设置一个根节点，判断是否可以到达该对象，如果没有到达，则判断为垃圾

 垃圾回收算法

　　不同的代-->需要用不同的回收算法

• 复制算法（主要用于Young区，每次垃圾回收，存活的对象比较少）

　　　　优点：不会有碎片

　　　　缺点：始终都会有一半的空间浪费

• 标记算法（主要用于Old区，绝大多数对象都是存活时间长）　　

　　　　优点：不会浪费空间，空间可以达到最大的合理使用

　　　　缺点：比较耗时，有空间碎片

G1垃圾收集器的过程

1. 初始标记：使用一个垃圾回收线程，标记垃圾
2. 并发标记：从Roots触发可达性分析，标记垃圾
3. 最终标记：再次标记。采用多线程
4. 筛选回收：回收垃圾对象

评价垃圾回收器的好坏标准

1. 吞吐量：吞吐量越高越好
2. 停顿时间：时间越低越好

如何减少GC的频率

1. 适当的增加堆内存的空间
2. 合适地设置G1垃圾回收器的停顿时间
3. 调整垃圾回收的临界线
4. 增加回收线程数量