JVM(三)—对象的访问定位,OutOfMemoryError 异常，类的加载机制

创建完对象，到了使用对象的时候，通常声明一个同类型的引用指向该类型的对象，由这个引用来操作对象的字段、方法等。

1
Object obj = new Object();

我们的Java程序需要通过栈上的 reference 数据来操作堆上的具体对象，目前主流的访问方式有使用句柄和直接指针两种，我更青睐于后者，或者说基本只使用后者，那么，我简要介绍一下如何通过直接指针访问对象。

采用直接指针访问，那么Java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，而 reference 中存储的直接就是对象地址，如图篇首。

使用这种方式的最大好处就是速度更快。就虚拟机 Sun HotSpot 而言，它是使用了直接指针访问方式记性对象访问。

Java 堆溢出

Java 堆是创建对象的区域，当GC来不及清除这些对象，并且对象数量达到最大堆的容量限制后就会产生内存溢出异常。

Java 堆可以自动扩展，如果将 -Xms（堆最小值）和 -Xmx（堆最大值）设置为一样可以避免堆自动扩展。

Java 堆内存的 OOM 异常是实际应用中常见的内存溢出情况。当 Java 堆出现 OOM 异常时，会提示错误信息：

1
java.lang.OutOfMemoryError: Java heap sapce

值得注意的是，此时异常还分为两种：

• 内存泄露（Memroy Leak）
• 对象本应该被 GC 回收，而未被回收。内存从 GC 中泄露出来。
• 内存溢出（Memory Overflow）
• 对象都还必须存活（JVM会判断），这些对象占的内存超出了Java堆的最大容量。此时最直接的方法就是调大物理内存。

两者的唯一区别就是，GC没有清除的对象是否是必要的存在的。

虚拟机栈

由于在HotSpot虚拟机中并不区分虚拟机栈和本地方法栈，所以，-Xoss参数（本地方法栈大小）没有是实际作用。栈容量只由 -Xss 参数设定。

在虚拟机栈中，存在两种异常：

• SatckOverflowError
• 线程请求的站深度大于虚拟机栈所允许的最大深度
• OutOfMemoryError
• 虚拟机在扩展时无法申请到足够的内存空间（同java堆）

当在单线程环境中，只会出现 StackOverflowError 异常。切换至多线程后，会出现 OutOfMemoryError 异常。

看起来，可以通过增大内存空间来缓解或者解决虚拟机栈的 OOM，但是，通过 Java 运行时的数据区域分析得知：

1
物理机总内存 = 程序计数器消耗内存 + Xmx（最大 Java堆容量）+ MaxPermSize（最大方法区容量）+ Xss（虚拟机栈容量）+ Xoss（本地栈容量）

由于程序计数器消耗内存很小，忽略不计。并且将本地栈容量归为虚拟机栈容量管理的话，那么：

1
Xss（虚拟机栈容量）= 物理机总内存 - Xmx（最大 Java堆容量）- MaxPermSize（最大方法区容量）

虚拟机栈是线程的“私有内存”，目的是线程分配运行时需要的内存容量，所以有：

1
Xss（虚拟机栈容量）= 线程数 * 线程栈容量

最后得到：

1
线程数 * 线程栈容量 = 物理机总内存 - Xmx（最大 Java堆容量）- MaxPermSize（最大方法区容量）

在实际情况中，我们希望得到更高的并发量，也就是增大线程数量，此时，有三种方法：

• 增大物理机总内存
• 减小java堆内存、方法区容量
• 减小线程栈容量

作为开发人员，能做的，也就是后两者。第一条不说申请流程复杂，就算是增加了，那也可能是个无底洞。

概述

如篇首图所示，Class 文件被 JVM 加载至 JVM内存，在内存中验证、解析、初始化之后，形成可以被 JVM 直接使用的 Java类型。这就是类加载的简要过程。类的加载过程是在 Java程序运行期间完成，虽然会损耗一部分性能，但是提高了Java语言的灵活性，体现在动态扩展方面，例如：多态（晚期绑定）。

类加载的时机

类的生命周期

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：

• 加载
• 验证
• 准备
• 解析
• 初始化
• 使用
• 卸载

