Java代码执行流程

  • Java代码执行流程
    Java源程序(.java文件)—经过Java编译器编译—>字节码文件(多个.class文件)—执行—>版本JVM虚拟机(在虚拟机中,将字节码文件编译成机器指令)。
  • JVM的生命周期
    • 虚拟机的启动:Java虚拟机的启动是通过引导类加载器(bootstrap class loader)创建一个初始类(initial class)来完成的,这个类是由虚拟机的具体实现指定的。
    • 虚拟机的执行:一个运行的Java虚拟机有着一个清晰的任务,即执行Java程序。程序开始执行时它才执行,程序结束时它才结束。执行一个Java程序时,真正在执行的是一个叫做Java虚拟机的进程。
    • 虚拟机的退出,有如下几种情况:
      • 程序正常执行结束;
      • 程序在执行过程中遇到了异常或错误而异常终止;
      • 由于操作系统出现错误而导致Java虚拟机进程终止;
      • 某线程调用Runtime类或System类的exit方法,或Runtime类的halt方法,并且Java安全管理器也允许这次exit或halt操作;
      • 除此之外,JNI(Java Native Interface)规范描述了用JNI Invocation API来加载或卸载Java虚拟机时,Java虚拟机的退出情况。
  • JVM有不同的版本,包括SUN Classic VM、Exact VM、HotSpot VM、JRockit VM、IBM J9 VM等,主流使用HotSpot VM。

JVM架构图

  • JVM架构图

image-20210115135153104.png

类加载器子系统

类加载器子系统,负责从文件系统或网络中加载Class文件,Class文件在文件开头有特定的文件标识(cafebaby)。ClassLoader只负责class文件的加载,至于能否运行则由ExecutionEngine(执行引擎)决定。类加载器子系统分为3个阶段,加载、链接、初始化。

加载

加载(Loading)阶段:引导类加载器、扩展类加载器、系统类加载器。

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

类加载器分类

  • 引导类加载器>扩展类加载器>系统类加载器,三者是一种包含关系,不是继承关系,下面所说的父类加载器和继承无关。

1、引导类加载器(启动类加载器,Bootstrap ClassLoader) 这个类加载器使用C/C++语言实现的,嵌套在JVM内部。它用来加载Java的核心库,用于提供JVM自身需要的类。并不继承自java.lang.ClassLoader,没有父加载器。加载扩展类加载器和系统类加载器,并指定为他们的父类加载器。出于安全考虑,Bootstrap 启动类加载器只加载包名为java、javax、sun等开头的类。 2、扩展类加载器(Extension ClassLoader) Java语言编写,派生于ClassLoader类,父类加载器为启动类加载器。 3、系统类加载器(应用程序类加载器,AppClassLoader) Java语言编写,派生于ClassLoader类,父类加载器为扩展类加载器,负责加载环境变量classpath或系统属性java.class.path指定路径下的类库。它是程序中默认的类加载器,一般来说,Java应用的类都是由它来完成加载,通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器。 4、用户自定义类加载器 在Java日常应用开发中,类的加载几乎是由上述3种类加载器相互配合执行的,必要时可以自定义类加载器来制定类的加载方式。

  • 类加载器分为引导类加载器和自定义类加载器。其中扩展类加载器、系统类加载器都属于自定义类加载器,Java虚拟机规范中定义所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。

获取类加载器ClassLoader的途径 1、获取当前类的ClassLoader clazz.getClassLoader() 2、获取当前线程上下文的ClassLoader Thread.currentThread().getContextClassLoader() 3、获取系统的ClassLoader ClassLoader.getSystemClassLoader() 4、获取调用者的ClassLoader DriverManager.getCallerClassLoader()

  1. //获取当前类的ClassLoader
  2. try {
  3. System.out.println(Class.forName("java.lang.String").getClassLoader());
  4. } catch (ClassNotFoundException e) {
  5. e.printStackTrace();
  6. }
  7. //获取当前线程上下文的ClassLoader
  8. System.out.println(Thread.currentThread().getContextClassLoader());
  9. //获取系统的ClassLoader
  10. System.out.println(ClassLoader.getSystemClassLoader());

双亲委派机制

Java虚拟机对class文件采用的是按需加载方式,加载某个类的class文件时Java虚拟机采用双亲委派模式,即把请求交由父类处理,它是一种任务委派模式。

  • 工作原理:如果一个类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请求委托给父类的加载器去执行。如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终将到达顶层的启动类加载器。如果父类加载器可以完成类加载任务,就成功返回,倘若父类加载器无法完成此加载任务子类加载器才会尝试自己去加载,这就是双亲委派模式。
  • 优势:
    • 避免类的重复加载;
    • 保护程序安全,防止核心API被随意篡改,这种保护就是沙箱安全机制

链接

