请谈谈你对JVM的理解，JVAVA8虚拟机的更新。
以元空间的方式去实现了 方法区，而jdk 1.8之前是以永久代去实现的方法区（两者的区别在于，）
什么是OOM，什么是栈溢出StackOverFlow 怎么分析
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/biapp/m.hprof
Jprofiler 工具
JVM的常用调优参数
-Xms200m memory size
-Xmx200m memory max (size)
-Xms和-Xmx都属于XX参数。-Xms等同于 -XX:InitialHeapSize；-Xmx等同于 -XX:MaxHeapSize，如果我们自己不设置的话 -Xms默认为系统内存的1/64，-Xmx默认为系统内存的1/4。
-XX:+PrintGCDetails 打印GC日志
-Xmn、新生代大小 memery new
-XX:NewRatio 新生代比列
-XX:SurvivorRatio 幸存区比列
内存快照如何抓去，怎么分析Dump文件
idea linux 命令
谈谈JVM中，类加载器你的认识？
加载class文件 ， xx 初始化
JVM的位置
操作系统之上，用C开发的，因此 Java又称为 c++-- ,内存交给jvm，去除指针。
image.png
JVM的体系结构
.java => .class => ClassLoader =>运行时数据区
=>本地方法接口（native方法）
=>执行引擎
1.运行时数据区内容：
· 方法区，method area
· 栈 stack
· 堆 heap（垃圾产生区域，JVM调优，就是调优堆。）
· 本地方法栈 native method stack
· 程序计数器 computer
默写，JVM的体系结构
1.类加载器 =>加载class文件。（引出class loader）
2.栈执行代码、会访问对象，对象存放在堆中，对象本身也会关联class模板。class模板存放在方法区引出 栈、堆、方法区)
3.执行指令时，通过程序计数器，记录下一条指令。(程序计数器)
4.若途中调用native 方法，本地方法栈就是 其他语言的运行栈空间，通过 执行器加载本地方法库执行。（执行引擎、本地方法接口，本地方法栈。）
PS：通过调用过程记录JVM的体系结构
image.png
类加载器
初始化是为类的静态变量赋予正确的初始值，准备阶段和初始化阶段看似有点矛盾，其实是不矛盾的，如果类中有语句：private static int a = 10，它的执行过程是这样的，首先字节码文件被加载到内存后，先进行链接的验证这一步骤，验证通过后准备阶段，给a分配内存，因为变量a是static的，所以此时a等于int类型的默认初始值0，即a=0,然后到解析（后面在说），到初始化这一步骤时，才把a的真正的值10赋给a,此时a=10。
.class => ClassLoader
作用：加载class文件
加载、初始化class 、 实例化对象。
类别：
虚拟机自带的加载器
启动类加载器
扩展类加载器
应用程序类加载器
从这里引出：沙箱机制和双亲委派模型
image.png
沙箱安排机制
组成
字节码校验器：判断是否遵守java语言规范（java包下的不会校验。）
类装载器：（=>引出双亲委派机制）
安全管理包：（加密、数字签名）
...存取控制器、安全管理器
通过双亲委派机制，类的加载永远都是从 启动类加载器开始，依次下放，保证你所写的代码，不会污染Java自带的源代码，所以出现了双亲委派机制，保证了沙箱安全
要素概念核心：
域的概念、（远程的代码是不安全的，因此使用沙箱隔离。有点像docker的容器，保证运行时环境的隔离。）
总结 类装载器+ 安全管理包+域的概念
双亲委派机制
双亲委派机制：
1.类加载器，加载类的请求。
2.将这个请求向上委托，给父类加载，一直向上委托，直到启动类加载器进行加载
3.启动加载器价差是否能加载当前的类，能加载则结束。不能加载则通知子类进行加载
4.重复步骤3 => class not found
5.总结：所以，Java 的类的加载机制，永远是从 启动类加载器 --> 拓展类加载器 --> 应用程序类加载器 这样的一个顺序进行加载
Native方法
由Thread => start() native 引入
native：凡是带了native关键字的，说明已经超出java的作用范围了，回去调用C语言的库。
调用本地方式时，会进入本地方法栈 =>调用本地接口（这个过程就是JNI java native interface）<=执行引擎加载本地方法
发展： java需要支持c++的调用，他在内存中，开辟了一块标记区域用来标记native方法。通过JNI执行。（少用）
// 调用其他接口、socket、webservice htttp
PC寄存器
每一次执行完jvm指令则+1 ,标识下一条指令的位置
方法区(现在是以元空间的方式去实现。)
static 、final、class模板、常量池
jdk1.8以后 是以元空间的方式去实现 方法区（native memory）
jdk 1.8以前是永久代 实现的方法区
方法区只是 jvm内存管理的逻辑区域，
而元空间和永久代是物理区域。
元空间和永久代的区别是，永久代利用的jvm内存 是连续的物理地址
而元空间是本地内存。可以是不连续的，这一块不属于堆的内存
栈
程序员=数据结构+算法（持续学习）
程序 = 框架+业务逻辑（now）
first in last out =>对比 队列相反 first in first out ·
递归=> 无限压栈 =>栈溢出 StackOverflow 栈溢出
生命周期：与生命周期同步
内容：八大基本类型+对象引用+实例的方法
原理：栈帧
程序真在执行的方法，一定在栈的顶部，
堆
Heap、JVM只有一个堆内存、堆内存的大小是可以调节的、
类加载器刦了类文件以后，一般会把什么东西放在堆中？ =>对象实例
堆内又可以分为 新生区（Eden Space）、老年区、永久区
容量会越来越大 轻则 gc 重则 full gc
假设内存满了 => OOM ，引出堆溢出
新生区
新生区又分为
Eden space
to、from =>引出替换和复制算法
老年区
当 to、from 满了之后，或者年龄够大，则会放置在老年区。
满了就stop the world
永久区（jdk1.8之后叫做元空间）
常驻内存、用来存放JDK自身携带额class对象，存储一些java的运行环境或类信息。
jdk 1.6之前，常量池、放在方法区中，
jdk1.7 ：永久代去除，常量池在堆中(方法区中)
jdk1.8:无永久代、常量池在元空间中。
一个启动类、加载了大量的第三方jar包，Tomcat部署了太多的应用，大量的动态反射类，
直到内存满了。
image.png
堆内存调优
发生OOM
1.尝试扩大内存
2.分析内存，看一下哪个环节出现了问题。
3.Jprofile 调试工具 分析大对线、线程、等鞥。
4.参数
-Xms200m 初始内存大小
-Xmx200m 内存最大值（交给JVM自动识别，因此 两个值通常是一样的）
5.Runtime 类，用于调优的
GC
流程
minor gc （复制算法） => full gc()
区域
1.新生代 （minor gc）
a. Eden (对象诞生的区域)
b.from
c.to
2.老年代 （full gc）
算法
1.应用计数法（给对象分配一个次数，每次引用则进行+1，失去引用-1，为0时清除，本身就需要耗费资源）
2.复制算法（minor gc 时，在新生代使用的就是，直接复制过来，然后清空原内存）
3.标记清除算法（扫描对象进行标记，对没有标记的对象，进行清除，）
优点：不需要额外的空间
缺点：会产生内存碎片，浪费时间、
4.标记压缩
向一端移动存活对象（又扫描一次），去除内存碎片
5.标记清除压缩算法
总结
内存效率： 复制算法 > 标记清除算法 > 标记压缩算法
内存整齐度：复制算法 = 标记压缩算法 > 标记清除算法
内存利用率：内存利用率 标记压缩算法>标记清除算法>复制算法
=> GC分带收集算法
引出 新生代 存活率低，效率要求高，因此使用复制算法
老年代，区域大，（如果使用复制算法则需要耗费更多的资源）存活率低，也就是 不需要效率高
因此采用 标记清除+标记压缩混合算法
JMM java memory model
1.什么是JMM ？
java memeory model java内存模型
2.JMM是干嘛的
作用：而JMM就对应于类似于MSI、MESI、MOSI、Synapse、Firefly及Dragon Protocol这样的缓存一致性协议，用于定义数据读写的规则。
3.他如何学习？
JMM是一种规范，目的是解决由于多线程通过共享内存进行通信时，存在的本地内存数据不一致、编译器会对代码指令重排序、处理器会对代码乱序执行等带来的问题。目的是保证并发编程场景中的原子性、可见性和有序性。
image.png
image.png
源自于 //www.greatytc.com/p/797129612bed
三种JVM（了解）
java -verison 查看
Sun 公司 HotSpot（当前）
BEA JRockit
IBM的 j9 vm
JMM
对象大小分为:
自身的大小（Shadow heap size）
所引用对象的大小（Retained heap size）
每个对象都有一个 mark work 头部，以及一个引用（klass pointer）指向Class类的信息。
在未开启 UseCompressedOops 的 64 位 JVM 上，对象头有 16 字节大小，即 8 字节的 mark word 和 8 字节的引用。
在开启 UseCompressedOops 的 64 位机器上，引用成了 4 字节，一共 12 字节。
