JVM虚拟机 超详细 介绍

谈谈你对，JVM的理解？java8的虚拟机有什么更新？
Jdk1.8及之后： 无永久代，常量池1.8在元空间
什么是oom?什么是StackOverflowError?有哪些方法分析？
JVM的常用参数调优？
内存快照抓取和MAT分析DUMP文件知道吗
谈谈JM中，对类加载器你的认识

JVM体系结构概述：

JVM是运行在操作系统之上的，与硬件没有直接交互
灰色区域没有垃圾回收

=========================================
总结：
方法区：.class ，jar包里的类
堆：new 出来的一推实例对象
Java栈：
本地方法栈：
本地方法接口：
本地方法库：
程序计数器：
加载因子：
执行引擎：

1.类加载器（放到方法区）（class loadel）：只负责把硬盘中的文件加载到内存中，转化为大Class文件，new出来的文件
类加载器有4种：虚拟机自带的加载器【
启动类加载器
扩展类加载器
系统类加载器

双亲委派机制
沙箱安全机制（保护自己原生的代码）
】
用户自定义加载器【
Java.lang.ClassLoader的子类，用户可以定制类的加载器
】
2.执行引擎：提交操作系统执行 出口
用一个Thread().start面试---------------- 我不确定启动没启动
native（本地方法） 没有方法体，得交给系统操作系统做
3.本地方法栈：只有标明native的才会执行，调用本地方法接口
4.本地方法接口：它的具体做法是Native Method Stack中登记native方法，在Execution Engine 执行时加载本地方法库。 也是系统的
5.本地方法库：第三方类库 dll 动态方法库
注意：三者都是操作系统的
6.PC寄存器（程序计数器，是线程私有的，即一个指针，指向下一条要执行的代码）：程序与程序之前相连接 ，按照顺序执行。
7.方法区：是被所有线程共享，大Class里包含的东西都放里边
静态变量+常量+类信息（构造方法/接口定义）+运行时常量池存在方法区中，注意实例变量存在堆内存中，和方法区无关
回收生命周期：在虚拟机停下来的时候
8.java栈（pc寄存器配合）【
队列：先进先出
栈：先进后出（弹夹），后进先出
存放的是：8种基本类型变量+对象的引用变量+实例方法

栈运行原理： 栈中的数据都是以栈帧（Stack Frame）的格式存在，栈帧是一个内存区 块，是一个数据集，是一个有关方法(Method)和运行期数据的数据集， 当一个方法A被调用时就产生了一个栈帧 F1，并被压入到栈中， A方法又调用了 B方法，于是产生栈帧 F2 也被压入栈， B方法又调用了 C方法，于是产生栈帧 F3 也被压入栈， …… 执行完毕后，先弹出F3栈帧，再弹出F2栈帧，再弹出F1栈帧……
遵循“先进后出”/“后进先出”原则
】

Exception in thread “main” java.lang.StackOverflowError----栈内存溢出（循环递归调用问题）

9.栈+堆+方法区的交互关系

HotSpont 这既是JDK品牌

*3种JVM
1)Sun公司的HostSpoot
2)BEA公司的JRockit
3)IBM公司 的J9 VM
复制必交换，随空谁是two
====堆空间=

新生去分为 伊甸区（new 出来的） 和幸存0区和1区
经历一次一次的gc 幸存1区最好进过15次gc，进入到养老区。

伊甸区空间（但是存活率低）》幸存区（from区 和 to区）》养老区

养老区和永久储存区是没有通路的

java8也是 一样 只不过 永久区变为元空间

新生区
新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾 回收器收集，结束生命。新生区又分为两部分：伊甸区（Eden space）和幸存者区 （Survivor pace） ，所有的类都是在伊甸区被new出来的。幸存区有两个：0区 （Survivor 0 space）和1区（Survivor 1 space）。当伊甸园的空间用完时，程序又需要 创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不 再被其他对象所引用的对象进行销毁。然后将伊甸园中的剩余对象移动到幸存0区。若幸 存 0区也满了，再对该区进行垃圾回收，然后移动到1 区。那如果1 区也满了呢？再次垃 圾回收，满足条件后再移动到养老区。若养老区也满了，那么这个时候将产生MajorGC （FullGC），进行养老区的内存清理。若养老区执行了Full GC之后发现依然无法进行对象 的保存，就会产生OOM异常“OutOfMemoryError”。
如果出现java.lang.OutOfMemoryError: Java heap space异常，说明 Java虚拟机的堆内存不够。
原因有二：
（1）Java虚拟机的堆内存设置不够，可以通过参数-Xms（初始内存调整）、-Xmx（最大内存）来调整。
（2）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存 在被引用）

伊甸区大概是 8:1:1

养老区：连接池

永久区

永久存储区是一个常驻内存区域，用于存放JDK自身所携带的 Class,Interface 的元数据，也就是说它存储的是运行环境必须的类信息，被装 载进此区域的数据是不会被垃圾回收器回收掉的，关闭 JVM 才会释放此区域所 占用的内存。
如果出现java.lang.OutOfMemoryError: PermGen space，说明是Java 虚拟机对永久代Perm内存设置不够。（一般不会出现）

出现这种情况原因，
1）都是程序启动需要加载 大量的第三方jar包。例如：在一个Tomcat下部署了太多的应用。或者大量动态 反射生成的类不断被加载，最终导致Perm区被占满。
Jdk1.6及之前： 有永久代, 常量池1.6在方法区 J
dk1.7： 有永久代，但已经逐步“去永久代”，常量池1.7在堆
Jdk1.8及之后： 无永久代，常量池1.8在元空间
====堆参数 调优=
-Xms 初始内存：以内存大小为例 除以64
-Xmx 最大内存：以内存大小为例 除以4