链接(Linking)阶段:验证、准备、解析。

  • 验证(Verify):确保Class文件的字节流中包含信息符合当前虚拟机要求,保证被加载类的正确性不会危害虚拟机自身安全。主要包括文件格式验证、元数据验证、字节码验证、符号引用验证。
  • 准备(Prepare):为类变量分配内存并且设置该类变量的默认初始值。这里不包含用final修饰的static,因为final在编译的时候就会分配。这里也不会为实例变量分配初始化,类变量会分配在方法区中,而实例变量是会随着对象一起分配到Java堆中。
  • 解析(Resolve):将常量池内的符号引用转换为直接引用的过程。事实上,解析往往会伴随着JVM在执行完初始化之后再执行。

初始化

初始化(Initialization)阶段。

初始化阶段就是执行类构造器方法()的过程。此方法不需要定义,是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。构造器方法中指令按语句在源文件中出现的顺序执行。若该类具有父类,JVM会保证子类的()执行前,父类的()已经执行完毕。虚拟机必须保证一个类的()方法在多线程下被同步加锁。

注意,()不同于类的构造器,构造器是虚拟机视角下的()。

加载的类信息存放在方法区。除了类的信息外,方法区中还会存放运行时常量池信息,可能还包括字符串字面量和数字常量(这部分常量信息是Class文件中常量池部分的内存映射)。

其他

  • 相同类
    在JVM中表示两个class对象是否为同一个类存在两个必要条件:类的完整类名必须一致,包括类名;加载这个类的ClassLoader(指ClassLoader实例对象)必须相同。
    换句话说,在JVM中,即使两个类对象来源于同一个Class文件,被同一个虚拟机所加载,但只要加载它们的ClassLoader实例对象不同,那么这两个类对象也是不相等的。
  • 类加载器的引用
    JVM必须知道一个类型是由启动类加载器加载的还是由用户类加载器加载的。如果一个类型是由用户类加载器加载的,那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。当解析一个类型到另一个类型的引用的时候,JVM需要保证这两个类型的类加载器是相同的。
  • 类的主动使用和被动使用
    主动使用:
    • 创建类的实例;
    • 访问某个类或接口的静态变量,或者对该静态类变量赋值;
    • 调用类的静态方法;
    • 反射;
    • 初始化一个类的子类;
    • Java虚拟机启动时被标明为启动类的类;
    • JDK7开始提供的动态语言支持:java.lang.invoke.MethodHandle实例的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic句柄对应的类没有初始化,则初始化。

除了上述情况,其他使用Java类的方式都被看作是类的被动使用,类的被动使用不会导致类的初始化。

运行时数据区

Java虚拟机定义了若干种程序运行期间会使用到的运行时数据区,其中有一些会随着虚拟机启动而创建,随着虚拟机退出而销毁,即与进程是对应的。另外一些则是与线程一一对应的,这些与线程对应的数据区域会随着线程开始和结束而创建和销毁。

每个线程,独立拥有各自的程序计数器、栈、本地栈; 线程之间,共享堆区、方法区(永久代或元空间、代码缓存)。

线程

线程是一个程序里的运行单元。JVM允许一个应用有多个线程并行的执行。

在HotSpot JVM里,每个线程都与操作系统的本地线程直接映射。当一个Java线程准备好执行以后,此时一个操作系统的本地线程也同时创建。Java线程执行终止后,本地线程也会回收。操作系统负责所有线程的安排调度到任何一个可用的CPU上,一旦本地线程初始化成功,他就会调用Java线程中的run()方法。

一般后台有许多线程在运行,这些后台线程不包括调用main方法分main线程以及所有这个main线程自己创建的线程。 这些主要的后台系统线程在HotSpot JVm里主要是以下几个:

  • 虚拟机线程:这种线程的操作是需要JVM达到安全点才会出现。这些操作必须在不同的线程中发生的原因是它们需要JVM达到安全点,这样堆才不会变化。这种线程的执行类型包括“stop-the-world”的垃圾收集,线程栈收集,线程挂起以及偏向所撤销。
  • 周期任务线程:这种线程是时间周期事件的体现(比如中断),他们一般用于周期性操作的调度执行。
  • GC线程:这种线程对于在JVM里不同种类的垃圾收集行为提供了支持。
  • 编译线程:这种线程在运行时会将字节码编译成本地代码。
  • 信号调度线程:这种线程接收信号并发送给JVM,在它内部通过调用适当的方法进行出路。

程序计数器(PC寄存器)

PC寄存器用来存储指向下一条指令的地址,也就是将要执行的指令代码。由执行引擎读取下一条指令。

它是一块很小的内存空间,几乎可以忽略不计。也是运行速度对快的存储区域。在JVM规范中,每个线程都有它自己的程序计数器,是线程私有的,生命周期与线程的生命周期保持一致。任何时间一个线程都只有一个方法在执行,也就是所谓的当前方法。程序计数器会存储当前线程正在执行的Java方法的JVM指令地址;或者,如果是在执行native方法,则是未指定值(undefined)。

