Java虚拟机运行时数据区

对象的创建

Java创建对象，在语言层面上使用new关键字。虚拟机遇到new关键字时，会检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已经被加载、解析和初始化过。如果没有，那就必须先执行类加载过程。类加载通过之后，虚拟机将会为新生对象分配内存。对象所需的内存在类加载完成后就能完全确定。分配内存的方法有“指针碰撞”和“空闲列表”两种方式，如果Java堆是规整的，则采用前者；否则，采用后者。Java堆是否规则和虚拟机有关。

OOM

在虚拟机中，能够发生OOM的有：虚拟机栈，本地方法栈，Java堆，方法区，运行时常量。分析OOM使用eclipse memory analyzer插件或者JProfiler工具。添加jvm参数(-XX:+PrintGCDetails)可以打印出GC的详细日志，-Xloggc:gc.log 日志文件的输出路径。

Java堆

几乎所有的对象的视力都在这里分配内存。通过参数-Xmx(JVM最大可用内存)和-Xms(JVM初始可用内存)控制对的大小。如果在堆中没有内存完成实例分配并且堆无法扩展，就会OOM。栈-Xss设置栈的容量大小。HotSpot不区分本地方法栈和虚拟机栈。如果虚拟机在申请栈扩展时，没有足够的空间，则会OOM。

垃圾收集器与内存分配策略

判断对象是否存活，两种方式：引用计数法和可达性分析。

引用计数法，不能解决对象相互引用的情况，所以主流虚拟机都采用的是可达性分析。

可达性分析采用采用GCROOTS策略，可作为GCROOTS的有：

• 虚拟机栈中引用的对象

• 方法区中类静态属性引用的对象

• 方法区中常量引用的对象

• Native方法中引用的对象

一、不同虚拟机对比表

二、理解GC日志

下面是一次GC产生的日志(jvm参数-XX:+PrintGCDetails)：

