JVM

1、什么是Java虚拟机

定义：JVM是Java Virtual Machine（Java虚拟机的缩写），JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。

引入JVM后，Java语言在不同平台上运行时不需要重新编译，Java语言使用Java虚拟机屏蔽了与具体平台相关的信息，使得Java语言编译程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改的运行。在由JVM将字节码文件编译成机器语言，从而达到运行Java程序的目的。

2、Java代码编译执行过程

1、源码编译：通过Java源码编译器，将Java代码编译成JVM字节码(.class文件）；
2、类加载：通过ClassLoader及其子类来完成JVM类加载；
3、类执行：字节码被装入内存，进入JVM虚拟机，被解释执行。

3、JVM体系结构

3.1、Class Loader类加载器

   负责加载 .class文件，class文件在文件开头有特定的文件标示，并且ClassLoader负责class文件的加载等，至于它是否可以运行，则由Execution Engine决定。

① 定位和导入二进制class文件
　　② 验证导入类的正确性
　　③ 为类分配初始化内存
　　④ 帮助解析符号引用.

3.2、Native Interface本地接口

本地接口的作用是融合不同的编程语言为Java所用，它的初衷是融合C/C++程序，Java诞生的时候C/C++横行的时候，要想立足，必须有调用C/C++程序，于是就在内存中专门开辟了一块区域处理标记为
　　native的代码，它的具体作法是Native Method Stack中登记native方法，在Execution Engine执行时加载native libraies。
　　目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机，或者Java系统管理生产设备，在企业级应用中已经比较少见。
　　因为现在的异构领域间的通信很发达，比如可以使用Socket通信，也可以使用Web Service等。

3.3、Execution Engine 执行引擎：执行包在装载类的方法中的指令，也就是方法。

3.4、Runtime data area 运行数据区（即：虚拟机内存或者JVM内存 下节介绍）

从整个计算机内存中开辟一块内存存储Jvm需要用到的对象，变量等，分为：方法区，堆，虚拟机栈，程序计数器，本地方法栈。

4、JVM内存结构

4.1、程序计数器 PC Register

每个线程都有一个程序计算器，就是一个指针，指向方法区中的方法字节码（下一个将要执行的指令代码），由执行引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记。

程序计数器（Program Counter Register）是一块较小的内存空间，它的作用可以看做是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里（仅是概念模型，各种虚拟机可能会通过一些更高效的方式去实现），字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。由于Java 虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。如果线程正在执行的是一个Java 方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是Natvie 方法，这个计数器值则为空（Undefined）。此内存区域是唯一一个在Java 虚拟机规范中没有规定任何OutOfMemoryError 情况的区域。

4.2、本地方法栈 Native Method Stack

Native Method Stack中登记native方法，在Execution Engine执行时加载native libraies

本地方法栈与虚拟机栈基本类似，区别在于虚拟机栈为虚拟机执行的java方法服务，而本地方法栈则是为Native方法服务

4.3、方法区 Method Area

用于存储虚拟机加载的：静态变量+常量+类信息+运行时常量池 （类信息：类的版本、字段、方法、接口、构造函数等描述信息 ）

默认最小值为16MB，最大值为64MB，可以通过-XX:PermSize 和 -XX:MaxPermSize 参数限制方法区的大小

对于习惯在HotSpot 虚拟机上开发和部署程序的开发者来说，很多人愿意把方法区称为“永久代”（Permanent Generation），本质上两者并不等价，仅仅是因为HotSpot 虚拟机的设计团队选择把GC 分代收集扩展至方法区，或者说使用永久代来实现方法区而已。对于其他虚拟机（如BEA JRockit、IBM J9 等）来说是不存在永久代的概念的。即使是HotSpot 虚拟机本身，根据官方发布的路线图信息，现在也有放弃永久代并“搬家”至Native Memory 来实现方法区的规划了。Java 虚拟机规范对这个区域的限制非常宽松，除了和Java 堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域是比较少出现的，但并非数据进入了方法区就如永久代的名字一样“永久”存在了。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说这个区域的回收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是有必要的。在Sun 公司的BUG 列表中，曾出现过的若干个严重的BUG 就是由于低版本的HotSpot 虚拟机对此区域未完全回收而导致内存泄漏。根据Java 虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError 异常。

4.4、栈 JVM Stack

编译器可知的各种基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(引用指针，并非对象本身)

栈是java 方法执行的内存模型：

每个方法被执行的时候 都会创建一个“栈帧”用于存储局部变量表(包括参数)、操作栈、方法出口等信息。

每个方法被调用到执行完的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。

（局部变量表：存放了编译器可知的各种基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(引用指针，并非对象本身)，

其中64位长度的long和double类型的数据会占用2个局部变量的空间，其余数据类型只占1个。

局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在栈帧中分配多大的局部变量是完全确定的，在运行期间栈帧不会改变局部变量表的大小空间）

栈的生命期是跟随线程的生命期，线程创建时创建，线程结束栈内存也就释放，是线程私有的。

4.5、堆 Java Heap

所有的对象实例以及数组都要在堆上分配，此内存区域的唯一目的就是存放对象实例

堆是Java 虚拟机所管理的内存中最大的一块。Java 堆是被所有线程共享的一块内存区域，在虚拟机启动时创建

堆是理解Java GC机制最重要的区域，没有之一

结构：新生代（Eden区+2个Survivor区） 老年代 永久代（HotSpot有）

新生代：新创建的对象——>Eden区

GC之后，存活的对象由Eden区 Survivor区0进入Survivor区1

再次GC，存活的对象由Eden区 Survivor区1进入Survivor区0

老年代：对象如果在新生代存活了足够长的时间而没有被清理掉（即在几次Young GC后存活了下来），则会被复制到老年代

如果新创建对象比较大（比如长字符串或大数组），新生代空间不足，则大对象会直接分配到老年代上（大对象可能触发提前GC，应少用，更应避免使用短命的大对象）

老年代的空间一般比新生代大，能存放更多的对象，在老年代上发生的GC次数也比年轻代少

永久代：可以简单理解为方法区（本质上两者并不等价）

如上文所说：对于习惯在HotSpot 虚拟机上开发和部署程序的开发者来说，很多人愿意把方法区称为“永久代”，本质上两者并不等价

仅仅是因为HotSpot 虚拟机的设计团队选择把GC 分代收集扩展至方法区，或者说使用永久代来实现方法区而已

对于其他虚拟机（如BEA JRockit、IBM J9 等）来说是不存在永久代的概念的

即使是HotSpot 虚拟机本身，根据官方发布的路线图信息，现在也有放弃永久代并“搬家”至Native Memory 来实现方法区的规划了

Jdk1.6及之前：常量池分配在永久代

Jdk1.7：有，但已经逐步“去永久代”

Jdk1.8及之后：没有永久代(java.lang.OutOfMemoryError: PermGen space,这种错误将不会出现在JDK1.8中)

4.6、直接内存 Direct Memor

直接内存并不是JVM管理的内存，可以这样理解，直接内存，就是JVM以外的机器内存，比如，你有4G的内存，JVM占用了1G，则其余的3G就是直接内存

JDK中有一种基于通道（Channel）和缓冲区（Buffer）的内存分配方式，将由C语言实现的native函数库分配在直接内存中，用存储在JVM堆中的DirectByteBuffer来引用

5、jvm内存模型

简单用一句话来概括：保证多线程之间操作共享变量的正确性！至于如何保证推荐阅读 https://www.jianshu.com/p/76959115d486

6、GC

GC主要发生在Java堆与方法区这两个区域。

6、1 如何判断对象已“死”

Java堆中存放着几乎所有的对象实例，垃圾回收器在堆进行垃圾回收前，首先要判断这些对象哪些还存活，哪些已经“死去”。判断对象是否已“死”有如下几种算法：

6.1.1 引用计数法

引用计数法描述的算法为：给对象增加一个引用计数器，每当有一个地方引用它时，计数器就+1；当引用失效时，计数器就-1；任何时刻计数器为0的对象就是不能再被使用的，即对象已“死”。
引用计数法实现简单，判定效率也比较高，在大部分情况下都是一个比较好的算法。比如Python语言就是采用的引用计数法来进行内存管理的。
但是，在主流的JVM中没有选用引用计数法来管理内存，最主要的原因是引用计数法无法解决对象的循环引用问题。
范例：循环引用问题

/**
  * JVM参数:-XX:+PrintGC
  *
*/
public class Test {
	public Object instance = null;
	private static int _1MB = 1024 * 1024;
	private byte[] bigSize = new byte[2 * _1MB];
	public static void testGC() {
		Test test1 = new Test();
		Test test2 = new Test();
		test1.instance = test2;
		test2.instance = test1;
		test1 = null;
		test2 = null;
		// 强制JVM进行垃圾回收
		System.gc();
	}
	public static void main(String[] args) {
		testGC();
	}
}

程序输出：[GC (System.gc()) 6092K->856K(125952K), 0.0007504 secs]

从结果可以看出，GC日志包含" 6092K->856K(125952K)"，意味着虚拟机并没有因为这两个对象互相引用就不回收他们。即JVM并不使用引用计数法来判断对象是否存活。

6.1.2 可达性分析算法

在上面讲了，Java并不采用引用计数法来判断对象是否已“死”，而采用“可达性分析”来判断对象是否存活（同样采用此法的还有C#、Lisp-最早的一门采用动态内存分配的语言）。
此算法的核心思想：通过一系列称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为“引用链”，当一个对象到 GC Roots 没有任何的引用链相连时(从 GC Roots 到这个对象不可达)时，证明此对象不可用。以下图为例：

对象Object5 —Object7之间虽然彼此还有联系，但是它们到 GC Roots 是不可达的，因此它们会被判定为可回收对象。

在Java语言中，可作为GC Roots的对象包含以下几种：

1.虚拟机栈(栈帧中的本地变量表)中引用的对象。
2.方法区中静态属性引用的对象
3.方法区中常量引用的对象
4.本地方法栈中(Native方法)引用的对象

7、 jvm性能调优

jvm性能调优不是绝对的，还要结合实际情况。
①：增大jvm的内存大小，我们都知道频繁的gc对我们程序的运行影响很大，所以增大内存在一定程度上是可以提高效率的，但是并不是越大越好，在增大内存的同时导致每次GC的耗时也会随之增长。所以在增大jvm内存的同时，我们应控制好gc的频率，特别是Full GC，我们在创建对象时如果对象过大会直接进去永久代（jdk1.8改为元空间），这里我们可以通过设置jvm参数（-XX:PretrnureSizeThreshold）做相应的控制，尽量让对象先进入新生代，利用Minor GC尽快回收掉。
②：合理设置jvm参数与收集器，查看gc日志或使用开源jvm监控程序，分析原因，有针对性的解决问题。
推荐链接：https://my.oschina.net/LucasZhu/blog/2056232
开源工具：https://github.com/chewiebug/GCViewer
GC日志分析：https://blog.csdn.net/qq_21383435/article/details/80702205

8、总结

会不断补充，新手第一篇，复习用。