它是程序控制流的指示器,分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。它是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。它既没有GC,也没有OOM。

  • 使用PC寄存器存储字节码指令地址有什么用?
    CPU需要不停切换各个线程,这时候切换回来以后,就得知道接着从哪开始继续执行。JVM的字节码解释器就需要通过改变PC寄存器的值来明确下一条应该执行什么样的字节码指令。
  • PC寄存器为什么会被设定为私有?
    我们都知道所谓的多线程在一个特定的时间段内只会执行其中某一个线程的方法,CPU会不停地做任务切换,这样必然导致经常中断或恢复。为了能够精确地记录各个线程正在执行的当前字节码指令地址,最好的办法自然是为每一个线程都分配一个PC寄存器,这样一来各个线程之间便可以进行独立计算,从而不会出现相互干扰的情况。

虚拟机栈

由于跨平台性的设计,Java的指令都是根据栈来设计的。不同平台CPU架构不同,所以不能设计为基于寄存器的。优点是跨平台,指令集小,编译器容易实现;缺点是性能下降,实现同样的功能需要更多的指令。

内存中的栈与堆: 栈是运行时的单位,堆是存储的单位。栈解决程序的运行问题,即程序如何执行,或者说如何处理数据。堆解决的是数据存储的问题,即数据怎么放、放在哪。

每个线程在创建时都会创建一个虚拟机栈,其内部保存一个个的栈帧(Stack Frame),对应着一次次的Java方法调用。Java虚拟机栈(Java Virtual Machine Stack)也叫Java栈,是线程私有的,生命周期和线程一致。主管Java程序的运行,它保存方法的局部变量、部分结果,并参与方法的调用和返回。

栈是一种快速有效的分配存储方式,访问速度仅次于程序计数器。

JVM直接对Java栈的操作只有两个,入栈和出栈。每个方法的执行,伴随着进栈(入栈、压栈);执行结束后的出栈工作。

对于栈来说不存在垃圾回收问题。

  • 栈可能出现的异常
    Java虚拟机规范允许Java栈的大小是动态的或者是固定不变的。
    如果采用固定大小的Java虚拟机栈,那每一个线程的Java虚拟机容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过Java虚拟机栈允许的最大容量,Java虚拟机将会抛出一个StackOverflowError异常。
    如果Java虚拟机栈可以动态扩展,并且在尝试扩展的时候无法申请到足够的内存,或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈,那么Java虚拟机会抛出OutOfMemoryError异常。
  • 调整虚拟机栈大小
    命令:-Xss
    例如 -Xss1024k,不加单位为默认的字节单位。
  • 栈的内部结构
    每个线程都有自己的栈,栈中的数据都是以栈帧的格式存在。在这个线程上正在执行的每个方法都各自对应一个栈帧。栈帧是一个内存区块,是一个数据集,维系着方法执行过程中的各种数据信息。
    在一条活动线程中,一个时间点上,只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧(栈顶栈帧)是有效的,这个栈帧被称为当前栈帧(Current Frame),与当前栈帧对应的方法就是当前方法(Current Method),定义这个方法的类就是当前类(Current Class)。
    执行引擎运行的所有字节码指令只针对当前栈帧进行操作。如果在该方法中调用了其他方法,对应的新的栈帧会被创建出来,放在栈的顶端,成为新的当前帧。方法返回之际,当前栈帧会传回此方法的执行结果给前一个栈帧,接着,虚拟机会丢弃当前栈帧,使得前一个栈帧重新成为当前栈帧。Java方法有两种返回函数的方式,一种是正常的函数返回,使用return指令;另一种是抛出异常。不管使用哪种方式,都会导致栈帧被弹出。
    每个栈帧中存储着局部变量表操作数栈(或表达式栈)、动态链接(或指向运行时常量池的方法引用)、方法返回地址(或方法正常退出/异常退出的定义)以及一些附加信息

局部变量表

局部变量表(local variables)也被称为局部变量数组或本地变量表。

定义为一个数字数组(一维的表),主要用于存储方法参数和定义在方法体内的局部变量,这些数据类型包括各类基本数据类型、对象引用(reference)以及returnAddress类型。由于局部变量表是建立在线程的栈上,是线程的私有数据,因此不存在数据安全问题。

  • 表的大小
    局部变量表所需要的容量大小是在编译期确定下来的,并保存在方法的Code属性的maximum local variable数据项中,在方法运行期间是不会改变局部变量表的大小的。
  • slot
    参数值的存放总是在局部变量数组的index0开始,到数组长度-1(length-1)的索引结束。局部变量表,最基本的存储单元是Slot(变量槽)。在局部变量表里,32位以内的类型只占用一个slot(包括returnAddress类型),64位的类型(long和double)占用两个slot。byte、short、char在存储前被转换为int,boolean也被转化为int,0表示false,非0表示true。
  • slot的重复利用
    栈帧中的局部变量表中的槽位是可以重用的。如果一个局部变量过了其作用域,那么在其作用域之后声明的新的局部变量就很有可能会复用过期局部变量的槽位,从而达到节省资源的目的。
  • 垃圾回收根节点
    局部变量表中的变量也是重要的垃圾回收根节点,只要被局部变量表中直接或间接引用的对象都不会被回收。

