只有光头才能变强！
学习JVM的目的也很简单：
1.能够知道JVM是什么，为我们干了什么，具体是怎么干的。能够理解到一些初学时不懂的东西
2.在面试的时候有谈资
3.能装逼
一、简单聊聊JVM
1.1先来看看简单的Java程序
现在我有一个JavaBean：
一个测试类：
我们在初学的时候肯定用过javac来编译.java文件代码，用过java命令来执行编译后生成的.class文件。
Java源文件：
在使用IDE点击运行的时候其实就是将这两个命令结合起来了(编译并运行)，方便我们开发。
生成class文件
解析class文件得到结果
1.2编译过程
.java文件是由Java源码编译器(上述所说的javac.exe)来完成，流程图如下所示：
Java源码编译由以下三个过程组成：
1.分析和输入到符号表
2.注解处理
3.语义分析和生成class文件
1.2.1编译时期-语法糖
语法糖可以看做是编译器实现的一些“小把戏”，这些“小把戏”可能会使得效率“大提升”。
最值得说明的就是泛型了，这个语法糖可以说我们是经常会使用到的！
泛型只会在Java源码中存在，编译过后会被替换为原来的原生类型（Raw Type，也称为裸类型）了。这个过程也被称为：泛型擦除。
有了泛型这颗语法糖以后：
1.代码更加简洁【不用强制转换】
2.程序更加健壮【只要编译时期没有警告，那么运行时期就不会出现ClassCastException异常】
3.可读性和稳定性【在编写集合的时候，就限定了类型】
了解泛型更多的知识：
segmentfault.com/a/119000001…
1.3JVM实现跨平台
至此，我们通过javac.exe编译器编译我们的.java源代码文件生成出.class文件了！
这些.class文件很明显是不能直接运行的，它不像C语言(编译cpp后生成exe文件直接运行)
这些.class文件是交由JVM来解析运行！
JVM是运行在操作系统之上的，每个操作系统的指令是不同的，而JDK是区分操作系统的，只要你的本地系统装了JDK，这个JDK就是能够和当前系统兼容的。
而class字节码运行在JVM之上，所以不用关心class字节码是在哪个操作系统编译的，只要符合JVM规范，那么，这个字节码文件就是可运行的。
所以Java就做到了跨平台--->一次编译，到处运行！
1.4class文件和JVM的恩怨情仇
1.4.1类的加载时机
现在我们例子中生成的两个.class文件都会直接被加载到JVM中吗？？
虚拟机规范则是严格规定了有且只有5种情况必须立即对类进行“初始化”(class文件加载到JVM中)：
*创建类的实例(new 的方式)。访问某个类或接口的静态变量，或者对该静态变量赋值，调用类的静态方法
*反射的方式
*初始化某个类的子类，则其父类也会被初始化
*Java虚拟机启动时被标明为启动类的类，直接使用java.exe命令来运行某个主类（包含main方法的那个类）
*当使用JDK1.7的动态语言支持时(....)
所以说：
Java类的加载是动态的，它并不会一次性将所有类全部加载后再运行，而是保证程序运行的基础类(像是基类)完全加载到jvm中，至于其他类，则在需要的时候才加载。这当然就是为了节省内存开销。
1.4.2如何将类加载到jvm
class文件是通过类的加载器装载到jvm中的！
Java默认有三种类加载器：
各个加载器的工作责任：
1）Bootstrap ClassLoader：负责加载$JAVA_HOME中jre/lib/rt.jar里所有的class，由C++实现，不是ClassLoader子类
2）Extension ClassLoader：负责加载java平台中扩展功能的一些jar包，包括$JAVA_HOME中jre/lib/*.jar或-Djava.ext.dirs指定目录下的jar包
3）App ClassLoader：负责记载classpath中指定的jar包及目录中class
工作过程：
1、当AppClassLoader加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器ExtClassLoader去完成。
2、当ExtClassLoader加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给BootStrapClassLoader去完成。
3、如果BootStrapClassLoader加载失败（例如在$JAVA_HOME/jre/lib里未查找到该class），会使用ExtClassLoader来尝试加载；
4、若ExtClassLoader也加载失败，则会使用AppClassLoader来加载
5、如果AppClassLoader也加载失败，则会报出异常ClassNotFoundException
其实这就是所谓的双亲委派模型。简单来说：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上。
好处：
防止内存中出现多份同样的字节码(安全性角度)
特别说明：
类加载器在成功加载某个类之后，会把得到的java.lang.Class类的实例缓存起来。下次再请求加载该类的时候，类加载器会直接使用缓存的类的实例，而不会尝试再次加载。
1.4.2类加载详细过程
加载器加载到jvm中，接下来其实又分了好几个步骤：
加载，查找并加载类的二进制数据，在Java堆中也创建一个java.lang.Class类的对象。
连接，连接又包含三块内容：验证、准备、初始化。
1）验证，文件格式、元数据、字节码、符号引用验证；
2）准备，为类的静态变量分配内存，并将其初始化为默认值；
3）解析，把类中的符号引用转换为直接引用
初始化，为类的静态变量赋予正确的初始值。
1.4.3JIT即时编辑器
一般我们可能会想：JVM在加载了这些class文件以后，针对这些字节码，逐条取出，逐条执行-->解析器解析。
但如果是这样的话，那就太慢了！
我们的JVM是这样实现的：
就是把这些Java字节码重新编译优化，生成机器码，让CPU直接执行。这样编出来的代码效率会更高。
编译也是要花费时间的，我们一般对热点代码做编译，非热点代码直接解析就好了。
热点代码解释：一、多次调用的方法。二、多次执行的循环体
使用热点探测来检测是否为热点代码，热点探测有两种方式：
采样
计数器
目前HotSpot使用的是计数器的方式，它为每个方法准备了两类计数器：
方法调用计数器（Invocation Counter）
回边计数器（Back EdgeCounter）。
在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译。
1.4.4回到例子中
按我们程序来走，我们的Java3yTest.class文件会被AppClassLoader加载器(因为ExtClassLoader和BootStrap加载器都不会加载它[双亲委派模型])加载到JVM中。
随后发现了要使用Java3y这个类，我们的Java3y.class文件会被AppClassLoader加载器(因为ExtClassLoader和BootStrap加载器都不会加载它[双亲委派模型])加载到JVM中
1.5类加载完以后JVM干了什么？
在类加载检查通过后，接下来虚拟机将为新生对象分配内存。
1.5.1JVM的内存模型
首先我们来了解一下JVM的内存模型的怎么样的：
基于jdk1.8画的JVM的内存模型--->我画得比较细。
简单看了一下内存模型，简单看看每个区域究竟存储的是什么(干的是什么)：
堆：存放对象实例，几乎所有的对象实例都在这里分配内存
虚拟机栈：虚拟机栈描述的是Java方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame）用于存储局部变量表、操作栈、动态链接、方法出口等信息
本地方法栈：本地方法栈则是为虚拟机使用到的Native方法服务。
方法区：存储已被虚拟机加载的类元数据信息(元空间)
程序计数器：当前线程所执行的字节码的行号指示器
1.5.2例子中的流程
>need-to-insert-img
我来宏观简述一下我们的例子中的工作流程：
1、通过java.exe运行Java3yTest.class，随后被加载到JVM中，元空间存储着类的信息(包括类的名称、方法信息、字段信息..)。
2、然后JVM找到Java3yTest的主函数入口(main)，为main函数创建栈帧，开始执行main函数
3、main函数的第一条命令是Java3y java3y = new Java3y();就是让JVM创建一个Java3y对象，但是这时候方法区中没有Java3y类的信息，所以JVM马上加载Java3y类，把Java3y类的类型信息放到方法区中(元空间)
4、加载完Java3y类之后，Java虚拟机做的第一件事情就是在堆区中为一个新的Java3y实例分配内存, 然后调用构造函数初始化Java3y实例，这个Java3y实例持有着指向方法区的Java3y类的类型信息（其中包含有方法表，java动态绑定的底层实现）的引用
5、当使用java3y.setName("Java3y");的时候，JVM根据java3y引用找到Java3y对象，然后根据Java3y对象持有的引用定位到方法区中Java3y类的类型信息的方法表，获得setName()函数的字节码的地址
6、为setName()函数创建栈帧，开始运行setName()函数
从微观上其实还做了很多东西，正如上面所说的类加载过程（加载-->连接(验证，准备，解析)-->初始化)，在类加载完之后jvm为其分配内存(分配内存中也做了非常多的事)。由于这些步骤并不是一步一步往下走，会有很多的“混沌bootstrap”的过程，所以很难描述清楚。
扩展阅读(先有Class对象还是先有Object)：www.zhihu.com/question/30…
1.6简单聊聊各种常量池
在写这篇文章的时候，原本以为我对String s = "aaa";类似这些题目已经是不成问题了，直到我遇到了String.intern()这样的方法与诸如String s1 = new String("1") + new String("2");混合一起用的时候
我摘抄一个例子：
打印结果是
jdk7,8下false true
调换一下位置后：
打印结果为：
jdk7,8下false false
1.6.1各个常量池的情况
针对于jdk1.7之后：
常量池位于堆中
运行时常量池位于堆中
字符串常量池位于堆中
常量池存储的是：
字面量(Literal)：文本字符串等---->用双引号引起来的字符串字面量都会进这里面
符号引用(Symbolic References)
类和接口的全限定名(Full Qualified Name)
字段的名称和描述符(Descriptor)
方法的名称和描述符
常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放--->来源：深入理解Java虚拟机 JVM高级特性与最佳实践（第二版）
现在我们的运行时常量池只是换了一个位置(原本来方法区，现在在堆中),但可以明确的是：类加载后，常量池中的数据会在运行时常量池中存放！
HotSpot VM里，记录interned string的一个全局表叫做StringTable，它本质上就是个HashSet。注意它只存储对java.lang.String实例的引用，而不存储String对象的内容
字符串常量池只存储引用，不存储内容！
再来看一下我们的intern方法：
* When the intern method is invoked,ifthe pool already contains a * string equal to this {@code String} object as determined by * the {@link#equals(Object)} method, then the string from the pool is* returned. Otherwise, this {@code String} object is added to the * pool and a reference to this {@code String} object is returned.复制代码
如果常量池中存在当前字符串，那么直接返回常量池中它的引用。
如果常量池中没有此字符串, 会将此字符串引用保存到常量池中后, 再直接返回该字符串的引用！
1.6.2解析题目
本来打算写注释的方式来解释的，但好像挺难说清楚的。我还是画图吧...
很容易看到，两条引用是不一样的！所以返回false
第二句：s.intern();发现字符串常量池中已经存在"1"字符串对象，直接返回字符串常量池中对堆的引用(但没有接收)-->此时s引用还是指向着堆中的对象
第三句：String s2 = "1";发现字符串常量池已经保存了该对象的引用了，直接返回字符串常量池对堆中字符串的引用
很容易看到，两条引用是不一样的！所以返回false。
第一句：String s3 = new String("1") + new String("1");注意：此时**"11"对象并没有在字符串常量池中保存引用**。
第二句：s3.intern();发现"11"对象并没有在字符串常量池中，于是将"11"对象在字符串常量池中保存当前字符串的引用，并返回当前字符串的引用(但没有接收)
第三句：String s4 = "11";发现字符串常量池已经存在引用了，直接返回(拿到的也是与s3相同指向的引用)
根据上述所说的：最后会返回true~~~
如果还是不太清楚的同学，可以试着接收一下intern()方法的返回值，再看看上述的图，应该就可以理解了。
下面的就由各位来做做，看是不是掌握了：
还有：
1.7GC垃圾回收
可以说GC垃圾回收是JVM中一个非常重要的知识点，应该非常详细去讲解的。但在我学习的途中，我已经发现了有很好的文章去讲解垃圾回收的了。
所以，这里我只简单介绍一下垃圾回收的东西，详细的可以到下面的面试题中查阅。
1.7.1JVM垃圾回收简单介绍
在C++中，我们知道创建出的对象是需要手动去delete掉的。我们Java程序运行在JVM中，JVM可以帮我们“自动”回收不需要的对象，对我们来说是十分方便的。
虽然说“自动”回收了我们不需要的对象，但如果我们想变强，就要变秃..不对，就要去了解一下它究竟是怎么干的，理论的知识有哪些。
首先，JVM回收的是垃圾，垃圾就是我们程序中已经是不需要的了。垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象之中哪些还“存活”着，哪些已经“死去”。判断哪些对象“死去”常用有两种方式：
引用计数法-->这种难以解决对象之间的循环引用的问题
可达性分析算法-->主流的JVM采用的是这种方式
现在已经可以判断哪些对象已经“死去”了，我们现在要对这些“死去”的对象进行回收，回收也有好几种算法：
标记-清除算法
复制算法
标记-整理算法
分代收集算法
(这些算法详情可看下面的面试题内容)~
无论是可达性分析算法，还是垃圾回收算法，JVM使用的都是准确式GC。JVM是使用一组称为OopMap的数据结构，来存储所有的对象引用(这样就不用遍历整个内存去查找了，空间换时间)。并且不会将所有的指令都生成OopMap，只会在安全点上生成OopMap，在安全区域上开始GC。
在OopMap的协助下，HotSpot可以快速且准确地完成GC Roots枚举（可达性分析）。
上面所讲的垃圾收集算法只能算是方法论，落地实现的是垃圾收集器：
Serial收集器
ParNew收集器
Parallel Scavenge收集器
Serial Old收集器
Parallel Old收集器
CMS收集器
G1收集器
上面这些收集器大部分是可以互相组合使用的
1.8JVM参数与调优
很多做过JavaWeb项目(ssh/ssm)这样的同学可能都会遇到过OutOfMemory这样的错误。一般解决起来也很方便，在启动的时候加个参数就行了。
上面也说了很多关于JVM的东西--->JVM对内存的划分啊，JVM各种的垃圾收集器啊。
内存的分配的大小啊，使用哪个收集器啊，这些都可以由我们根据需求，现实情况来指定的，这里就不详细说了，等真正用到的时候才回来填坑吧~~~~
二、JVM面试题
拿些常见的JVM面试
1、详细jvm内存模型
2、讲讲什么情况下回出现内存溢出，内存泄漏？
3、说说Java线程栈
4、JVM 年轻代到年老代的晋升过程的判断条件是什么呢？
5、JVM 出现 fullGC 很频繁，怎么去线上排查问题？
6、类加载为什么要使用双亲委派模式，有没有什么场景是打破了这个模式？
7、类的实例化顺序
8、JVM垃圾回收机制，何时触发MinorGC等操作
9、JVM 中一次完整的 GC 流程（从 ygc 到 fgc）是怎样的
10、各种回收器，各自优缺点，重点CMS、G1
11、各种回收算法
12、OOM错误，stackoverflow错误，permgen space错误
2.1详细jvm内存模型
根据 JVM 规范，JVM 内存共分为虚拟机栈、堆、方法区、程序计数器、本地方法栈五个部分。
具体可能会聊聊jdk1.7以前的PermGen（永久代），替换成Metaspace（元空间）
原本永久代存储的数据：符号引用(Symbols)转移到了native heap；字面量(interned strings)转移到了java heap；类的静态变量(class statics)转移到了java heap
Metaspace（元空间）存储的是类的元数据信息（metadata）
元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。
替换的好处：一、字符串存在永久代中，容易出现性能问题和内存溢出。二、永久代会为 GC 带来不必要的复杂度，并且回收效率偏低
2.2讲讲什么情况下回出现内存溢出，内存泄漏？
内存泄漏的原因很简单：
对象是可达的(一直被引用)
但是对象不会被使用
常见的内存泄漏例子：
解决这个内存泄漏问题也很简单，将set设置为null，那就可以避免上诉内存泄漏问题了。其他内存泄漏得一步一步分析了。
内存溢出的原因：
内存泄露导致堆栈内存不断增大，从而引发内存溢出。
大量的jar，class文件加载，装载类的空间不够，溢出
操作大量的对象导致堆内存空间已经用满了，溢出
nio直接操作内存，内存过大导致溢出
解决：
1.查看程序是否存在内存泄漏的问题
2.设置参数加大空间
3.代码中是否存在死循环或循环产生过多重复的对象实体、
4.查看是否使用了nio直接操作内存。