其中，验证、准备和解析三个部分称为连接。解析和初始化的相对顺序不是固定的，当解析在初始化之后执行时，称为动态绑定或者晚期绑定，例如：晚期绑定的多态特性。

初始化

在 JVM 规范中没有强制约束加载的时机，不过对于初始化，JVM有严格的规范，根据《深刻理解JVM虚拟机》所述，有且只有5种情况必须对类进行初始化，但是我只能理解其中3种：

• 遇到 new、getstatic、putstatic或invokestatic 这4条指令时
• 如果类没有进行过初始化，则需要先触发其初始化。getstatic指读取一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）；invokestatic指调用一个类的静态方法。
• 使用 java.lang.reflect 包的方法对类进行反射调用的时候
• 如果类没有进行过初始化，则需要先触发其初始化。
• 派生类
• 初始化一个派生类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类

上述三种情况，被称为对一个类进行 主动引用。除此之外的引用类被称为 被动引用，不会触发初始化。

• 通过子类引用父类的静态字段，父类初始化，但子类不会初始化

package com.zhoupq.jvm.calssload;
public class SuperClass
{
	static
	{
		System.out.println("SuperClass init!");
	}
	
	public static int i = 1;
	
}
public class SubClass extends SuperClass
{
	
	static 
	{
		System.out.println("SubClass init!");
	}
}
public class TestApp
{
	public static void main(String[] args)
	{
		System.out.println(SubClass.i);
	}
}
/*
SuperClass init!
1
*/

类加载的过程

加载

在家在阶段，虚拟机需要完成以下三件事情：

• 通过一个类的全限定名来获取定义此类的二进制字节流
• 可以从一个java文件、jsp文件获取class文件，即生成一个对应的class类。
• 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
• 在内存中生成一个代表这个类的java.lang.Class对象，作为这个方法区这个类的各种数据的访问入口

加载阶段与连接阶段的部分内容是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始。

验证

验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件中的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

准备

准备阶段是正式为类变量（被static修饰的变量）分配内存并设置类变量初始值（0值）的阶段，这些变量所使用的内存都将在方法区中进行分配。

方法区中分配的是静态变量的内存，并为其设置0值，具体的值将在初始化阶段后再赋值。成员变量（实例变量）随对象一起在java堆中分配内存，具体的值也是在初始化阶段后再赋值。

但是如果静态变量被 final 修饰，那么该静态变量在准备阶段就会被赋实际的值。

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。在 JVM（三）——对象的访问定位中有介绍什么是直接引用。

初始化

初始化阶段是类加载过程的最后一步，在此之前的阶段，基本都是由迅疾主导和控制，在此阶段，才真正开始执行类中定义的 Java 程序代码。

在准备阶段，类变量已经赋过一次初始值（0值），在此阶段，则根据程序员的主观计划去初始化类变量和其他资源。

有一种说法：

初始化阶段是执行类构造器 < clinit>()方法的过程

• 类构造器< clinit>() 方法 与 实例构造器< init>()方法（构造方法） 不同，它不需要显示地调用父类构造器，虚拟机会保证在子类的< clinit>() 方法执行前，父类的< clinit>()方法已经执行完毕。因此在虚拟机中，第一个被执行的< clinit>()方法的类肯定是 java.lang.Object。
• < clinit>() 方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的。如果没有静态语句块，也没有对类变量的赋值操作，那么编译器可以不生成< clinit>()方法。
• 由于父类的< clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量复制操作。
• 接口中不能使用静态语句块，但是仍然有变量初始化的赋值操作，因为接口与类一样，都会生成< clinit>()方法。但接口与类不同的是，执行接口的< clinit>()方法不需要先执行父接口的< clinit>()方法。只有当父接口中定义的变量使用时，父接口才会初始化。实现类与接口不是继承关系，所以不存在< clinit>()方法执行的先后顺序。
• 在多线程中，虚拟机会保证一个类的< clinit>()方法在被正确地加锁、同步，只会有一个线程去执行这个类的< clinit>()方法，其他线程都需要阻塞等待，知道活动线程执行< clinit>()方法完毕。并且< clinit>()方法只会被执行一次，当其他线程被唤醒后，是不会再进入< clinit>()方法。