操作数栈

每一个独立的栈帧中除了包含局部变量表以外,还包含一个后进先出的操作数栈(Operand Stack),也可以称之为表达式栈(Expression Stack)。操作数栈,在方法执行过程中,根据字节码指令,往栈中写入数据或提取数据,即入栈(push)/出栈(pop)。

操作数栈主要用于保存计算过程的中间结果,同时作为计算过程中变量临时的存储空间。

  • 栈的大小
    操作数栈就是JVM执行引擎的一个工作区,当一个方法刚开始执行的时候一个新的栈帧也会随之被创建出来,这个方法的操作数栈是空的。每一个操作数栈都会拥有一个明确的栈深度用于存储数值,其所需的最大深度在编译期就定义好了,保存在方法的Code属性中,为max_stack的值。
  • 栈内存储
    栈中任何一个元素都可以是任意的Java数据类型。32bit的类型占用一个栈单位深度,64bit的类型占用两个单位深度。
  • 栈的访问
    操作数栈并非采用访问索引的方式来进行数据访问的,而是只能通过标准的入栈和出栈操作来完成一次数据访问。

如果被调用的方法带有返回值的话,其返回值将会被压入当前栈帧的操作数栈中,并更新PC寄存器中下一条需要执行的字节码指令。另外,Java虚拟机的解释引擎是基于栈的执行引擎,这里的栈指的就是操作数栈。

栈顶缓存技术
由于操作数是存储在内存中的,因此频繁地执行内存读写操作必然会影响执行速度。为了解决这个问题,就有了栈顶缓存技术(ToS,Top-of-Stack Cashing)技术,将栈顶元素全部缓存在物理CPU的寄存器中,以此降低对内存的读写次数,提升执行引擎的执行效率。

动态链接

每一个栈帧内部都包含一个指向运行时常量池中该栈帧所属方法的引用。包含这个引用的目的就是为了支持当前方法的代码能够实现动态链接(Dynamic Linking)。在Java源文件被编译到字节码文件中时,所有的变量和方法引用都作为符号引用(Symbolic Reference)保存在class文件的常量池里。一个方法调用了其他方法时,通过常量池中指向方法的符号引用来表示,动态链接的作用就是为了将这些符号引用转换为调用方法的直接引用。

方法的调用

在JVM中,将符号引用转换为调用方法的直接引用与方法的绑定机制相关。

  • 静态链接
    当一个字节码文件被装载进JVM内部时,如果被调用的目标方法在编译期可知,且运行期保持不变,这种将调用方法的符号引用转换为直接引用的过程称为静态链接。
  • 动态链接
    被调用的方法在编译期无法被确定下来,即只能够在程序运行期将调用方法的符号引用转换为直接引用,这种被称为动态链接。
  • 绑定
    绑定是一个字段、方法或者类在符号引用被替换为直接引用的过程,这仅仅发生一次。绑定分为早期绑定与晚期绑定,早期绑定对应静态链接,晚期绑定对应动态绑定。
  • 非虚方法与虚方法
    如果方法在编译期就确定了具体的调用版本,这个版本在运行时是不可变的,这样的方法称为非虚方法。静态方法、私有方法、final方法、实例构造器、父类方法都是非虚方法,其他方法称为虚方法。
  • 调用指令
    虚拟机中提供了以下几条方法调用指令:
    • invokestatic:调用静态方法,解析阶段确定唯一方法版本;
    • invokespecial:调用方法、私有及父类方法,解析阶段确定唯一方法版本;
    • invokevirtual:调用所有虚方法;
    • invokeinterface:调用接口方法;
    • invokedynamic:动态解析出需要调用的方法,然后执行。

前四条指令固化在虚拟机内部,方法的调用执行不可人为干预,而invokedynamic指令则支持由用户确定方法版本。其中invokestatic指令和invokespecial指令调用的方法称为非虚方法,其余(final修饰的除外)的称为虚方法。

方法返回地址

方法返回地址(return address)存放调用该方法的pc寄存器的值。

一个方法的结束有两种方式:正常执行完成;出现未处理的异常,非正式退出。无论通过哪种方式退出,在方法退出后都返回到该方法被调用的位置。方法正常退出时,调用者的pc寄存器的值作为返回地址,即调用该方法的指令的下一条指令的地址。而通过异常退出的,返回地址是要通过异常表来确定,栈帧中一般不会保存这部分信息。

