一、JVM通识
1.程序的执行方式
主要有三种：静态编译执行、动态编译执行和动态解释执行。
注意：此处所说的编译指的是编译成可让操作系统直接执行的机器码。
静态编译执行：C，C++
动态解释执行（看一行翻译一行执行）：JVM
动态编译执行（运行中进行编译）：JVM2.JVM即采用了动态解释又采用了动态编译执行。
3. 字节码和机器码的区别
机器码是电脑CPU直接读取运行的机器指令，运行速度最快，但是非常晦涩难懂，也比较难编写，一般从业人员接触不到。
字节码是一种中间状态（中间码）的二进制代码（文件）。需要直译器转译后才能成为机器码。
4.
JVM（java virtual machine）是虚拟计算机，用于执行字节码文件。JRE（java runtime environment）是 java 运行时环境，
包含了 JVM 和 java 核心基础类库（JDBC，lang and util）。JDK（java development kit）是 java 开发运行环境，
包含了 JRE，同时还包含了编译 java 源码的 javac （或称为前端编译器）和用于 java 程序调试分析的工具（JConsole，visualVM等）等
JVM 具有自动内存分配的功能和垃圾回收机制，而C++需要自己管理内存和自己回收内存。
java 是跨平台的，JVM 不是跨平台的
内存是非常重要的系统资源，是硬盘和CPU的中间仓库及桥梁，承载着os和应用程序的实时运行。
JVM内存布局规定了Java在运行过程中内存申请、分配、管理的策略，保证了JVM高效稳定运行。不同JVM对于内存的划分方式和管理机制存在差异。
5.openjdk与sun/oraclejdk
通过java -version我们可以查看jdk版本
(1) 如果是SUN/OracleJDK， 显示信息为：
[root@localhost ~]# java -version
java version "1.8.0_162"
Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12， mixed mode)说明:
Java HotSpot(TM) 64-Bit Server VM 表明， 此JDK的JVM是Oracle的64位HotSpot虚拟机， 运行在Server模式下(虚拟机有Server和Client两种运行模式).
Java™ SE Runtime Environment (build 1.8.0_162-b12) 是Java运行时环境(即JRE)的版本信息.
(2) 如果OpenJDK， 显示信息为：
[root@localhost ~]# java -version
openjdk version "1.8.0_144"
OpenJDK Runtime Environment (build 1.8.0_144-b01)
OpenJDK 64-Bit Server VM (build 25.144-b01， mixed mode)OpenJDK使用的是开源免费的FreeType， 可以按照GPL v2许可证使用.GPL V2允许在商业上使用;
Oracle JDK则采用JRL(Java Research License，Java研究授权协议) 放出.JRL只允许个人研究使用，要获得Oracle JDK的商业许可证，需要联系Oracle的销售人员进行购买。
6. JVM和Hotspot的关系
JVM是《JVM虚拟机规范》中提出来的规范。
Hotspot是使用JVM规范的商用产品，除此之外还有Oracle JRockit、IBM的J9也是JVM产品
JRockit是Oracle的JVM， 从Java SE 7开始， HotSpot和JRockit合并为一个JVM。
7. JVM的运行模式
JVM有两种运行模式：Server模式与Client模式。
两种模式的区别在于：
Client模式启动速度较快，Server模式启动较慢；
但是启动进入稳定期长期运行之后Server模式的程序运行速度比Client要快很多。
因为Server模式启动的JVM采用的是重量级的虚拟机，对程序采用了更多的优化；而Client模式启动的JVM采用的是轻量级的虚拟机。所以Server启动慢，但稳定后速度比Client远远要快。
在 windows上，缺省的虚拟机类型为client模式，如果要使用server模式，就需要在启动虚拟机时加-server参数，以获得更高性能，对服 务器端应用，推荐采用server模式，尤其是多个CPU的系统。在Linux，Solaris上缺省采用server模式。
二、JVM架构
jvm运行数据区
jvm内存模型
本地方法栈：
程序计数器：
虚拟机栈：
堆：
元数据区：
codecache（JIT编译的机器码）：
栈是运行时的单位，而堆是存储的单位。
栈解决程序的运行问题，即程序如何执行或者如何处理数据。堆解决的是数据存储的问题，即数据怎么放，放在哪
线程共享（随虚拟机或者GC而创建和销毁）：方法区(java8，将堆中的永生代优化至元数据区)，堆
线程独享（随线程生命周期而创建和销毁）：虚拟机栈，本地方法栈，程序计数器
1.程序计数器Program Counter Register (程序计数寄存器)
每个线程在创建后，都会产生自己的程序计数器和栈帧，程序计数器用来存放执行指令的偏移量和行号指示器等，线程执行或恢复都要依赖程序计数器。
程序计数器在各个线程之间互不影响，此区域也不会发生内存溢出异常
任何时刻一个线程只能有一个方法在执行，也就是当前方法
1）.当前线程执行java方法，记录当前线程正在执行的字节码指令的地址
2）.当前线程执行本地方法，计数器值为undefined
程序计数器（后文简称为 PCR）有两个作用：
字节码解释器通过改变PCR依次读取指令，实现代码的流程控制，如：顺序执行、选择、循环、异常处理
多线程情况下，PCR用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪了
2.Java虚拟机栈(JVM Stack)
2.1. 定义
相对于基于寄存器的运行环境，JVM是基于栈结构的运行环境。栈结构移植性更好，可控性更强。
JVM中的虚拟机栈是描述Java方法执行的内存区域，属【线程私有】。
栈中的元素用于支持虚拟机进行方法调用，每个方法从开始调用到执行完成的过程，就是栈帧从入栈到出栈的过程。
2.2 结构
栈帧是方法运行的基本结构。
在活动线程中，只有位于栈顶的帧才是有效的，称为当前栈帧（栈顶帧，像手枪弹夹，先进后出）
正在执行的方法称为当前方法
在执行引擎运行时，所有指令都只能针对当前栈帧操作，StackOverflowError表示请求的栈溢出，导致内存耗尽，通常出现在递归方法。
虚拟机栈通过压/出栈，对每个方法对应的活动栈帧进行运算处理，方法正常执行结束，肯定会跳转到另一个栈帧上。
在执行的过程中，如果出现异常，会进行异常回溯，返回地址通过异常处理表确定。
栈帧在整个JVM体系中的地位颇高，包括：局部变量表、操作栈、动态连接、方法返回地址等。
a.局部变量表
局部变量必须人工赋值
最基本的存储单元是Slot（变量槽），变量槽当一个方法使用完毕，可复用
存放方法参数和局部变量。其实就是数组
相对于类属性变量的准备阶段和初始化阶段，局部变量没有准备阶段，必须显式初始化。
如果是非静态方法，则在index[0]位置上存储的是方法所属对象的实例引用，随后存储的是参数和局部变量。
字节码指令中的STORE指令就是将操作栈中计算完成的局部变量写回局部变量表的存储空间内。
局部变量表的创建是在方法被执行的时候，随栈帧创建而创建。
表的大小在编译期就确定，在创建的时候只需分配事先规定好的大小即可。在方法运行过程中，表的大小不会改变。Java虚拟机栈会出现两种异常：
StackOverFlowError
若Java虚拟机栈的内存大小不允许动态扩展,那么当线程请求的栈深度大于虚拟机允许的最大深度时(但内存空间可能还有很多),就抛出此异常
栈内存默认最大是1M,超出则抛出StackOverflowError
OutOfMemoryError
若Java虚拟机栈的内存大小允许动态扩展,且当线程请求栈时内存用完了,无法再动态扩展了,此时抛出OutOfMemoryError异常
b.操作数栈
一个初始状态为空的桶式结构栈。由于 Java 没有寄存器，所有参数传递使用操作数栈。在方法执行过程中，会有各种指令往栈中写入和提取信息。JVM的执行引擎是基于栈的执行引擎，其中的栈指的就是操作栈。
字节码指令集的定义都是基于栈类型的，栈的深度在方法元信息的stack属性中。
操作栈与局部变量表交互
比如：i++ 先在局部变量表 slot取出，压入栈顶，cpu计算 再在下一个slot +1
++i 先在局部变量表 slot中+1取出 ，再压入栈顶 cpu计算 再保存在下一个slot
c.动态连接
每个栈帧中包含一个在常量池中对当前方法的引用，目的是支持方法调用过程的动态连接。
b.方法返回地址
方法执行时有两种退出情况：
正常退出
正常执行到任何方法的返回字节码指令，如RETURN、IRETURN、ARETURN等。
异常退出
无论何种，都将返回至方法当前被调用的位置。方法退出的过程相当于弹出当前栈帧。
退出可能有三种方式:
返回值压入，上层调用栈帧
异常信息抛给能够处理的栈帧
PC计数器指向方法调用后的下一条指令
3. 本地方法栈(Native Method Stack)
和虚拟机栈功能类似，虚拟机栈是为虚拟机执行JAVA方法而准备的。虚拟机规范并未规定具体实现，由不同虚拟机厂商自行实现。
HotSpot虚拟机中虚拟机栈和本地方法栈的实现式一样的。
本地方法栈和Java虚拟机栈实现的功能与抛出异常几乎相同。只不过
虚拟机栈是为虚拟机执行Java方法(也就是字节码)服务
本地方法栈则为虚拟机使用到的Native方法服务
在JVM内存布局中，也是线程对象私有的，但是虚拟机栈“主内”，而本地方法栈“主外”。
这个“内外”是针对JVM来说的，本地方法栈为Native方法服务线程开始调用本地方法时，会进入一个不再受JVM约束的世界。本地方法可以通过JNI(Java Native Interface)访问虚拟机运行时的数据区，甚至可以调用寄存器,具有和JVM相同的能力和权限。
当大量本地方法出现时，势必会削弱JVM对系统的控制力，因为它的出错信息都比较黑盒。对于内存不足的情况，本地方法栈还是会拋出native heap OutOfMemory。
最著名的本地方法应该是System.currentTimeMillis()，JNI 使Java深度使用OS的特性功能，复用非Java代码。但在项目过程中，如果大量使用其他语言来实现JNI,就会丧失跨平台特性，威胁到程序运行的稳定性。假如需要与本地代码交互，就可以用中间标准框架进行解耦，这样即使本地方法崩溃也不至于影响到JVM的稳定。当然，如果要求极高的执行效率、偏底层的跨进程操作等，可以考虑设计为JNI调用方式。
4 Java堆(Java Heap)
JVM启动时创建，存放所有的类实例及数组对象。
除实例数据，还保存对象的其他信息，如Mark Word（存储对象哈希码，GC标志，GC年龄，同步锁等信息），Klass Pointy(指向存储类型元数据的指针）及一些字节对齐补白的填充数据（若实例数据刚好满足8字节对齐，则可不存在补白）。
垃圾回收器主要就是管理堆内存。
Heap是OOM主要发源地，它存储着几乎所有的实例对象，堆由垃圾收集器自动回收，由各子线程共享使用。通常它占用的空间是所有内存区域中最大的，但若无节制创建大量对象，也容易消耗完所有空间。
堆的内存空间，既可以固定大小，也可运行时动态调整，通过如下参数设定初始值和最大值，比如
-Xms 256M
-Xmx 1024M
其中-X表示它是JVM运行参数
ms是memorystart的简称，最小堆容量
mx是memory max的简称，最大堆容量
通常情况下，服务器在运行过程中，堆空间不断地扩容与回缩，势必形成不必要系统压力，所以在线上生产环境中，JVM的Xms和Xmx设置成一样大小，避免在GC后调整堆大小时带来的额外压力。
堆分成两大块：新生代和老年代
对象产生之初在新生代，步入暮年时进入老年代，但是老年代也接纳在新生代无法容纳的超大对象。
新生代
1个Eden区(伊甸园[ˈiːdn])+ 2个Survivor区（幸存[sərˈvaɪvər]）。绝大部分对象在Eden区生成，当Eden区填满，会触发Young GC（后文简称YGC）。GC时，在Eden区实现清除策略，没有被引用的对象则直接回收。依然存活的对象会被复制到Survivor区。
Survivor 区分为S0和S1两块内存空间，送到哪块空间呢?
每次YGC时，将存活的对象复制到未使用的那块空间，然后将当前正在使用的空间完全清除，交换两块空间的使用状态。
若YGC要移送的对象大于Survivor区容量上限，则直接移交给老年代。假如一些没有进取心的对象以为可以一直在新生代的Survivor区交换来交换去，那就错了。每个对象都有一个计数器，每次YGC都会加1。
-XX:MaxTenuringThreshold
参数能配置计数器的值到达某个阈值的时候，对象从新生代晋升至老年代。若该参数配置为1，则从新生代的Eden区直接移至老年代。
默认值是15
可以在Survivor 区交换14次之后，晋升至老年代
若Survivor区无法放下，或超大对象的阈值超过上限，则尝试在老年代中进行分配。
若老年代也无法放下，则会触发Full Garbage Collection(Full GC)，若依然无法放下，则抛OOM。
堆出现OOM的概率是所有内存耗尽异常中最高的，出错时的堆内信息对解决问题非常有帮助，所以给JVM设置运行参数
-XX:+HeapDumpOnOutOfMemoryError
让JVM遇到OOM异常时能输出堆内信息。
在不同的JVM实现及不同的回收机制中，堆内存的划分方式是不一样的。
特点
Java虚拟机所需要管理的内存中最大的一块.
堆内存物理上不一定要连续,只需要逻辑上连续即可,就像磁盘空间一样.
堆是垃圾回收的主要区域,所以也被称为GC堆.
堆的大小既可以固定也可以扩展,但主流的虚拟机堆的大小是可扩展的(通过-Xmx和-Xms控制),因此当线程请求分配内存,但堆已满,且内存已满无法再扩展时,就抛出OutOfMemoryError.
线程共享
整个Java虚拟机只有一个堆,所有的线程都访问同一个堆.
它是被所有线程共享的一块内存区域,在虚拟机启动时创建.
而程序计数器、Java虚拟机栈、本地方法栈都是一个线程对应一个
5 方法区
5.1 定义
Java虚拟机规范中定义方法区是堆的一个逻辑区划部分，具体实现根据不同虚拟机来实现。
HotSpot在：
JDK7时，方法区放在永久代
JDK8时，方法区放在元数据空间，通过GC对该区域进行管理
别名Non-Heap(非堆)，以与Java堆区分。
方法区主要存放已经被虚拟机加载的类型的相关信息：
类信息
类名、访问修饰符、字段描述、方法描述
运行时常量池
常量存储在【运行时常量池】
静态变量
即时编译器(JIT)编译后的代码等数据
5.2.1 特点
线程共享
方法区是堆的一个逻辑部分，因此和堆一样，线程共享。整个虚拟机只有一个方法区。
永久代
方法区中的信息一般需长期存在，且又是堆的逻辑分区，因此用堆的划分方法，把方法区称为永久代
内存回收效率低
Java虚拟机规范对方法区的要求比较宽松，可不实现GC。方法区中的信息一般需长期存在，回收一遍内存后，可能只有少量信息无效。对方法区的内存回收的主要目标是：
常量池的回收
类型的卸载
和堆一样，允许固定大小，也可扩展大小，还允许不实现GC。
当方法区内存空间无法满足内存分配需求时,将抛出OutOfMemoryError异常.
5.3.2 特性
运行时常量池相比class文件常量池的另外一个特性是具备动态性，Java语言并不要求常量一定只有编译器才产生，即并非预置入class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池。
String类的intern()方法就采用了运行时常量池的动态性。调用 intern 时，看池中是否已包含等于此 String 对象的字符串：
是
返回池中的字符串
否
将此 String 对象添加到池中，并返回此 String 对象的引用
5.3.3 可能抛出的异常
运行时常量池是方法区的一部分，所以会受到方法区内存的限制，因此当常量池无法再申请到内存时，就会抛OutOfMemoryError异常。
一般在一个类中通过public static final声明一个常量。该类被编译后便生成Class文件，该类的所有信息都存储在这个class文件中。当这个类被JVM加载后，class文件中的常量就存放在方法区的运行时常量池。当运行时常量池中的某些常量没有被对象引用，同时也没有被变量引用，那么就需要垃圾收集器回收。
6 直接内存(Direct Memory)
直接内存不是虚拟机运行时数据区的一部分，也不是JVM规范中定义的内存区域，但在JVM的实际运行过程中会频繁地使用这块区域，而且也会抛OOM 。
JDK 1.4引入NIO(New Input／Output)类，一种基于管道和缓冲区的I/O方式，可使用Native函数库直接分配堆外内存，然后通过一个存储在堆里的DirectByteBuffer对象作为这块内存的引用来操作堆外内存中的数据。
这样能在一些场景中显著提升性能，因为避免了在Java堆和Native堆中来回复制数据。
7 Metaspace (元空间)
到了JDK8，元空间的前身Perm区（永久代）被淘汰，在JDK7及之前的版本中，只有Hotspot才有Perm区，它在启动时固定大小，很难调优，并且Full GC时会移动类元信息。
在某些场景下，若动态加载类过多，容易产生Perm区的OOM。比如某工程因为功能点较多，运行过程中，要不断动态加载很多类，经常出现错误：
Exception in thread ‘dubbo client x.x connector'
java.lang.OutOfMemoryError: PermGenspac
为解决该问题，需要设定运行参数
-XX:MaxPermSize=1280m
如果部署到新机器上，往往会因为JVM参数没有修改导致故障再现。不熟悉此应用的人排查问题时都苦不堪言。此外，永久代在GC过程中还存在诸多问题。
所以，JDK8使用元空间替换永久代。不同于永久代，元空间在本地内存中分配。即
只要本地内存足够，它不会出现类似永久代的java.lang.OutOfMemoryError: PermGen space
对永久代的设置参数 PermSize 和MaxPermSize也会失效。在JDK8及以上版本，设定MaxPermSize参数，JVM在启动时并不会报错，但提示:
Java HotSpot 64Bit Server VM warning:ignoring option MaxPermSize=2560m; support was removed in 8.0
默认情况下，“元空间”大小：
可动态调整
或使用新参数MaxMetaspaceSize限制本地内存分配给类元数据的大小
JDK8里，Perm 区所有内容中
字符串常量，移至堆内存
其他内容包括类元信息、字段、静态属性、方法、常量等，移动至元空间
Object类元信息、静态属性System.out、整型常量000000等，图中显示在常量池中的String，其实际对象被保存在堆内存。
特点
充分利用Java语言规范：
类及相关元数据的生命周期与类加载器一致
每个类加载器都有其内存区域-元空间
只进行线性分配
不会单独回收某个类（除了重定义类 RedefineClasses 或类加载失败）
无GC扫描或压缩
元空间里的对象不会被转移
若GC发现某个类加载器不再存活，会对整个元空间进行集体回收Full GC时，指向元数据指针都不用再扫描，减少了Full GC的时间
很多复杂的元数据扫描的代码（尤其是CMS里面的那些）都删除了
元空间只有少量的指针指向Java堆
这包括：类的元数据中指向java.lang.Class实例的指针;数组类的元数据中，指向java.lang.Class集合的指针。
无元数据压缩的开销
减少了GC Root的扫描（不在扫描虚拟机里面的已加载类的目录和其它的内部哈希表）
G1中，并发标记阶段完成后就可以进行类的卸载
元空间内存分配模型
绝大多数的类元数据的空间都在本地内存中分配
用来描述类元数据的对象也被移除
为元数据分配了多个映射的虚拟内存空间
为每个类加载器分配一个内存块列表
块的大小取决于类加载器的类型
Java反射的字节码存取器（sun.reflect.DelegatingClassLoader ）占用内存更小
空闲块内存返还给块内存列表
当元空间为空，虚拟内存空间会被回收
减少了内存碎片从线程共享角度来看
堆和元空间，线程共享
虚拟机栈、本地方法栈、程序计数器，线程私有
从这个角度看一下Java内存结构
