JVM相关知识总结
目录
5 程序计数器（Program Counter Register）
一、JVM体系结构
1） 类装载器（ClassLoader）（用来装载.class文件）
2） 执行引擎（执行字节码，或者执行本地方法）
3） 运行时数据区（方法区、堆、java栈、PC寄存器、本地方法栈）
二、JAVA编译过程
JAVA源码不能被机器识别，要先经过编译器编译成JVM可以执行的.class字节码文件，再由解释器解释运行。即：Java源文件（.java） -- Java编译器 --> Java字节码文件 （.class） -- Java解释器 --> 执行。流程图如下：
生成的class文件由以下部分组成：
- 结构信息：包括class文件格式版本号及各部分的数量与大小的信息
- 元数据：对应于Java源码中声明与常量的信息。包含类/继承的超类/实现的接口的声明信息、域与方法声明信息和常量池
- 方法信息：对应Java源码中语句和表达式对应的信息。包含字节码、异常处理器表、求值栈与局部变量区大小、求值栈的类型记录、调试符号信息
Class的生命周期
包括加载、连接、初始化、使用、和卸载五个阶段。
加载
在java中，我们经常会接触到一个词——类加载，它和这里的加载并不是一回事，通常我们说类加载指的是类的生命周期中加载、连接、初始化三个阶段。在加载阶段，java虚拟机会做什么工作呢？其实很简单，就是找到需要加载的类并把类的信息加载到jvm的方法区中，然后在堆区中实例化一个java.lang.Class对象，作为方法区中这个类的信息的入口。
类的加载方式比较灵活，我们最常用的加载方式有两种，一种是根据类的全路径名找到相应的class文件，然后从class文件中读取文件内容；另一种是从jar文件中读取。另外，还有下面几种方式也比较常用：
- 从网络中获取：比如10年前十分流行的Applet。
- 根据一定的规则实时生成，比如设计模式中的动态代理模式，就是根据相应的类自动生成它的代理类。
- 从非class文件中获取，其实这与直接从class文件中获取的方式本质上是一样的，这些非class文件在jvm中运行之前会被转换为可被jvm所识别的字节码文件。
对于加载的时机，各个虚拟机的做法并不一样，但是有一个原则，就是当jvm“预期”到一个类将要被使用时，就会在使用它之前对这个类进行加载。比如说，在一段代码中出现了一个类的名字，jvm在执行这段代码之前并不能确定这个类是否会被使用到，于是，有些jvm会在执行前就加载这个类，而有些则在真正需要用的时候才会去加载它，这取决于具体的jvm实现。我们常用的hotspot虚拟机是采用的后者，就是说当真正用到一个类的时候才对它进行加载。
加载阶段是类的生命周期中的第一个阶段，加载阶段之后，是连接阶段。有一点需要注意，就是有时连接阶段并不会等加载阶段完全完成之后才开始，而是交叉进行，可能一个类只加载了一部分之后，连接阶段就已经开始了。但是这两个阶段总的开始时间和完成时间总是固定的：加载阶段总是在连接阶段之前开始，连接阶段总是在加载阶段完成之后完成。
连接
连接阶段比较复杂，一般会跟加载阶段和初始化阶段交叉进行，这个阶段的主要任务就是做一些加载后的验证工作以及一些初始化前的准备工作，可以细分为三个步骤：验证、准备和解析。
- 验证：当一个类被加载之后，必须要验证一下这个类是否合法，比如这个类是不是符合字节码的格式、变量与方法是不是有重复、数据类型是不是有效、继承与实现是否合乎标准等等。总之，这个阶段的目的就是保证加载的类是能够被jvm所运行。
-
准备：准备阶段的工作就是为类的静态变量分配内存并设为jvm默认的初值，对于非静态的变量，则不会为它们分配内存。有一点需要注意，这时候，静态变量的初值为jvm默认的初值，而不是我们在程序中设定的初值。jvm默认的初值是这样的：
- 基本类型（int、long、short、char、byte、boolean、float、double）的默认值为0。
- 引用类型的默认值为null。
- 常量的默认值为我们程序中设定的值，比如我们在程序中定义final static int a = 100，则准备阶段中a的初值就是100。
- 解析：这一阶段的任务就是把常量池中的符号引用转换为直接引用。那么什么是符号引用，什么又是直接引用呢？我们来举个例子：我们要找一个人，我们现有的信息是这个人的身份证号是1234567890。只有这个信息我们显然找不到这个人，但是通过公安局的身份系统，我们输入1234567890这个号之后，就会得到它的全部信息：比如安徽省黄山市余暇村18号张三，通过这个信息我们就能找到这个人了。这里，123456790就好比是一个符号引用，而安徽省黄山市余暇村18号张三就是直接引用。在内存中也是一样，比如我们要在内存中找一个类里面的一个叫做show的方法，显然是找不到。但是在解析阶段，jvm就会把show这个名字转换为指向方法区的的一块内存地址，比如c17164，通过c17164就可以找到show这个方法具体分配在内存的哪一个区域了。这里show就是符号引用，而c17164就是直接引用。在解析阶段，jvm会将所有的类或接口名、字段名、方法名转换为具体的内存地址。
连接阶段完成之后会根据使用的情况（直接引用还是被动引用）来选择是否对类进行初始化。
初始化
如果一个类被直接引用，就会触发类的初始化。在java中，直接引用的情况有：
- 通过new关键字实例化对象、读取或设置类的静态变量、调用类的静态方法。
- 通过反射方式执行以上三种行为。
- 初始化子类的时候，会触发父类的初始化。
- 作为程序入口直接运行时（也就是直接调用main方法）。
使用
类的使用包括主动引用和被动引用，主动引用在初始化的章节中已经说过了，下面我们主要来说一下被动引用：
- 引用父类的静态字段，只会引起父类的初始化，而不会引起子类的初始化。
- 定义类数组，不会引起类的初始化。
- 引用类的常量，不会引起类的初始化。
卸载
关于类的卸载，笔者在单例模式讨论篇：单例模式与垃圾回收一文中有过描述，在类使用完之后，如果满足下面的情况，类就会被卸载：
- 该类所有的实例都已经被回收，也就是java堆中不存在该类的任何实例。
- 加载该类的ClassLoader已经被回收。
- 该类对应的java.lang.Class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法。
如果以上三个条件全部满足，jvm就会在方法区垃圾回收的时候对类进行卸载，类的卸载过程其实就是在方法区中清空类信息，java类的整个生命周期就结束了。
三、类加载机制
Java程序并不一个可执行文件，是由多个独立的类文件组成。这些类文件并非一次性全部装入内存，而是依据程序逐步载入。
1.类加载的三个特征
1. 全盘负责，当一个类加载器负责加载某个Class时，该Class所依赖的和引用的其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入
2. 父类委托，先让父类加载器试图加载该类，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类
3. 缓存机制，缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区寻找该Class，只有缓存区不存在，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓存区。这就是为什么修改了Class后，必须重启JVM，程序的修改才会生效
2.类加载顺序
JVM的类加载是通过ClassLoader及其子类来完成的，类的层次关系和加载顺序可以由下图来描述：
（1）Bootstrap ClassLoader
- JVM的根ClassLoader，由C++实现
- 加载Java的核心API：$JAVA_HOME中jre/lib/rt.jar中所有class文件的加载，这个jar中包含了java规范定义的所有接口以及实现。
- JVM启动时即初始化此ClassLoader
（2）Extension ClassLoader
- 加载Java扩展API（lib/ext中的类）
（3）App ClassLoader
- 加载Classpath目录下定义的class
（4）Custom ClassLoader
- 属于应用程序根据自身需要自定义的ClassLoader，如tomcat、jboss都会根据J2EE规范自行实现ClassLoader
加载过程中会先检查类是否被已加载，检查顺序是自底向上，从Custom ClassLoader到BootStrap ClassLoader逐层检查，只要某个classloader已加载就视为已加载此类，保证此类只所有ClassLoader加载一次。而加载的顺序是自顶向下，也就是由上层来逐层尝试加载此类。
3.双亲委派机制
JVM在加载类时默认采用的是双亲委派机制。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归。如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，才自己去加载。
作用：1）避免重复加载；2）更安全。如果不是双亲委派，那么用户在自己的classpath编写了一个java.lang.Object的类，那就无法保证Object的唯一性。所以使用双亲委派，即使自己编写了，但是永远都不会被加载运行。
四、类执行过程
Java字节码的执行是由JVM执行引擎来完成，流程图如下所示：
JVM是基于栈的体系结构来执行class字节码的。线程创建后，都会产生程序计数器（PC）和栈（Stack），程序计数器存放下一条要执行的指令在方法内的偏移量，栈中存放一个个栈帧，每个栈帧对应着每个方法的每次调用，而栈帧又是有局部变量区和操作数栈两部分组成，局部变量区用于存放方法中的局部变量和参数，操作数栈中用于存放方法执行过程中产生的中间结果。
主要的执行技术：解释，即时编译，自适应优化、芯片级直接执行
- 解释属于第一代JVM：把class字节码一行行读出来解释成机器码执行。过程是解释，而不是编译，速度慢。
- 即时编译JIT属于第二代JVM：当某段代码即将第一次被执行时进行编译（编译成机器码），因而叫“即时编译”。缓存那些需要经常执行的机器码， 提高下次运行速度。
- 自适应优化（目前Sun的HotspotJVM采用这种技术）则吸取第一代JVM和第二代JVM的经验，采用两者结合的方式
解释器与编译器的对比
1.解释器的执行，抽象的看是这样的：
字节码 -> [ 解释器 解释执行机器码 ] -> 执行结果
2.而要JIT编译然后再执行的话，抽象的看则是：
字节码 -> [ 编译器 编译 ] -> 与机器相关的机器码-> [ 执行 ] -> 执行结果
对只执行一次的代码做JIT编译再执行，可以说是得不偿失。对只执行少量次数的代码，JIT编译带来的执行速度的提升也未必能抵消掉最初编译带来的开销。只有对频繁执行的代码，JIT编译才能保证有正面的收益。
五、内存相关
5.1.JVM运行时数据区
1 Java堆(Heap)
- 被所有线程共享的一块内存区域，在虚拟机启动时创建
- 用来存储对象实例
- 可以通过-Xmx和-Xms控制堆的大小
- OutOfMemoryError异常：当在堆中没有内存完成实例分配，且堆也无法再扩展时。
java堆是垃圾收集器管理的主要区域。java堆还可以细分为：新生代（New/Young）、旧生代/年老代（Old/Tenured）。持久代（Permanent）在方法区，不属于Heap。
新生代：新建的对象都由新生代分配内存。常常又被划分为Eden区和Survivor区。Eden空间不足时会把存活的对象转移到Survivor。新生代的大小可由-Xmn控制，也可用-XX:SurvivorRatio控制Eden和Survivor的比例。
旧生代：存放经过多次垃圾回收仍然存活的对象。
持久代：存放静态文件，如今Java类、方法等。持久代在方法区，对垃圾回收没有显著影响。
2 方法区
- 线程间共享
- 用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据
- OutOfMemoryError异常：当方法区无法满足内存的分配需求时
-
运行时常量池
- 方法区的一部分
- 用于存放编译期生成的各种字面量与符号引用，如String类型常量就存放在常量池
3 java虚拟机栈（VM Stack）
- 线程私有，生命周期与线程相同
- 存储方法的局部变量表(基本类型、对象引用)、操作数栈、动态链接、方法出口等信息。
- java方法执行的内存模型，每个方法执行的同时都会创建一个栈帧，每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
- StackOverflowError异常：当线程请求的栈深度大于虚拟机所允许的深度
- OutOfMemoryError异常：如果栈的扩展时无法申请到足够的内存
JVM栈是线程私有的，每个线程创建的同时都会创建JVM栈，JVM栈中存放的为当前线程中局部基本类型的变量、部分的返回结果以及Stack Frame。其他引用类型的对象在JVM栈上仅存放变量名和指向堆上对象实例的首地址。
4 本地方法栈（Native Method Stack）
- 与虚拟机栈相似，不过虚拟机栈是为虚拟机执行Java方法（字节码）服务，本地方法栈主要为虚拟机使用到的Native方法服务，在HotSpot虚拟机中直接把本地方法栈与虚拟机栈二合一
5 程序计数器（Program Counter Register）
- 当前线程所执行的字节码的行号指示器
- 当前线程私有
- 不会出现OutOfMemoryError情况
直接内存（Direct Memory）
- 直接内存并不是虚拟机运行的一部分，也不是Java虚拟机规范中定义的内存区域，但是这部分内存也被频繁使用
- NIO可以使用Native函数库直接分配堆外内存，堆中的DirectByteBuffer对象作为这块内存的引用进行操作
- 大小不受Java堆大小的限制，受本机(服务器)内存限制
- OutOfMemoryError异常：系统内存不足时
总结：Java对象实例存放在堆中；常量存放在方法区的常量池；虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据放在方法区；以上区域是所有线程共享的。栈是线程私有的，存放该方法的局部变量表(基本类型、对象引用)、操作数栈、动态链接、方法出口等信息。
一个Java程序对应一个JVM，一个方法（线程）对应一个Java栈。
5.2 内存回收GC
1 强软弱虚
2 虚拟机中的三个代
年轻代（Young Generation）、年老点（Old Generation）和持久代（Permanent Generation）。其中持久代主要存放的是Java类的类信息，与垃圾收集要收集的Java对象关系不大。年轻代和年老代的划分是对垃圾收集影响比较大的。
5.3 JVM内存调优
调优手段主要是通过控制堆内存的各个部分的比例和GC策略来实现，内存比例不良设置会导致一下不良后果：
1). 新生代设置过小
一是新生代GC次数非常频繁，增大系统消耗；二是导致大对象直接进入旧生代，占据了旧生代剩余空间，诱发Full GC
2). 新生代设置过大
一是新生代设置过大会导致旧生代过小（堆总量一定），从而诱发Full GC；二是新生代GC耗时大幅度增加
一般说来新生代占整个堆1/3比较合适
3). Survivor设置过小
导致对象从eden直接到达旧生代，降低了在新生代的存活时间
4). Survivor设置过大
导致eden过小，增加了GC频率。
另外，通过-XX:MaxTenuringThreshold=n来控制新生代存活时间，尽量让对象在新生代被回收
六、虚拟机对比
JVM, Art和Dalvik对比：JVM一种软件实现，只要其他编程语言的编译器能生成Java字节码，就能在不改变java代码下在各种硬件上运行。Dalvik虚拟机：基于apache的java虚拟机，改造后适合低内存低配置设备。Dalvik每次都要编译再运行，Art只会首次启动编译。Art占用空间比Dalvik大，用空间换时间。减少编译和CPU使用频率，更省电。启动快，运行快。