本质上,方法的退出就是当前栈帧出栈的过程。此时,需要恢复上层方法的局部变量表、操作数栈、将返回值压入调用者栈帧的操作数栈、设置PC寄存器值等,让调用者方法继续执行下去。正常完成出口和异常完成出口的区别在于,通过异常完成出口退出的不会给它的上层调用者产生任何的返回值。

本地方法栈

Java虚拟机用于管理Java方法的调用,而本地方法栈(Native Method Stack)用于管理本地方法的调用。具体做法是本地方法栈中登记native方法,在执行引擎执行时加载本地方法库。
和虚拟机栈所发挥的作⽤⾮常相似,区别是: 虚拟机栈为虚拟机执⾏ Java ⽅法 (也就是字节码)服务,⽽本地⽅法栈则为虚拟机使⽤到的 Native ⽅法服务。 本地⽅法被执⾏的时候,在本地⽅法栈也会创建⼀个栈帧,⽤于存放该本地⽅法的局部变量表、操作数栈、动态链接、出⼝信息。
⽅法执⾏完毕后相应的栈帧也会出栈并释放内存空间,也会出现 StackOverFlowErrorOutOfMemoryError 两种错误。

  • 本地方法栈,也是线程私有的。
  • 允许被实现成固定或者是可动态扩展的内存大小。

当某个线程调用一个本地方法时,它就进入了一个全新的并且不再受虚拟机限制的世界。它和虚拟机拥有同样的权限。

  • 本地方法可以通过本地方法接口来访问虚拟机内部的运行时数据区。
  • 它甚至可以直接使用本地处理器中的寄存器。
  • 直接从本地内存的堆中分配任意数量的内存。

并不是所有的JVM都支持本地方法,因为Java虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构等。在HotSpot JVM中,直接将本地方法栈和虚拟机栈合二为一。

一个进程只有一个JVM实例,一个JVM实例只存在一个堆内存,堆也是Java内存管理的核心区域。

Java堆区在JVM启动的时候即被创建,其空间大小也就确定了,是JVM管理的最大一块内存空间,堆内存的大小是可以调节的。《Java虚拟机规范》规定,堆可以处于物理上不连续的内存空间中,但在逻辑上它应该被视为连续的。所有的线程共享Java堆,在这里还可以划分线程私有的缓冲区(Thread Local Allocation Buffer,TLAB)。

在方法结束后,堆中的对象不会马上被移除,仅仅在垃圾收集的时候才会被移除。

现代垃圾收集器大部分都基于分代收集理论设计,

  • Java7及之前的堆内存在逻辑上分为三部分
    • 新生区(Young Generation Space)
    • 养老区(Tenure Generation Space)
    • 永久区(Permanent Space)
  • Java8及之后的堆内存逻辑上分为三部分
    • 新生区(Young Generation Space)
    • 养老区(Tenure Generation Space)
    • 元空间(Meta Space)

其实不分代也完全可以,分代的唯一目的就是优化GC性能,提升GC效率。

设置堆空间大小与OOM

Java堆区用于存储Java对象实例,那么堆的大小在JVM启动时就已经设定好了,可以通过命令”-Xms”、”-Xmx”设置。一旦堆区中的内存大小超过”-Xmx”所指定的最大内存时,将会抛出OutOfMemoryError异常。

  • “-Xms”用于表示堆区的起始内存,等价于”-XX:InitialHeapSize”
    “-X”是JVM的运行参数,”ms”是memory start。
  • “-Xmx”表示堆区的最大内存,等价于”-XX:MaxHeapSize”

通常会将”-Xms”、”-Xmx”两个参数配置相同的值,其目的是为了能够在Java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小,从而提高性能。默认情况下,初始内存大小是物理电脑内存大小的1/64,最大内存大小是物理电脑内存大小的1/4 。

  • 查看设置的参数
    • cmd命令:”jps”查看进程,”jstat -gc 进程id”查看进程参数
    • idea参数命令:”-XX:+PrintGCDetails”

年轻代与老年代

存储在JVM中的Java对象可以被划分为两类,一类是生命周期较短的瞬时对象,这类对象的创建和消亡都非常迅速;另一类对象的生命周期却非常长,在某些极端的情况下还能够与JVM的生命周期保持一致。

Java堆区进一步细分的话,可以划分为年轻代和老年代。其中年轻代又可以划分为Eden空间、Survivor0空间和Survivor1空间(或者叫做from区、to区)。
image.png

  • 老年代与新生代大小比例默认是2:1,可通过”-XX:NewRatio=2”设置比例,其中数字2可以自定义修改。例如”-XX:NewRatio=4”,表示新生代占1,老年代占4,新生代占整个堆的1/5 。当生命周期很长的对象非常多的时候,建立调大老年代的空间。在HotSpot中,Eden空间和另外两个Survivor空间所占比例是8:1:1,可以通过”-XX:SurvivorRatio”调整。