从日志中可以看到，System.gc()表示程序调用了System.gc()方法触发了垃圾回收，[PSYoungGen:3932k->592k(76288k)]中PSYoungGen代表了GC发生的区域，这个名称和GC收集器密切相关：如果显示的是[DefNew，则表明是Serial收集器的新生代；如果是ParNew则表明是ParNew收集器的新生代；我们这里是PSYoungGen，则表明是Parallel Scavenge收集器的新生代。再看后面是数字，3932k->592k(76288k)代表的是：GC前该内存已经使用的容量->GC后该内存区域使用的容量(该内存区域总容量)。3932K->600K(251392K)表示GC前Java堆已经使用的容量->GC后Java堆已经使用的容量(Java堆总容量)。后面的时间表示GC所花费的时间，单位s。

三、内存分配与回收策略

1、对象优先分配在Eden区

大多数情况下，对象首先会被分配到Eden区，当Eden区满了，会触发一次Minor GC。

大对象直接进入老年区

所谓的大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组（笔者列出的例子中的byte[]数组就是典型的大对象）。虚拟机提供了一个-XX：PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存复制（复习一下：新生代采用复制算法收集内存）。

2、长期存活的对象进入老年区

对象在Survivor区中每“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就将会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数-XX：MaxTenuringThreshold设置。

3、动态对象年龄的判断

虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

4、空间分配担保

在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC，尽管这次Minor GC是有风险的，如果担保失败则会进行一次Full GC；如果小于，或者HandlePromotionFailure设置不允许冒险，那这时也要改为进行一次Full GC。

虚拟机性能监控与故障处理工具

jps:虚拟机进程状况工具

jps格式:jps [options] [hostid]

功能：列出正在执行的虚拟机进程，并显示虚拟机执行主类（Main Class,main（）函数所在的类）名称以及这些进程的本地虚拟机唯一ID（Local Virtual Machine Identifier,LVMID）。

jstat:虚拟机统计信息监视工具

功能：它可以显示本地或者远程[1]虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。

命令格式：jstat [option vmid [ interval [s|ms] [count] ] ]，参数interval和count代表查询间隔和次数。

其中，如果进程是本地虚拟机进程，则vmid与lvmid一致；如果是远程虚拟机进程，则vmid格式为：[protocol:][//]lvmid[@hostname[:port]/servername]

举例：

S0代表Survivor0；S1代表Survivor1；E代表Eden区；O代表Old区；M代表Metaspace元数据区域(JDK1.8用Metaspace代替了1.7以前的PermGen永久代)；CCS表示的是NoKlass Metaspace的使用率也就是CCSU，/CCSC算出来的，具体可参看这里，总之在1.7之前，M所在的位置是P，表示永久代使用的比例；YGC代表程序运行以来共发生Minor GC；YGCT表示其所用的时间；FGC代表程序运行以来共发生Full GC；FGCT表示其所用的时间；GCT表示GC总共花费了所长时间。

jinfo:Java配置信息工具

格式：jinfo [option] pid

作用：实时的查看和调整java虚拟机各项参数。

jmap:Java内存映像工具

格式：jmap [option] vmid

作用：用于生成堆转储快照（一般称为heapdump或dump文件）。

jhat:虚拟机堆转储快照分析工具

作用：配合jmap命令，分析dump文件。jhat内置了一个微型的HTTP/HTML服务器，生成dump文件的分析结果可以在浏览器中查看。

命令：jhat dumpfile

一般使用专业的工具进行分析，例如：VisualVM，Eclipse Memory Analyzer，IBM HeapAnalyzer等。

jstack:Java堆栈跟踪工具

格式：jstack [option] vmid

作用：用于生成虚拟机当前时刻的线程快照，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等都是导致线程长时间停顿的常见原因。线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做些什么事情，或者等待着什么资源。

类文件结构

1. 无关性的基石

任何语言，不局限于Java，都可以在虚拟机上运行。Java虚拟机不care .class文件来自何种语言。

2. Class类文件结构(这部分看不懂，需要汇编知识，后续补充)

Class文件是一组以8位字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑地排列在Class文件之中，中间没有添加任何分隔符

根据Java虚拟机规范规定，Class文件中采用类似C语言结构体中的伪结构体来存储数据，这种结构体中只存在两种数据结构：无符号数和表。

• 无符号数属于基本的数据类型，以u1、u2、u4、u8来分别代表1个字节、2个字节、4个字节和8个字节的无符号数，无符号数可以用来描述数字、索引引用、数量值或者按照UTF-8编码构成字符串值。

• 表是由多个无符号数或者其他表作为数据项构成的复合数据类型，所有表都习惯性地以“_info”结尾。表用于描述有层次关系的复合结构的数据，整个Class文件本质上就是一张表

2.1 魔数和Class文件的版本

每个Class文件的头4个字节被称为魔数，它的唯一作用是确定这个文件是否为一个能被虚拟机接受的Class文件。Class文件的魔数为：0xCAFFEEBABE。紧接着魔数的4个字节存储的是Class文件的版本号：第5和第6个字节是次版本号（Minor Version），第7和第8个字节是主版本号（Major Version）。Java的版本号是从45开始的，JDK 1.1之后的每个JDK大版本发布主版本号向上加1（JDK 1.0～1.1使用了45.0～45.3的版本号），高版本的JDK能向下兼容以前版本的Class文件，但不能运行以后版本的Class文件，即使文件格式并未发生任何变化，虚拟机也必须拒绝执行超过其版本号的Class文件。

2.2 常量池

紧接着主版本号后面的是常量池入口。

虚拟机类加载机制

类的生命周期

上图所示，类加载过程包含：加载，验证，准备，解析，初始化，使用，卸载。其中加载，验证，准备，初始化，卸载这5个阶段的顺序是确定。而解析阶段不一定，某些时候可以在初始化之后才进行解析，这是为了支持Java中动态绑定。什么时候开始类加载的一个过程：加载？虚拟机规范中没有严格的约束，交给虚拟机的实现去具体把握。但是对于初始化，虚拟机规范中严格规定了5中场景必须进行初始化：

• 使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。

• 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。

• 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

• 当虚拟机启动时，用户需要指定一个要执行的主类（包含main（）方法的那个类），虚拟机会先初始化这个主类。

• 当使用JDK 1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REFgetStatic、REFputStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

以上5种场景称为主动引用，会首先进行初始化，除此之外，所有引用类的方式都不会触发初始化，称为被动引用。

被动引用例子一：

以上执行的结果如下：

为什么只会打印出"SuperClass init !"？因为对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过其子类来引用父类中定义的静态，只会触发父类的初始化而不会触发子类的初始化。

被动引用例子二：

以上执行结果也没有输出ConstClass Init ~~，原因是常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。

类加载机制

加载

“加载”是“类加载”过程中的一个阶段。在加载阶段，虚拟机会做3件事：

• 通过一个类的全限定名来获取定义此类的二进制字节流。

• 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

• 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

这三点并不具体，例如第一点，Java虚拟机规范并没有指定二进制字节流要从哪一个Class文件中获取，怎么去获取。所以Java可以从：

• zip，jar，ear，war等格式中加载

• 从网络中获取，典型应用场景就是Applet

• 运行时计算生成，这种场景用的最多的就是动态代理

• 由其他文件生成，如JSP

验证

验证是连接阶段的第一步。目的是确保Class文件的字节流中包含的信息不会危害到虚拟机自身的安全。包含：文件格式验证，元数据验证，字节码验证，符号引用验证。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。其中初始值“通常情况下”是数据类型的零值。假设一个类变量的定义为：

public static int value = 123;

那变量在准备阶段过后的初始值是0而不是123，因为这时候尚未进行任何的Java方法，而把value赋值为123是在初始化阶段。但是如果上面的类变量定义为：

public static final int value = 123;

那么在编译阶段javac会为value生成ConstantValue属性，并且在准备阶段value就会被赋值为123。

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。

初始化

类初始化阶段是类加载的最后一步，初始化阶段是执行类构造器()方法的过程，()方法是由编译器自动收集类中所有类变量的赋值动作和静态语句块中的语句合并产生的。

()方法与类的构造函数()不同，它不需要显示的调用父类构造器，虚拟机会保证在子类的()方法执行之前，父类的()方法已经执行完毕。所以在虚拟机中第一个被执行的()方法的类必定是java.lang.Object。

()对于类或接口来说并不是必须的，如果类中没有静态语句块，也没有对变量的赋值操作，那么编译器不会生成该方法。

接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口也会生成()。但接口和类不同的是：执行接口的()不需要先执行父接口的()，只有当父接口中定义的变量被使用时，父接口才会初始化。另外接口的实现类在初始化也一样不会执行接口的()

类加载器

类与类加载器

对于任意一个类，都需要由他的类加载器和这个类本身共同确立其在Java虚拟机中的唯一性。每一个类加载器，都拥有一个独立的类名称空间。简言之，比较两个类是否“相等”只有在这两个类是由同一个类加载器加载的前提下才有意义。

如下例子：

最后的运行结果为：

可以看出，我们自己实现的类加载器确实加载并实例化了类com.alibaba.jvm.ClassLoaderTest的，但是实例化对象在与类com.alibaba.jvm.ClassLoaderTest做类型检查的时候却返回了false。因为虚拟机中存在两个com.alibaba.jvm.ClassLoaderTest类，一个是系统类加载器加载，另一个是由我们自己实现的加载器加载的，虽然这两个类来自同一个Class文件但是却是两个独立的类。

双亲委派模型

从Java虚拟机的角度来讲，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；另一种就是所有其他的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。

从Java开发人员的角度来看，有三种类加载器：

• 启动类加载器(Bootstrap ClassLoader)：负责加载\lib目录或者由参数-Xbootclasspath指定路径中并且是虚拟机识别的类库加载到虚拟机内存中。

• 扩展类加载器(Extension ClassLoader)：负责加载\lib\ext目录中或者被java.ext.dirs系统变量指定路径中所有的类库。

• 应用程序加载器(Application ClassLoader)：负责加载由CLASSPATH指定的类库，如果程序没有自定义类加载器，程序默认使用该加载器。

下图是类加载器的双亲委派模型：

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

Q：为什么要采用双亲委派模型？

A：例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。

实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass（）方法之中，逻辑如下：先检查是否已经被加载过，若没有加载则调用父加载器的loadClass（）方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass（）方法进行加载。下面是loadClass()方法：

虚拟机字节码执行引擎

一. 运行时栈帧

栈帧是用于支持虚拟机进行方法调用和方法执行的数据结构。栈帧存储了方法的局部变量表、操作数栈、动态连接和方法返回地址等信息。每一个方法从调用开始到执行完成的过程都对应着一个栈帧在虚拟机栈里面从入栈到出栈的过程。

1.局部变量表

局部变量表是一组变量值存储空间，用于存放方法参数和方法内部定义的局部变量。Java程序编译为Class文件时，就在方法的Code属性的max_locals数据项中确定了该方法所需要分配的局部变量表的最大容量。局部变量表的铜梁以变量槽(Slot)为最小单位，Java虚拟机规范说一个Slot应该能存放一个boolean，byte，char，short，int，floot，reference以及returnAddress类型的数据。为了节省空间，Slot是可以重用的。

2. 操作数栈

3. 动态连接

4. 方法返回地址

二. 方法调用

方法调用不等同于方法执行。方法调用阶段唯一的任务就是确定被调用方法的版本，即调用哪一个方法，不涉及方法内部的具体运行过程。

解析

所有方法在调用中的目标方法在Class文件中都是一个常量池中的符号引用，在类加载期间，会将其中部分符号引用转化为直接引用。这类方法必须满足：方法在程序真正运行之前就有一个可确定的调用版本，并且这个版本在运行期间是不可改变的。

在Java中符合“编译器可知，运行期间不可变” 这个要求的方法主要包括静态方法和私有方法。因为这两类方法都不能被继承或重写。在JVM中，凡是能被invokestatic和invokespecial指令调用的方法都可以在解析阶段唯一确定调用版本，符合这个条件的方法有：静态方法，私有方法，实例构造方法，父类方法4类。

解析调用一定是一个静态的过程，在编译器就完全的确定，不会延迟到运行期间再去完成。

Tomcat类加载器架构

服务器都会解决几个问题：部署在同一个服务器上的两个web应用程序所使用的java类库可以实现相互隔离以及相互共享，服务器自身的类库应该与应用程序的类库隔离。

解决办法：服务器会提供好几个classpath路径供用户存放第三方类库，被放置到不同路径中的类库，具备不同的访问范围和服务对象。通常，每个目录都会有一个相应的自定义类加载器去加载放在里面的Java类库。以tomcat为例：tomcat目录结构中，有4组目录(/common/*，/server/*，/shared/*，/WEB-INF/*)可以存放Java类库:

• /common目录：类库可以被Tomcat和所有的web应用程序共用

• /shared目录：类库可以被所有web应用程序共用，但对tomcat不可见

• /server目录：类库可以被tomcat使用，但是对所有的web应用程序不可见

• /WEB-INF目录：类库仅仅可以被此web程序使用