idea或者eclipes都行

这是 java7 还是永久区

这是java8 是元空间 注意 新生区 老年期的空间明显要大一些 而元空间 不参加

这是调整堆空间大小--------------idea----run—Eid Configuration—VM options下进行修改配置
VM参数： -Xms1024m -Xmx1024m -XX:+PrintGCDetails

堆空间 调小
VM参数：-Xms8m -Xmx8m -XX:+PrintGCDetails

---------------------MAT工具--------------
得在eclipse下安装这个插件 help-Eclipse Marketplace

注意生成异常 Throwable

idea 里进行设置

-Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\（要下载的目录）

会在你定的目录下生成相对应文件

还有 jdk–bin（可执行命令）—jvisualvm.exe 解读dump文件

=GC========
GC的作用区域------------方法区—堆空间
Minor（普通） GC发生在伊甸区 和幸存区 （各自区域快满的时候）
Full （全局） GC发生在（养老区快满的时候）
1.GC是什么（分带收集算法）：必会
次数上频繁收集Young区
次数上较少收集OLd区
基本不懂Perm(永久)区

2.GC 4 大算法：
1）引用计数法

2）复制算法(Copying)：-----复制必交换，谁空谁是to
年轻代中使用的是Minor GC，这种GC算法采用的是复制算法(Copying)
图下优缺点：

复制算法它的缺点也是相当明显的。
　　1、它浪费了一半的内存，这太要命了。
　　2、如果对象的存活率很高，我们可以极端一点，假设是100%存活，那么我们需要将所有对象都复制一遍，并将所有引用地址重置一遍。复制这一工作所花费的时间，在对象存活率达到一定程度时，将会变的不可忽视。 所以从以上描述不难看出，复制算法要想使用，最起码对象的存活率要非常低才行，而且最重要的是，我们必须要克服50%内存的浪费。
3）标记清除(Mark-Sweep)：
老年代一般是由标记清除或者是标记清除与标记整理的混合实现

缺点：此算法需要暂停整个应用，会产生内存碎片

用通俗的话解释一下标记/清除算法，就是当程序运行期间，若可以使用的内存被耗尽的时候，GC线程就会被触发并将程序暂停，随后将依旧存活的对象标记一遍，最终再将堆中所有没被标记的对象全部清除掉，接下来便让程序恢复运行。
4）标记压缩(Mark-Compact)
老年代一般是由标记清除或者是标记清除与标记整理的混合实现

运行：在整理压缩阶段，不再对标记的对像做回收，而是通过所有存活对像都向一端移动，然后直接清除边界以外的内存。
缺点：
标记/整理算法唯一的缺点就是效率也不高，不仅要标记所有存活对象，还要整理所有存活对象的引用地址。从效率上来说，标记/整理算法要低于复制算法。
5）标记清除压缩(Mark-Sweep-Compact)

========================================
总结；
内存效率：复制算法>标记清除算法>标记整理算法（此处的效率只是简单的对比时间复杂度，实际情况不一定如此）。
内存整齐度：复制算法=标记整理算法>标记清除算法。
内存利用率：标记整理算法=标记清除算法>复制算法。

可以看出，效率上来说，复制算法是当之无愧的老大，但是却浪费了太多内存，而为了尽量兼顾上面所提到的三个指标，标记/整理算法相对来说更平滑一些，但效率上依然不尽如人意，它比复制算法多了一个标记的阶段，又比标记/清除多了一个整理内存的过程
扩展知识=======
500的硬盘重 还是500的机械硬盘
固态硬盘会：一个一个存储的小的空间，区域，写入的是电子，就会变重（固态有次数限制。例如500G存满删除，这才算一次）
机械硬盘会是以：写入写出 是通过改磁极，只是磁极发生变化，（机械会用的越来越慢）

没有最好的算法，只有最合适的算法。==========>分代收集算法。

年轻代(Young Gen)

年轻代特点是区域相对老年代较小，对像存活率低。

这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对像大小有关，因而很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。

老年代(Tenure Gen)

老年代的特点是区域较大，对像存活率高。

这种情况，存在大量存活率高的对像，复制算法明显变得不合适。一般是由标记清除或者是标记清除与标记整理的混合实现。

Mark阶段的开销与存活对像的数量成正比，这点上说来，对于老年代，标记清除或者标记整理有一些不符，但可以通过多核/线程利用，对并发、并行的形式提标记效率。

Sweep阶段的开销与所管理区域的大小形正相关，但Sweep“就地处决”的特点，回收的过程没有对像的移动。使其相对其它有对像移动步骤的回收算法，仍然是效率最好的。但是需要解决内存碎片问题。

Compact阶段的开销与存活对像的数据成开比，如上一条所描述，对于大量对像的移动是很大开销的，做为老年代的第一选择并不合适。

基于上面的考虑，老年代一般是由标记清除或者是标记清除与标记整理的混合实现。以hotspot中的CMS回收器为例，CMS是基于Mark-Sweep实现的，对于对像的回收效率很高，而对于碎片问题，CMS采用基于Mark-Compact算法的Serial Old回收器做为补偿措施：当内存回收不佳（碎片导致的Concurrent Mode Failure时），将采用Serial Old执行Full GC以达到对老年代内存的整理。