几乎所有的Java对象都是在Eden区被new出来的,除非Java对象特别大,大到Eden区都放不下,这样的情况下Java对象会被直接放在老年代。绝大部分Java对象的销毁都在新生代进行了,IBM公司的研究表明,新生代中80%的对象都是“朝生夕死”的。

  • 可以使用”-Xmn”设置新生代最大内存大小,当设置新生代内存大小和新老比例冲突的时候,以设置的新生代大小为准。

为新对象分配内存是一件非常严谨和复杂的任务,JVM的设计者们不仅需要考虑内存如何分配、在哪里分配等问题,并且由于内存分配算法与内存回收算法密切相关,所以还需要考虑GC执行完毕内存回回收后是否会在内存空间中产生内存碎片。 1、new的对象先放伊甸园区,此区有大小限制。 2、当伊甸园区的空间填满时,程序又需要创建对象,JVM的垃圾回收器将对伊甸园区进行垃圾回收(YGC/Minor GC),将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区。 3、然后将伊甸园区的剩余对象移动到幸存者0区。 4、如果再次触发垃圾回收,此时上次幸存下来的放到幸存者0区的,如果没有回收,就会放到幸存者1区。 5、如果再次经历垃圾回收,此时会重新放回幸存者0区,接着再去幸存者1区。 6、对象有一个age属性,初始值是1(从伊甸园放到幸存者0区会获得初始值),每次移动会+1,当值超过15(阈值)时会放到养老区。 可以设置参数:”-XX:MaxTenuringThreshold=“进行阈值设置。 7、在养老区,相对悠闲。当养老区内存不足时,再次触发GC:Major GC,进行养老区的内存清理。 8、若养老区执行了Major GC后发现依然无法进行对象的保存,就会产生OOM异常。

  • Eden区填满时会触发垃圾回收,但是Survivor区填满时不会触发垃圾回收。当Eden区填满时触发的垃圾回收也会对Survivor区进行垃圾回收。
  • 关于垃圾回收:频繁在新生区收集,很少在养老区收集,几乎不在元空间收集。

Minor、Major、Full GC

JVM在进行GC时,并非每次都对三个内存(新生代、老年代、方法区)区域一起回收,大部分回收的都是指新生代。在HotSpot VM中,GC按照回收区域分为两大种类型:部分收集(Partial GC)与整堆收集(Full GC)。

  • 部分收集:不是完整收集整个Java堆的垃圾收集。其中又分为:
    • 新生代收集(Minor GC / Young GC):只是新生代的垃圾收集;
      当年轻代空间不足时,就会触发Minor GC,这里的年轻代空间不足指Eden空间不足,Survivor空间不足不会引发GC(每次Minor GC会清理年轻代的内存)。
      因为Java对象大多数都具备朝生夕灭的特性,所以Minor GC非常频繁,一般回收速度也比较快。
      Minor GC会引发STW(Stop The World),暂停其他的线程用户,等垃圾回收结束,用户线程才恢复运行。
    • 老年代收集(Major GC / Old GC):只是老年代的垃圾收集;
      目前,只有CMS GC会有单独收集老年代的行为。出现了Major GC,经常会伴随着至少一次的Minor GC,也就是在老年代空间不足时,会尝试触发Minor GC。如果之后空间还不足,则触发Major GC。如果Major GC后,内存还不足,就OOM。
      注意,很多时候Major GC会和Full GC混淆使用,需要具体分辨是老年代回收还是整堆回收。
      Major GC的速度一般会比Minor GC慢10倍以上,STW的时间更长。
    • 混合收集(Mixed GC):收集整个新生代以及部分老年代的垃圾收集。
      目前,只有G1 GC会有这种行为。
  • 整堆收集(Full GC):收集整个Java堆和方法的垃圾收集。
    触发Full GC执行的情况有如下五种:
    • 调用System.gc()时,系统建议执行Full GC,但是不必然执行;
    • 老年代空间不足;
    • 方法区空间不足;
    • 通过Minor GC后进入老年代的平均大小大于老年代的可用内存;
    • 由Eden区、Survivor0区(From区)向Survivor1区(To区)复制时,对象大小大于To区可用内存,则把该对象转存到老年代,且老年代的可用内存小于该对象大小。

Full GC是开发或调优中尽量要避免的,这样暂停时间会短一些。

内存分配策略

针对不同年龄段的对象,分配原则如下:

  • 优先分配到Eden;
  • 大对象直接分配到老年代;
    尽量避免查询中出现过多的大对象,大对象就是需要大量连续内存空间的对象(字符串、数组),为了避免为大对象分配内存时由于分配担保机制带来的复制而降低效率。
  • 长期存活的对象分配到老年代;
  • 动态对象年龄判断
    如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象可以直接进入老年代,无需等到MaxTenuringThreshold中要求的年龄。
  • 空间分配担保
    “-XX:HandlePromotionFailure”

TLAB

堆区是线程共享区域,任何线程都可以访问到堆区中的共享数据。由于对象实例的创建在JVM中非常频繁,因此在并发环境下从堆区中划分内存空间是线程不安全的。为避免多个线程操作统一地址,需要使用加锁等机制,而这样会影响分配速度。

从内存模型而不是垃圾收集的角度,对Eden区域继续进行划分,JVM为每个线程分配了一个私有缓存区域(Thread Local Allocation Buffer,TLAB),它包含在Eden空间中。多线程同时分配内存时,使用TLAB可以避免一系列的非线程安全问题,同时还能够提升内存分配的吞吐量,因此我们可以将这种内存分配方式称之为快速分配策略

尽管不是所有的对象实例都能够在TLAB中成功分配内存,但JVM确实是将TLAB作为内存分配的首选。在程序中,开发人员可以通过指令”-XX:UseTLAB”设置是否开启TLAB空间(默认是开启的)。默认情况下,TLAB空间的内存非常小,仅占整个Eden空间的1%,可以通过指令”-XX:TLABWasteTargetPercent”设置TLAB空间所占Eden空间的百分比大小。一旦对象在TLAB空间分配内存失败时,JVM就会尝试通过使用加锁机制确保数据操作的原子性,从而直接在Eden空间中分配内存。

堆空间参数设置

官方文档https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

  • “-XX:+PrintFlagsInitial”:查看所有的参数默认初始值
  • “-XX:+PrintFlagsFinal”:查看所有的参数最终值(可能会存在修改,不再是初始值)
  • “-Xms”:初始堆空间内存(默认值是物理内存的1/64)
  • “-Xmx”:最大堆内存空间(默认值为物理内存的1/4)
  • “-Xmn”:设置新生代的大小(初始值与最大值)
  • “-XX:NewRatio”:设置老年代与新生代在堆结构的占比
  • “-XX:SurvivorRatio”:设置新生代中Eden和S0/S1空间的比例
  • “-XX:MaxTenuringThreshold”:设置新生代垃圾的最大年龄
  • “-XX:+PrintGCDetails”:输出详细的GC处理日志
  • “-XX:+PrintGC”:打印GC简要信息
  • “-XX:HandlePromotionFailure”:是否设置空间分配担保
    在发生Minor GC之前,虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。如果大于,则此次Minor GC是安全的;如果小于,则虚拟机会查看”-XX:HandlePromotionFailure”设置值是否允许担保失败。如果HandlePromotionFailure = false,会进行一次Full GC;如果HandlePromotionFailure = true,那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小。如果大于,则尝试进行一次Minor GC,但这次Minor GC依然是有风险的;如果小于,则改为进行一次Full GC。
    在JDK6 Update24之后,HandlePromotionFailure参数已经失效,只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC,否则将进行Full GC。

其他

  • 堆是分配对象存储的唯一选择吗
    随着JIT编译期的发展与逃逸分析(Escape Analysis)技术逐渐成熟,栈上分配、标量替换优化技术将会导致一些微妙的变化,所有的对象都分配到堆上也渐渐变得不那么绝对了。
    在JVM中,对象是在Java堆中分配内存的,这是一个普遍的常识。但是,如果经过逃逸分析后发现,一个对象并没有逃逸出方法的话,那么就可能被优化成栈上分配。这样就无需在堆上分配内存,也无需进行垃圾回收了,这也是最常见的堆外存储技术。
  • 逃逸分析
    如何将堆上的对象分配到栈,需要使用逃逸分析手段。这是一种可以有效减少Java程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。通过逃逸分析,Java HotSpot编译器能够分析出一个新对象的引用的使用范围,从而决定是否要将这个对象分配到堆上。
    逃逸分析的基本行为就是分析对象动态作用域。当一个对象在方法中被定义后,如果对象只在方法内部使用,则没有发生逃逸;如果它被外部方法所引用,则认为发生逃逸,例如作为调用参数传递到其他地方。没有发生逃逸的对象,可以分配到栈上,随着方法执行的结束,栈空间就被移除。
    在JDK 6u23之后,HotSpot中默认就已经开启了逃逸分析。如果是早期版本,开发人员可以通过”-XX:+DoEscapeAnalysis”显式地开启逃逸分析,通过”-XX:+PrintEscapeAnalysis”查看逃逸分析的筛选结果。

方法区

方法区(Method Area)与Java堆一样,是各个线程共享的内存区域,它⽤于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。方法区在JVM启动的时候被创建,并且它的实际物理内存空间中和Java堆区一样都可以是不连续的。方法区的大小,跟堆空间一样,可以选择固定大小或者可扩展。方法区的大小决定了系统可以保存多少个类,如果系统定义了太多的类,导致方法区溢出,虚拟机同样会抛出内存溢出错误OOM。关闭JVM就会释放这个区域的内存。
image.png

⽅法区也被称为永久代。很多⼈都会分不清⽅法区和永久代的关系。 《Java 虚拟机规范》只是规定了有⽅法区这么个概念和它的作⽤,并没有规定如何去实现它。那么,在不同的 JVM 上⽅法区的实现肯定是不同的了。 ⽅法区和永久代的关系很像Java 中接⼝和类的关系,类实现了接⼝,⽽永久代就是 HotSpot 虚拟机对虚拟机规范中⽅法区的⼀种实现⽅式。 也就是说,永久代是 HotSpot 的概念,⽅法区是 Java 虚拟机规范中的定义,是⼀种规范,⽽永久代是⼀种实现,⼀个是标准⼀个是实现,其他的虚拟机实现并没有永久代这⼀说法。

JDk8中,完全废弃了永久代的概念,改用元空间(Metaspace)来代替。元空间的本质和永久代类似,都是对JVM规范中方法区的实现。元空间与永久代最大的区别在于:元空间不在虚拟机设置的内存中,而是使用本地内存。永久代、元空间不只是名字改变,内部结构也调整了。
这项改动是很有必要的,因为:

  • 为永久代设置空间大小是很难确定的。在某些场景下,如果动态加载类过多,容易产生Perm区的OOM。比如某个实际Web工程中,因为功能点比较多,在运行过程中,要不断动态加载很多类,经常出现致命错误。而元空间和永久代最大的区别在于,元空间并不在虚拟机中,而是使用本地内存。因此,默认情况下,元空间的大小仅受本地内存限制
  • 对永久代进行调优是很难的

Hotspot中方法区的变化:

jdk1.6及以前 有永久代(permanent generation),静态变量存放在永久代上
jdk1.7 有永久代,但已经逐步“去永久代”,字符串常量池、静态变量移除,保存在堆中
jdk1.8及之后 无永久代,类型信息、字段、方法、常量保存在本地内存的元空间,但字符串常量池、静态变量仍在堆

类型信息

对每个加载的类型(类class、接口interface、枚举enum、注解annotation),JVM必须在方法区中存储以下类型信息:

  • 这个类型的完整有效名称(全名=包名.类名)
  • 这个类型直接父类的完整有效名(对于interface或是java.lang.Object,都没有父类)
  • 这个类型的修饰符(public、abstract、final的某个子集)
  • 这个类型直接接口的一个有序列表

域(Field)信息

  • JVM必须在方法区中保存类型的所有域相关信息以及域的声明顺序
  • 域的相关信息包括:域名称、域类型、域修饰符(public、private、protected、static、final、volatile、transient的某个子集)

方法(Method)信息

JVM必须保存所有方法的以下信息,同域信息一样包括声明顺序:

  • 方法名称
  • 方法的返回类型(或void)
  • 方法参数的数量和类型(按顺序)
  • 方法的修饰符(public、private、protected、static、final、syschronized、native、abstract的一个子集)
  • 方法的字节码(bytecodes)、操作数栈、局部变量表及大小(abstract和native方法除外)
  • 异常表(abstract和native方法除外)
    • 每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引

运行时常量池

  • 运行时常量池(Runtime Constant Pool)是方法区的一部分
  • 常量池表(Constant Pool Table)是Class文件的一部分,用于存放编译期生成的各种字面量与符号引用,这部分内容将在类加载后存放到方法区的运行时常量池中
  • 运行时常量池,在加载类和接口到虚拟机后,就会创建对应的运行时常量池
  • JVM为每个已加载的类型(类或接口)都维护一个常量池。池中的数据项像数组项一样,是通过索引访问的
  • 运行时常量池中包含多种不同的常量,包括编译期就已经明确的数值字面量,也包括到运行期解析后才能够获得的方法或者字段引用。此时不再是常量池中的符号地址了,这里替换为真实地址
    • 运行时常量池,相对于Class文件常量池的另一重要特征是:具备动态性
  • 运行时常量池类似于传统编程语言中的符号表(symbol table),但是它所包含的数据却比符号表要更加丰富一些
  • 当创建类或接口的运行时常量池时,如果构造运行时常量池所需要的内存空间超过了方法区所能提供的最大值,则JVM会抛出OutOfMemoryError异常

设置方法区大小与OOM

本地方法接口

本地方法(Native Method)是一个Java调用非Java代码的接口。这个特征并非Java所特有,很多其它的编程语言都有这一机制。在定义一个native method时,并不提供实现体,因为它的实现体是由非Java语言在外面实现的。本地接口的作用是融合不同的编程语言为Java所用,它的初衷是融合C/C++程序。

Java使用起来固然方便,但是有些层次的任务用Java实现起来不容易,有时Java应用需要与Java外面的环境交互,这是本地方法存在的主要原因。目前该方法使用的越来越少了,除非是与硬件有关的应用,因为现在的异构领域间的通信很发达。