1、运行时数据区

 

 

 

 

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

 

 

灰色部分为单线程私有，红色的为多个线程共享的。即：

 每个线程：独立包括程序计数器、栈、本地栈  (谈优化的时候，在这些线程私有的地方都不需要优化，需要调优的地方主要就是在堆里面)
 线程间共享：堆、对外内存(永久代或元空间、代码缓存)

线程

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

  • 在Hotspot JVM里，每个线程斗鱼操作系统的本地线程直接映射。

    • 当一个Java线程准备好执行以后，此时一个操作系统的本地线程也同时创建。Java线程执行终止后，本地线程也会回收。

  • 操作系统负责所有线程的安排调度到任何一个可用的CPU上。一旦本地线程初始化成功，他就会调用Java线程中的run()方法。

  • 如果使用jconsole或者是任何一个调试工具，都能看到在后台有许多线程在运行。这些后台不包括public static void main(String[] args)的main线程以及所有这个main线程自己创建的线程。

  • 这些主要的后台系统线程在Hotspot JVM里主要是以下几个：

    • 线程虚拟机：这种线程的操作是需要JVM达到安全点才会出现。这些操作必须在不同的线程中发生的原因是他们都需要JVM达到安全点，这样堆才不会变化。这种线程的执行类型包括“stop-the-world”的垃圾收集，线程栈收集，线程挂起以及偏向锁撤销

    • 周期任务线程：这种线程是时间周期事件的体现(比如中断)，他们一般用于周期性操作的调度执行。

    • GC线程：这种线程对在JVM里不同的种类的垃圾收集行为提供了支持。

    • 编译线程：这种线程在运行时会将字节码编译成本地代码。

    • 信号调度线程：这种线程接受信号并放给JVM，在它内部通过调用适当的方法进行处理。

1、程序计数器。

https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.5

 

 

程序计数器(program Counter Register)是一块较小的内存空间，他可以看做是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里(仅仅是概念模型，各种虚拟机可能会通过一些高校的方式去实现),字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。

每条线程都有一个独立的线程计数器，每条线程互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。

如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果是Native方法，这个计数器值则为空。此内存区域是唯一一个在Java虚拟机规范中没有任何OutOfMemoryError情况的区域。

特点：

  • 一块很小的内存空间，几乎可以忽略不计，也是运行速度最快的存储区域

  • 在JVM规范中，每个线程都有它自己的程序计数器，是线程私有的，声明周期与线程的生命周期保持一致

  • 任何时间一个线程都只有一个方法在执行，也就是所谓的当前方法。程序计数器会存储当前线程执行的Java方法的JVM指令地址；或者，如果实在执行native方法，这是未指定值(undefined)。

  • 程序控制流的只是器，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成

  • 字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。

  • 他是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。

举例：

1  public class PCRegister {
2      public static void main(String[] args) {
3          int i = 10;
4          int j = 20;
5          int k = i + j;
6      }
7  }

javap -v PCRegister.class

Classfile /F:/ideaproject/JVM_Study/src/org/ybl/jvm/chapter04/PCRegister.class
   Last modified 2020-12-28; size 309 bytes
   MD5 checksum fab377ac30dad2b01ddd2e11ca4bf7e7
   Compiled from "PCRegister.java"
 public class org.ybl.jvm.chapter04.PCRegister
   minor version: 0
   major version: 52
   flags: ACC_PUBLIC, ACC_SUPER
 Constant pool:
    #1 = Methodref          #3.#12         // java/lang/Object."<init>":()V
    #2 = Class              #13            // org/ybl/jvm/chapter04/PCRegister
    #3 = Class              #14            // java/lang/Object
    #4 = Utf8               <init>
    #5 = Utf8               ()V
    #6 = Utf8               Code
    #7 = Utf8               LineNumberTable
    #8 = Utf8               main
    #9 = Utf8               ([Ljava/lang/String;)V
   #10 = Utf8               SourceFile
   #11 = Utf8               PCRegister.java
   #12 = NameAndType        #4:#5          // "<init>":()V
   #13 = Utf8               org/ybl/jvm/chapter04/PCRegister
   #14 = Utf8               java/lang/Object
 {
   public org.ybl.jvm.chapter04.PCRegister();
     descriptor: ()V
     flags: ACC_PUBLIC
     Code:
       stack=1, locals=1, args_size=1
          0: aload_0
          1: invokespecial #1                  // Method java/lang/Object."<init>":()V
          4: return
       LineNumberTable:
         line 9: 0
 ​
   public static void main(java.lang.String[]);
     descriptor: ([Ljava/lang/String;)V
     flags: ACC_PUBLIC, ACC_STATIC
     Code:
       stack=2, locals=4, args_size=1
          0: bipush        10
          2: istore_1
          3: bipush        20
          5: istore_2
          6: iload_1
          7: iload_2
          8: iadd
          9: istore_3
         10: return
       LineNumberTable:
         line 11: 0
         line 12: 3
         line 13: 6
         line 15: 10
 }
 SourceFile: "PCRegister.java"

 

上面的0：、2：、3等叫做指令地址(偏移地址)，数字后边就是操作指令(这个后面详细讲)。比如0：binpush对应就是指令地址为0，binpush表示当int取值-128~127时，JVM采用bipush指令将常量压入栈中。

执行引擎会读取会到程序计数器中读取值，然后找到该值对应的操作指令，然后将它翻译成机器指令，交给CPU进行执行。

常见面试题

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

2.Java虚拟机栈

出现背景

由于跨平台性的设计，Java的指令都是根据栈来设计的。不同平台CPU架构不同，所以补鞥呢设计为基于寄存器的。

Java虚拟机栈(Java Virtual Machine Stacks)也是线程私有的，生命周期和线程相同。描述的是Java执行的内存模型：每个方法在执行的同时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。一个方法对应一个栈帧。

局部变量表存放了各种基本类型、对象引用和returnAddress类型（指向了一条字节码指令地址）。其中64位长度long 和 double占两个局部变量空间，其他只占一个。

对这个区域规定了两种异常情况：线程请求深度大于虚拟机所允许的深度，会抛出StackOverflowError异常；如果虚拟机可以动态扩展，如果扩展时无法申请到足够内存，就会抛出OutOfMemoryError异常

作用

主管Java程序的运行，它保存方法得到局部变量(8种基本数据类型、对象的引用地址)、部分结果，并参与方法的调用和返回。

特点(优点)

 

 

优点是跨平台，指令集小，编译器容易实现，缺点是性能下降，实现同样的功能需要很多的指令

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

  • JVM直接对Java栈的操作只有两个：

    • 每个方法执行，伴随着进栈(入栈、压栈)

    • 执行结束后的出栈工作

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

栈可能出现的异常

Java虚拟机规范允许Java栈的大小是动态的或者是固定不变的。

  • 如果采用固定大小的Java虚拟机栈，那每一个线程的Java虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过Java虚拟机栈允许的追到容量，Java虚拟机将会抛出一个StackOverflowError

  • 如果Java虚拟机栈可以动态扩展的，并且尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈，那Java虚拟机将会抛出一个OutOfMemoryError

设置栈内存大小

可以使用-Xss参数来设置线程的最大栈空间，栈的大小直接决定了函数调用的最大可达深度

栈的存储结构和运行原理

栈中存储什么？

  • 每个线程都有自己的栈，栈中的数据都是以栈帧(Stack Frame)的格式存在

  • 在这个线程上正在执行的每个方法都各自对应一个栈帧

  • 栈帧是一个内存区块，是一个数据集，维系着方法执行过程中的各种数据信息。

栈运行原理

 

 

  • JVM直接对Java栈的操作只有两个，就是对栈帧的压栈和出栈，遵循“先进后出”/“后进先出”的原则

  • 在一条活动线程中，一个时间点上，只会有一个活动的栈帧。即只有当前正在执行的栈帧(栈顶栈帧)是有效的，这个栈帧被称为当前栈帧(Current Frame),与当前栈帧相对应的方法就是当前方法(Current Method)，定义这个方法的类就是当前类当前类(Current Class)。

  • 执行引擎运行的所有字节码指令只针对当前栈帧进行操作。

  • 如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，放在栈的顶端，成为新的当前帧。

  • 不同线程中所包含的栈帧是不运行存在相互引用的，即不可能在一个栈帧之中引用另外衣蛾线程的栈帧。

  • 如果当前方法调用了其他方法，方法返回之际，当前栈帧会传回此方法的执行结果给前一个栈帧，接着，虚拟机会丢弃当前栈帧，使得前一个栈帧重新成为当前栈帧。

  • Java方法有两种返回函数的方式，一种是正常的函数返回，使用return指令；另一种是抛出异常。不管用那种方式，都会导致栈帧被弹出。

栈帧的内部结构

 

每个栈帧中存储着：

  • 局部变量表(Local Variables)

  • 操作数栈(Operand Stack)（或表达式栈）

  • 动态链接(Dynamic Linking)（或指向运行时常量池的方法引用）

  • 方法返回地址(Return Address) （或方法正常退出或者异常退出的定义）

  • 一些附加信息

局部变量表

  • 局部变量表也称为局部变量数组或本地变量表

  • 定义为一个数字数组，主要用于存储方法参数和定义在方法体内的局部变量，这些数据类型包括各类基本数据类型、对象引用(reference)，以及returnAddress类型

  • 由于局部变量表示建立在线程的栈上，是线程的是有数据，因此不存在数据安全问题。

  • 局部变量表所需的容量大小是在编译器确定下来的，并保存在方法的Code属性的maximum local variables数据项中。在方法运行期间是不会改变局部变量表的大小的。

  • 方法嵌套调用的次数由栈的大小决定。一般来说，栈越大，方法嵌套调用次数越多。对一个函数而言，它的参数和局部变量越多，使得局部变量表膨胀，它的栈帧就越大，以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间，导致其嵌套调用次数就会减少

  • 局部变量表中的变量只在当前方法调用中有效。在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁。

关于Slot的理解

  • 参数值的存放宗师在局部变量数组的index0开始，到数组长度-1的索引结束

  • 局部变量表，最基本的存储单元是Slot(变量槽)

  • 局部变量表中存放编译期可知的各种基本数据类型，引用类型，returnAddress类型的变量。

  • 局部变量表里，32位以内的类型只占用一个slot(包括returnAddress类型)，64位的类型(long和doubloe)占用两个slot

    • byte、short、char在存储前辈转换为int，boolean也被转换为int，0表示false，非0表示true

    • long和double则占据两个Slot。

  • JVM会为局部变量表中的每一个Slot都分配一个访问索引，通过这个索引即可成功访问到局部变量表中指定的局部变量值

  • 当一个实例方法被调用的时候，它的方法参数和方法体内部定义的局部变量将会按照顺序被赋值到局部变量表中的每一个Slot上

  • 如果需要访问局部变量表中一个64bit的局部变量值时，只需要使用前一个索引即可。(比如：访问long或double类型变量)

  • 如果当前帧是由构造方法或者实例方法创建的，那么该对象引用this将会存放在index为0的slot处，其余的参数按照参数表顺序继续排列

 

Slot的重复利用

栈帧中的局部变量表中的槽位是可以重复利用的，如果以局部变量过了其作用域，那么在其作用域之后申明的新的局部变量就很有可能会复用过期局部变量的槽位，从而达到节省资源的目的。

操作数栈

  • 每一个独立的栈帧中除了包含局部变量表以外，还包含一个先进后出的操作数栈，也可以称之为表达式栈

  • 操作数栈，在方法执行过程中，根据字节码指令，往栈中写入数据或读取数据，即入栈(push)/出栈(pop)

    某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈，使用他们后再把结果压入栈。

    比如：执行赋值、交换、求和等操作

 

 

  • 如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，并更新PC寄存器中下一条需要执行的字节码指令。

  • 操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，这由编译器在编译期间进行验证，同时在类加载过程中的类校验阶段的数据流分析阶段要再次验证

  • 另外，Java虚拟机的解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈。

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

  • 操作数栈就是JVM执行引擎的一个工作区，当一个方法刚开始执行的时候，一个新的栈帧也会随之被创建出来，这个方法的操作数栈是空的。

  • 每一个操作数栈都会拥有一个明确的栈深度用于存储数值，其所需的最大深度在编译器就定义好了，保存在方法的Code属性中，为max_stack的值

  • 栈中的任何一个元素都是可以任意的Java数据类型

    • 32bit的类型占用一个栈单位深度

    • 64bit的类型占用两个栈单位深度

  • 操作数栈并非采用访问索引的方式来进行数据访问的，而是只能通过标准的入栈和出栈操作来完成一次数据访问。

栈顶缓存技术

前面提过，基于栈式架构的虚拟机所使用的零地址指令更加紧凑，单完成一项操作的时候必然需要使用更多的入栈和出栈指令，这同时也就意味着将需要更多的指令分派(instruction dispatch)次数和内存读/写次数

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

动态链接

  • 每一个栈帧内部都包含一个指向运行时常量池中该栈帧所属方法的引用。包含这个引用的目的就是为了支持当前方法的代码能购实现动态链接。比如：invokedynamic指令

  • 在Java源文件被编译到字节码文件中时，所有的变量和方法引用都作为符号引用(Symbolic Reference)保存在class文件的常量池里。比如：描述一个方法调用了另外的其他方法时，就是通过常量池中指向方法的符号引用来表示的，那么动态链接的作用就是为了将这些符号引用转换为调用方法的直接引用。

对应的绑定机制为：早期绑定(Early Binding)和晚期绑定(Late Binding)。绑定是一个字段、方法或者类在符号引用被替换为直接引用的过程，这仅仅发生一次

  • 早期绑定： 早期绑定就是值被调用的目标方法如果在编译器可知，且运行期间保持不变时，即可将这个方法与所属的类型进行绑定，这样一来，由于明确了被调用的目标发方法究竟是哪一个，因此也就可以使用静态链接的方式将符号引用转换为直接引用。

  • 晚期绑定： 如果被调用的方法在编译期无法被确定下来，只能够在程序运行期根据实际的类型绑定相关的方法，这种方式被称之为晚期绑定。

方法调用

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

  • 静态链接：

    当一个字节码文件被装载进JVM内部时，如果被调用的目标方法在编译期可知，企鹅运行期保持不变时。这种情况下将调用方法的符号引用转换为直接引用的过程称之为静态链接

  • 动态链接： 如果被调用的方法在编译器无法被确定下来，也就是说，只能够在程序运行期间调用方法的符号引用转换为直接引用，由于这种引用转换过程具备动态性，因此也就被称之为动态链接。

虚方法与非虚方法

非虚方法：

  • 如果方法在编译器就确定了具体的调用版本，这个版本在运行时是不可变的。这样的方法称为非虚方法

  • 静态方法、私有方法、final方法、实例构造器、父类方法都是非虚方法

  • 其他方法称为虚方法

虚拟机中提供了一下几条方法调用指令：

  • 普通调用指令：

    • invokestatic：调用静态方法，解析阶段确定唯一方法版本

    • invokespecial：调用<init>方法、私有及父类方法，解析阶段确定唯一方法版本

    • invokevirtual：调用所有虚方法

    • invokeinteferace：调用接口方法

  • 动态调用指令：

    • invokedynamic：动态解析出需要调用的方法，然后执行

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

invokedynamic指令

  • JVM字节码指令集一直比较稳定，一直到Java7中增加了一个invokedynamic指令，这是Java为了实现【动态类型语言】支持而做的一种改进

  • 在Java7中并没有提供直接生成invokedynamic指令的方法，需要借助ASM这种底层字节码工具来产生invokedynamic指令。知道Java8的Lambda表达式的出现，invokedynamic指令的生成，在Java中才有了直接的生成方式

  • Java7中增加的动态语言类型支持的本质是对Java虚拟机规范的修改，而不是对Java语言规则的修改，这一块相对来讲比较复杂，增加了虚拟机中的方法调用，最直接的受益者就是运行在Java平台的动态语言的编译器。

方法返回地址

  • 存放调用该方法的PC寄存器的值

  • 一个方法结束，有两种方式

    • 正常执行完成

    • 出现未处理的异常，非正常退出

  • 无论通过哪种方式退出，在方法退出后都返回到该方法被调用的位置。方法正常退出时，调用者的PC计数器的值作为返回地址，即调用该方法的指令的下一条指令的地址。而通过异常退出的，返回地址是通过异常表来确定的，栈帧中一般不会保存这部分信息。

正常退出和异常退出区别在于：通过异常完成退出的不会给他的上层调用者产生任何返回值。

当一个方法开始执行后，只有两种方式可以退出这个方法：

  • 执行引擎遇到任意一个返回方法的字节码指令(return)，会有返回值传递给上层的方法调用者，简称正常完成出口

    • 一个方法在正常调用完成之后究竟需要使用哪一个返回指令还需要根据返回值的实际数据类型而定

    • 在字节码指令中，返回指令包括ireturn(当返回值是boolean、byte、char、short和int 类型时使用)、lreturn、freturn、dreturn以及areturn，另外还有一个return指令供声明为void的方法、实例初始化方法、类和接口的初始化方法使用。

虚拟机栈相关面试题

  • 举例栈溢出的情况？(StackOverflowError)

    递归调用

    通过-Xss设置栈的大小；如果是固定的会出现StackOverflowError，如果是动态调整会出现OOM

  • 调整栈大小，就能保证不出现溢出吗？

  • 不能，理论上只能让StackOverflowError出现的时间更晚些

  • 分配栈内存越大越好吗？

  • 不是，理论上，内存越大在单位时间内越可以避免发生Error。但是不是越大越好，因为内存空间是优先的，栈越大，线程数就会越少，甚至会挤占其他的内存空间

  • 垃圾回收是否涉及到虚拟机栈

  • 不会，虚拟机栈只会出现Error

  • 方法中定义的局部变量是否线程安全

    • 具体问题具体分析

       何为线程安全？
           如果只有一个线程才可以操作此数据，则必是线程安全的。
           如果有多个线程操作数据，这此数据是共享数据。如果不考虑同步机制的话，会存在线程安全问题。
       //s1的声明方式是线程安全的。
       public static void method1(){
           Stringbuilder s1 = new StringBuilder();
           s1.append("a");
           s1.append("b");
       }
       但是在method1中操作了共享数据，那么这个共享数据就是不安全的。

       

3.本地方法栈

和Java虚拟机栈很类似，不同的是本地方法栈为Native方法服务。

为什么要使用本地方法

Java使用起来非常方便，然而有些层次的任务用Java实现起来不容易，或者我们对程序的效率很在意时，问题就来了

  • 与Java环境外交互：

    有时Java应用需要与Java外面的环境交互，这是本地方法存在的主要原因。

    Java需要与一些底层系统，如操作系统或某些硬件交换信息时的情况。本地方法正是这样一种交流机制：它为我们提供了一个非常简洁的接口，而且我们无需去了解Java应用之外的繁琐的细节。

  • 与操作系统交互

    JVM支持着Java语言本身和运行时库，它是Java程序赖以生存的平台，它有一个解释器(解释字节码)和一些链接到本地代码的库组成。然而不管怎样，它毕竟不是一个完整的系统，它经常依赖于一些底层系统的支持。这些底层系统常常是强大的操作系统。通过使用本地方法，我们得以用Java实现了jre的与底层系统的交互，甚至JVM的一些部分就是用c写的。还有，如果我们要使用一些Java语言本身没有提供封装的操作系统的特性时，我们也需要使用本地方法

  • Sun`S Java

    sun的解释器是用C实现的，这使得它能像一些普通的C一样与外部交互。jre大部分是用Java实现的，它也通过一些本地方法与外界交互。例如：java.lang.Thread的setPriority()方法是用Java实现的，但是它实现调用的是该类里的本地方法setPriority0()。这个本地方法是用C实现的，并被植入JVM内部，在Windows 95的平台上，这个本地方法最终将调用Win32 setPriority()API。这是一个本地方法的具体实现由JVM直接提供，更多的请款是本地方法由外部的动态链接库(external dynamic link library)提供，然后被JVM调用。

本地方法栈：

  • Java虚拟机栈用于管理Java方法的调用，而本地方法栈用于管理本地方法的调用

  • 本地方法栈，也是线程私有的

  • 允许被实现成固定或者是可动态扩展的内存大小(在内存溢出方面是相同的)

    • 如果线程请求分配的栈容量超过本地方法栈允许的最大容量，Java虚拟机将会抛出一个StackOverflowError异常。

    • 如果本地方法栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建爱你对应的本地方法栈，那么Java虚拟机就会抛出一个OutOfMemoryError异常。

  • 本地方法是使用C语言实现的。

  • 它的具体做法是Native Method Stack中登记了native方法，在Execution Engine执行时加载本地方法栈

4.Java堆

对于大多数应用而言，Java堆(Java Heap)是Java虚拟机所管理的内存中最大的一块。他是所有线程的共享区域，在虚拟机启动时创建。主要存放对象实例。几乎所有的对象实例都在这里分配内存。

它是垃圾收集器管理的区域，也被称为“GC堆”。他可以细分为：兴盛代合老年代；在细致一点的有Eden空间、From Survivor空间，To Survivor空间等。

如果堆中没有内存完成实例分配，并且堆也无法在扩展时，将会抛出OutOfMemoryError异常。

  • 一个JVM实例只存在一个堆内存，堆也是Java内存管理的核心区域。

  • Java堆区在JVM启动的时候就被创建，其空间大小也就确定了。是JVM管理的最大一块内存空间 堆内存的大小是可以调节的：-Xms10m：初始堆空间、-Xmx10m：最大堆空间

  • 《Java虚拟机规范》规定，堆可以处于物理上不连续的内存空间，但在逻辑上它应该被视为连续的。

  • 所有的线程共享Java堆，在这里还可以划分线程私有的缓冲区(Thread Local Allocation Buffer,TLAB)

  • 《Java虚拟机规范》中对Java堆的描述是：所有的对象实例以及数组都应当在运行时分配在堆上。

    • 我要锁的是：“几乎”所有的对象实例都在在这理分配内存——从实例使用角度看。

  • 数组和对象可能永远不会存储在栈上，因为栈帧中保持引用，这个引用指向对象或者数组在堆中的位置

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

  • 堆是GC(Garbage Collection，垃圾收集器)执行垃圾回收的重点区域。

堆内存细分

 Java7及之前堆内存逻辑上分为三部分：新生代+养老区+永久区
     Young Generation Space  新生区      Young/New
         又被划分为Eden区和Survivor区
     Tenure generation space 养老区      Old/Tenure
     Permanent Space         永久区      Perm
     
 Java 8及之后堆内存逻辑上分为三部分：新生区+养老区+元空间
     Young Generation Space  新生区      Young/New
         又被划分为Eden区和Survivor区
     Tenure generation space 养老区      Old/Tenure
     Meta Space              元空间      Meta
 ​
 约定：新生区<——>新生代<——>年轻代        养老区<——>老年区<——>老年代  永久区<——>永久代

堆内存大小设置及OOM

  • Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，可以通过选项“-Xmx”和“-Xms”来进行设置

    • “-Xms”用于表示堆区的起始内存，等价于`-XX:InitialHeapSize

    • “-Xmx”用于表示堆区的最大内存，等价于`-XX:MaxHeapSize

  • 一旦堆中的内存大小超过“-Xmx”所指定的最大内存时，就会抛出OutOfMemoryError异常。

  • 通常会将-Xms和-Xmx两个参数配置相同的值，其目的是为了能够在Java垃圾回收机制清理完堆区后不需要重新分割计算堆区的大小，从而提高性能

  • 默认情况下，初始内存大小：物理内存大小1/64；最大内存大小：物理电脑内存大小/4

    查看设置的参数：方式一：jps ， jstat -gc 进程id

    方式二：-XX:+PrintGCDetails

年轻代与老年代

  • 存储在JVM中的Java对象可以被划分为两类：

    • 一类是生命周期较短的瞬时对象，这类对象的创建和消亡都非常迅速

    • 另外一类对象的生命周期却非常长，在某些极端的情况下还能够与JVM的生命周期保持一致

  • Java堆区进一步细分的话，可以分为年轻代(YoungGen)和老年代(OldGen)

  • 其中年轻代又可以分为Eden空间、Survivor0空间和Survivor1空间(有时也叫做form区、to区)

      

下面这参数开发中一般不会调：

 

 

  • 配置新生代与老年代在堆结构的占比

    • 默认-XX:NewRatio=2，表示新生代占1，老年代占2，新生代占整个对的1/3.

    • 可以修改-XX:NewRatio=4，表示新生代占1，老年代占4，新生代占整个堆的1/5

  • 在HotSpot中，Eden空间和另外两个Survivor空间缺省所占的比例是8:1:1

  • 当然也可以通过选项“-XX:SurvivorRatio”调整这个空间比例。例如：-XX：SurvivorRatio=8

    从visualVM来看，有时比例不是8：1：1，这就涉及到了自适应的机制，可以利用-XX:-UseAdaptiveSizePolicy来关闭这个自适应机制

  • 几乎所有的Java对象都是在Eden区被new出来的

  • 绝大部分的Java对象的销毁都在新生代进行了

    • IBM公司的专门研究中，新生代中80%的对象都是“朝生夕死”的

  • 可以使用选项“-Xms”设置新生代最大内存大小

    • 这个参数一般使用默认值就行

对象分配过程：概述

为新对象分配内存是一件非常严谨和复杂的任务，JVM的设计者们不仅需要考虑内存如何分配、在那里分配的问题，并且由于内存分配算法与内存回收算法密切相关，所以还需要考虑GC执行完内存回收后是否会在内存空间中产生内存碎片。

1、new的对象先放在Eden去。此区有大小限制。

2、当Eden的空间填满后，程序有需要创建对象，JVM的垃圾回收器将堆Eden区进行垃圾回收(Minor GC),将Eden区中的不在被其他对象所引用的对象进行销毁。再加载新的对象放到Eden区。

3、然后将Eden中的剩余对象移动到幸存者0区。

 

 

4、如果再次出发垃圾回收，此时上次幸存下来的放到幸存0区的，如果没有回收，将会放到幸存者1区。

 

5、如果再次经历回收，此时会重新放回幸存者0区，接着再去幸存者1区。

6、啥时候能去养老区呢？可以设置参数。默认为15次。

 

  • 可以设置参数：-XX:MaxTenuringThreshold=<N>进行设置。

s0和s1不会触发垃圾回收，只有Eden区满的时候，会触发MinorGC/YGC，MinorGC会将Eden去Survivor区的垃圾一起回收。

7、在养老区，相对悠闲。当养老区内存不足时，再次出发GC：Major GC，进行养老区的内存清理

8、若养老区执行了Major GC之后发现依然无法进行对象的保存，就会产生OOM异常

java.lang.OutOfMemoryError:Java heap space

总结

  • 针对幸存者s0,s1区的总结：复制之后有交换，谁空谁是to

  • 关于垃圾回收：频繁在新生区收集，很少在养老区收集，几乎不再永久区/元空间收集。

对象分配的特殊情况

Minor GC、Major GC与Full GC

JVM在进行GC时，并非每次都对上面三个内存区域(新生代、老年代；方法区)一起回收，大部分时候回收的都是在新生代

针对HotSpot VM的实现，它里面的GC按照回收区域又分为两种大类型：一种是部分收集(Partial GC)，一种是堆整理收集(Full GC)

  • 部分收集:不是完整收集整个Java堆的垃圾收集，其中又分为：

    • 新生代收集(Minor GC/Young GC)：只是新生代的垃圾收集

    • 老年代收集(Major GC/Old GC):只是老年代的垃圾收集

      • 目前，只有CMS GC会有单独收集老年代的行为

      • 注意，很多时候Major GC会和Full GC混合使用，需要具体分辨是老年代回收还是整堆回收。

    • 混合收集(Mixed GC):收集整个新生代以及部分老年代的垃圾收集。

      • 目前，只有G1 GC会有这种行为

  • 整堆回收(Full GC)：收集整个Java堆和方法区的垃圾收集。

分代式GC策略的触发条件

  • 年轻代GC(Minor GC)触发机制：

    • 当年轻空间不足时，就会触发Minor GC，这里的年轻代满指的是Eden区满，Survivor满不会触发GC。(每次Minor GC会清理年轻代的内存)

    • 因为Java对象大多都具备朝生夕死的特性，所以Minor GC非常频繁，一般回收速度也比较快。

    • Minor GC会引发STW(Stop The World),暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行。

  • 老年代GC(Major GC/Full GC)触发机制：

    • 指发生在老年代的GC，对象从老年代消失时，我们说“Major GC”或“Full GC”发生了

    • 出现了Major GC，经常会伴随着至少一次的Minor GC(并非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程)

      • 也就是在老年代空间不足时，会先尝试触发Minor GC。如果之后空间还不足，则触发Major GC

    • Major GC的速度一般会比Minor GC慢10倍以上，STW的时间更长

    • 如果Major GC后，内存不足，就报OOM了。

  • Full GC触发机制(后面细讲)：

    触发Full GC执行的情况有如下五种：

    • 调用System.GC()时，系统建议执行Full GC，但是不一定会执行

    • 老年代空间不足

    • 方法区空间不足

    • 通过Minor GC后进入老年代的平均大小大于老年代的可用内存

    • 由Eden区、survivor、 space0(From Space)区想survivor space1(To Space)区复制时，对象大小大于To Space可用内存时，则把该对象存到老年代，且老年代的可用内存小于该对象大小

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

GC 举例与日志分析
 1 public class GCTest {
 2      public static void main(String[] args) {
 3          int i = 0;
 4          try {
 5              List<String> list = new ArrayList<>();
 6              String a = "好好学习，天天向上";
 7              while (true) {
 8                  list.add( a );
 9                  a = a + a;
10                  i++;
11              }
12          } catch (Throwable t) {
13              System.out.println( "遍历次数：" + i );
14              t.printStackTrace();
15          }
16      }
17  } 

添加参数

 -Xms6m -Xmx6m -XX:+PrintGCDetails

结果：

 
 1 [GC (Allocation Failure) [PSYoungGen: 1024K->488K(1536K)] 1024K->576K(5632K), 0.0019585 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
 2  [GC (Allocation Failure) [PSYoungGen: 1466K->508K(1536K)] 1554K->856K(5632K), 0.0054675 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
 3  [GC (Allocation Failure) [PSYoungGen: 1330K->504K(1536K)] 1679K->1346K(5632K), 0.0008167 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
 4  [Full GC (Ergonomics) [PSYoungGen: 1139K->0K(1536K)] [ParOldGen: 3722K->2918K(4096K)] 4861K->2918K(5632K), [Metaspace: 3197K->3197K(1056768K)], 0.0073346 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
 5  [Full GC (Ergonomics) [PSYoungGen: 45K->0K(1536K)] [ParOldGen: 4070K->2919K(4096K)] 4116K->2919K(5632K), [Metaspace: 3200K->3200K(1056768K)], 0.0029104 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
 6  [Full GC (Ergonomics) [PSYoungGen: 25K->0K(1536K)] [ParOldGen: 4071K->4067K(4096K)] 4097K->4067K(5632K), [Metaspace: 3205K->3205K(1056768K)], 0.0055424 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
 7  [GC (Allocation Failure) [PSYoungGen: 0K->0K(1536K)] 4067K->4067K(5632K), 0.0004202 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 
 8  [Full GC (Allocation Failure) [PSYoungGen: 0K->0K(1536K)] [ParOldGen: 4067K->4049K(4096K)] 4067K->4049K(5632K), [Metaspace: 3205K->3205K(1056768K)], 0.0068321 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
 9  遍历次数：16
10  Heap
11   PSYoungGen      total 1536K, used 91K [0x00000000ffe00000, 0x0000000100000000, 0x0000000100000000)
12    eden space 1024K, 8% used [0x00000000ffe00000,0x00000000ffe16d78,0x00000000fff00000)
13    from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
14    to   space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
15   ParOldGen       total 4096K, used 4049K [0x00000000ffa00000, 0x00000000ffe00000, 0x00000000ffe00000)
16    object space 4096K, 98% used [0x00000000ffa00000,0x00000000ffdf46d8,0x00000000ffe00000)
17   Metaspace       used 3263K, capacity 4496K, committed 4864K, reserved 1056768K
18    class space    used 353K, capacity 388K, committed 512K, reserved 1048576K
19  java.lang.OutOfMemoryError: Java heap space
20      at java.util.Arrays.copyOf(Arrays.java:3332)
21      at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
22      at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
23      at java.lang.StringBuilder.append(StringBuilder.java:136)
24      at org.ybl.jvm.java1.GCTest.main(GCTest.java:20)

 

堆空间为每个线程分配的TLAB(Thread Local Allocation Buffer)

  • 堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据

  • 由于对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的。

  • 为避免多个线程操作同一个地址，需要使用加锁等机制，进而影响分配速度。

什么是TLAB？

  • 从内存模型而不是垃圾收集的角度，对Eden区域继续进行划分，JVM为每个线程分配了一个私有缓存区域，它包含在Eden空间内

  • 多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还能够提升内存分配的吞吐量，因此可以将这种内存分配方式称为快速分配策略

  • 据我们所知所有OpenJDK衍生出来的JVM都提供了TLAB的设计

TLAB说明：

  • 尽管不是所有的对象实例都能够在TLAB中成功分配内存，单JVM确实是将TLAB作为内存分配的首选。

  • 在程序中，可以通过选项“-XX:UseTLAB”设置是否开启TLAB空间

  • 默认情况下，TLAB空间非常小，仅占有整个Eden空间的1%，当然我们可以通过“-xx:TLABWasteTargetPercent”设置TLAB空间锁占用Eden空间的百分比大小

  • 一旦对象在TLAB空间分配内存失败时，JVM就会尝试通过使用加锁机制确保数据操作的原子性，宠儿直接在Eden空间中分配内存。

对象分配过程：TLAB

堆空间参数设置总结

 -XX:+PrintFlagsInitial:查看所有的参数的默认初始值
 -XX:+PrintFlagsFinal:查看所有参数的最终值(可能会存在修改，不再是初始值)
         具体查看某个参数的指令：jps：查看当前运行中的进程
                              jinfo -flag SurvivoRatio 进程ID
 -Xms：初始堆空间内存(默认为物理内存的1/64)
 -Xmx：最大堆空间的内存(默认为物理内存的1/4)
 -Xmn：设置新生代的大小。(初始值及最大值)
 -XX:NewRatio: 配置新生代与老年代在堆结构中的占比
 -XX:SurvivorRatio: 设置新生代中Eden和S0/S1空间的比例
 -XX:maxTenuringThreshold: 设置新生代垃圾的最大年龄
 -XX:+PrintGCDetails: 输出详细的GC处理日志
     打印GC的简要信息：1、-XX：PrintGC           2、-verbose:gc
 -XX:HandlePromotionFailure: 是否设置空间分配担保

在Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。

  • 如果大于，则此次Minor GC是安全的

  • 如果小于，则虚拟机会查看-XX:HandlePromotionFailure设置值是否允许担保失败

    • 如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小

      • 如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的。

      • 如果小于，则改为进行一次Full GC

    • 如果HandlePromotionFailure=false，则改为进行一次Full GC。

在JDK6 Update24之后，HandlePromotionFailure参数不会再影响到虚拟机的空间分配策略，观察OpenJDK中的源码变化，虽然源码中定义了HandlePromotionFailure参数，但是在代码中已经不会再使用它。JDK Update24之后的规则变为只要老年代的连续空间大于新生代对象总大小或者老年代最大可用连续空间大于历次晋升的平均大小会进行Minor GC，否则进行Full GC。

堆是分配对象存储的唯一选择吗？

不是。

随着JIT编译期的发展与逃逸分析技术逐渐成熟,栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配在堆上也渐渐变得不那么“绝对”了。

Java虚拟机中，对象是在Java堆中分配内存的，这是一个常识。但是一些特殊情况，那就是如果经过逃逸分析(Escape Analysis)后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无需进行垃圾回收了。这是常见的堆外存储技术。

此外，基于OpenJDK深度定制的TaoBaoVM，其中创新的GCIH(GC invisible heap)技术实现off-heap，将生命周期较长的Java对象从heap中移至heap外，并且GC不能管理GCIH内部的Java对象，以此达到降低GC回收频率和提升GC回收效率的目的。

  • 如何将堆上的对象分配到栈，需要使用逃逸分析手段

  • 这是一种可以有效减少Java程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法

  • 通过逃逸分析，Java Hotspot编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。

  • 逃逸分析的基本行为就是分析对象动态作用域：

    • 当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸

    • 当一个对象在方法中被定义后，它被外部方法所引用，则认为发生了逃逸。例如作为调用参数传递到其他地方中。

结论：开发中能使用局部变量的，就不要在方法外定义

代码优化
栈上分配

将堆分配转化为栈分配。如果一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配

  • JIT编译器在编译期间根据逃逸分析的结果，发现如果一个对象并没有逃逸出方法的话，就可能被优化成栈上分配。分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收。这样就无须进行垃圾回收了

  • 常见的栈上分配场景

    • 在逃逸分析中，已经说明。分别是给成员变量赋值、方法返回值、实例引用传递。

同步省略

如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步

  • 线程同步的代价是相当高的，同步的后果是降低并发性和性能

  • 在动态编译同步块的时候，JIT编译器可以借助逃逸分析来判断同步块锁使用的锁对象是否只能被一个线程访问而没有被发布到其他线程。如果没有，那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样就能大大提高并发性和性能。这个取消同步的过程就叫同步省略，也叫锁消除

 
1 public void f(){
2      Object hollis = new Object();
3      synchronized(hollis){
4          System.out.println(hollis);
5      }
6  }

上述代码中对hollis这个对象加锁，但是hollis对象的生命周期只在f()方法中，并不会被其他线程所访问到，所以在JIT编译阶段就会被优化掉。优化成：

1 public void f(){
2      Object hollis = new Object();
3      System.out.println(hollis);
4  } 
分离对象或标量替换

有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分(或全部)可以不存储在内存，而是存储在CPU寄存器上。

标量(Scalar)：是指一个无法再分解成更小的数据的数据。Java中的原始数据类型就是标量。相对的，那些还可以分解的数据叫做聚合量(Aggregate),Java中的对象就是聚合量，因为它可以分解成其他聚合量和标量。

在JIT阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过JIT优化，就会把这个对象拆解成若干个其中包含的若干成员来代替。这个过程就是标量替换。

public static void main(String[] args){
     alloc();
 }
 private static void alloc(){
     Point point = new Point(1,2);
     System.out.println("point.x="+point.x+",point.y="+point.y);
 }
 class Point(){
     private int x;
     private int y;
 }

经过标量替换后，变成：

private static void alloc(){
     int x = 1;
     int y = 2;
     System.out.println("point.x="+point.x+",point.y="+point.y);
 }

可以看出，Point这个聚合量经过逃逸分析后，发现他并没有逃逸，就被替换成两个聚合量。那么标量替换有什么好处呢？就是可以大大减少堆内存的占用。因为一旦不需要创建对象了，那么就不再需要分配堆内存了。

标量替换为栈上分配提供了很好的基础。

标量替换参数设置

参数：-XX:+EliminateAllocations开启标量替换(默认打开)，允许将对象打散分配在栈上。

逃逸分析小结

逃逸分析并不成熟。虽然论文已经在1999年发表了，但直到JDK 1.6才有实现，而且这项技术到如今也并不是十分成熟。其根本原因就是无法保证逃逸分析的性能一定能高于它的消耗。虽然经过逃逸分析可以做标量替换、栈上分配和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程

一个极端的例子，就是进过逃逸分析之后，发现没有一个对象是不逃逸的。那么这个逃逸分析的过程就白白浪费掉了。虽然这项技术并不十分成熟，但是它也是即使编译器优化中一个十分重要的手段。

注意到有一些观点，认为通过逃逸分析，JVM会在栈上分配那些不会逃逸的对象，这在理论上是可行的，但是取决于JVM设计者的选择。Oracle HotspotJVM中并未这么做，这一点在逃逸分析相关的文档里已经说明，所以可以明确所有的对象实例都是在堆上。

目前很多书籍还是基于JDK 7以前的版本，JDK已经发生了河大的变化，intern字符串的缓存和静态变量曾经都被分配在永久代上，而永久代已经被元数据区取代。但是intern字符串缓存和静态变量并不是被转移到元数据区，而是直接在堆上分配，所以这一点同样符合前面一点的结论：对象实例都是分配在堆上。

5.方法区

与Java堆一样，是各个线程共享的内存区域，用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常

《Java虚拟机规范》中明确说明：“尽管所有的方法区在逻辑上是属于堆的一部分，单一些简单的实现可能不会选择去进行垃圾收集或者进行压缩。”单对于HotSpotJVM而言，方法区还有一个别名叫做Non-Heap(非堆)，目的就是要和堆分开

所以，方法区看作是一块独立于Java堆的内存空间。

  • 方法区与Java堆一样，是各个线程共享的内存区域

  • 方法区在JVM启动的时候被创建，并且它的实际的物理内存空间中和Java堆区一样都可以不是连续的

  • 方法区的大小，跟堆空间一样，可以选择固定大小或者可扩展。

  • 方法区的大小决定了洗头工可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，虚拟机同样会抛出内存溢出错误：java.lang.OutOfMemoryError: PermGen space或者Java.lang.outOFMemoryError:Metaspace

    • 加载大量的第三方的jar包；

    • Tomcat部署的工程过多(30-50)；

    • 大量动态的生成反射类。

  • 关闭JVM就会释放这个区域的内存。

栈、堆、方法区的交互关系

Hotspot方法区的演进过程

在jdk 7以前，习惯把方法区称为永久代。jdk8开始，使用元空间取代了永久代。

 In JDK 8,classes metadata is now stored in the native heop and this space is called Metaspace;

本质上，方法区和永久代并不等价。仅是对hotspot而言的，《Java虚拟机规范》对如何实现方法区，不做同意要求。例如：BEA JRockit/IBM J9中不存在永久代的概念。

 

现在来看，当年使用永久代，不是好的主意。导致Java程序更容易OOM(超过-XX:MaxPermSize上限)

而到了JDK 8，终于完全废弃了永久代的概念，改用与JRockit、J9一样在本地内存中实现的元空间(Metaspace)来代替

元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代最大的区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存

根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将抛出OOM异常。

设置方法区大小与OOM

方法区的大小不必是固定的，JVM可以根据应用的需要动态调整

JDK 7及以前：

  • 通过-XX:PermSize来设置永久代初始分配空间。默认值是20.75M

  • -XX:MaxPermSize来设定永久代最大可分配空间，32为机器默认是64M，64为机器默认是82M

  • 当JVM加载的类信息容量超过了这个值，会抛出异常OutOfMemoryError: PermGen space

JDK 8及以后：

  • 元数据区大小可以使用参数-XX:MetaspaceSize和-XX:MaxMetaspaceSize指定，替代上述原有的两个参数

  • 默认值依赖于平台。windows下，-XX:MetaspaceSize是512M，-XX:MaxMetaspaceSize的值是-1，即没有限制

  • 与永久代不同，如果不指定大小，默认情况下，虚拟机会耗尽所有的可用系统内存。如果元数据区发生溢出，虚拟机一样会抛出异常OutOfMemoryError：Metaspace

  • -XX:MetaspaceSize:设置初始的元空间大小。对于一个64为的服务器端JVM来说，其默认的-XX:MetaspaceSize值为512M。这就是初始的高水位线，一旦触及这个水位线，Full GC将会被处罚并卸载没用的类(即这些类对应的类加载器不再存活)，然后这个高水位线将会被重置。新的高水位线的值取决于GC后释放了多少元空间。如果释放的空间不足，那么在不超过MaxMetaspaceSize时，适当提高该值。如果释放空间过多，则适当降低该值

  • 如果初始化的高水位线设置过低，上述高水位线调整情况发生很多次。通过垃圾回收器的日志可以观察到Full GC多次调用。为了避免频繁地GC，建议将-XX:MaxMetaspaceSize设置为一个较高的值。

OOM举例
 1 public class OOMTest extends ClassLoader {
 2      public static void main(String[] args) {
 3          int j = 0;
 4          try {
 5              OOMTest test = new OOMTest();
 6              for (int i = 0; i < 10000; i++) {
 7                  //创建ClassWriter对象，用于生成类的二进制字节码
 8                  ClassWriter classWriter = new ClassWriter( 0 );
 9                  //指明版本号，修饰符，类名，包名，父类，接口
10                  classWriter.visit( Opcodes.V1_8, Opcodes.ACC_PUBLIC, "Class" + i, null, "java/lang/Object", null );
11                  //返回byte[]
12                  byte[] code = classWriter.toByteArray();
13                  test.defineClass( "Class" + i, code, 0, code.length );
14                  j++;
15              }
16          } finally {
17              System.out.println( j );
18          }
19      }
20  }

 

jdk8：

设置参数：

 -XX:MaxMetaspaceSize=10m -XX:MetaspaceSize=10m -XX:-UseCompressedClassPointers
 
9344
 Exception in thread "main" java.lang.OutOfMemoryError: Metaspace
     at java.lang.ClassLoader.defineClass1(Native Method)
     at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
     at java.lang.ClassLoader.defineClass(ClassLoader.java:635)
     at org.ybl.jvm.java1.OOMTest.main(OOMTest.java:24)
如何解决这些OOM？

1、要解决OOM异常或heap space的异常，一般的手段是首先通过内存映象分析工具(如Eclipse Memory Analyzer)对dump出来的堆存储快照进行分析，重点是确认内存中的对象是否是必要的，也就是先分清楚到底是出现了内存泄露(Memory Leak)还是内存溢出(Memory Overflow)

2、如果是内存泄露，可以进一步通过工具查看泄露对象到GC Roots的引用链。于是就能找到泄露对象是通过怎样的路劲与GC Roots相关联并导致 垃圾收集器无法自动回收他们的。掌握了泄露对象的类型信息，以及GC Roots引用链的信息，就可以比较准确地定位泄露代码的位置

3、如果不存在内存泄露，换句话说就是内存中的对象却是都还必须存活着，拿就应当检查虚拟机的堆参数(-Xmx 与 -Xms),与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。

方法区的内存结构

《深入理解Java虚拟机》书在中对方法区(Method Area)存储内容描述如下：

它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。

类型信息

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

1️⃣这个类型的完整的有效名称(全名=包名.类名)

2️⃣这个类型直接父类的完整有效名(对于interface或是java.lang.Object,都没有父类)

3️⃣这个类型的修饰符(public、abstract，final的某个子集)

4️⃣这个类型直接接口的一个有序列表

域(Field)信息

  • JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序

  • 域的相关信息包括：域名称、域类型、域修饰符(public、private、protected、static、final、volatitle、transient的某个子集)

方法(Method)信息

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

  • 方法名称

  • 方法的返回类型(按顺序)

  • 方法的修饰符(public、private、protected、static、final、synchronized、native、abstract的一个子集)

  • 方法的字节码(bytecodes)、操作数栈、局部变量表以及大小(abstract和native方法除外)

  • 异常表(abstract和native方法除外)

    • 每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引

non-final的类变量

  • 静态变量和类关联在一起，随着累的加载而加载，他们成为类数据在逻辑上的一部分。

  • 类变量被类的所有实例共享，即使没有类实例时也可以访问它

方法区的使用

public class MethodAreaDemo {
     public static void main(String[] args) {
         int x = 500;
         int y = 100;
         int a = x / y;
         int b = 50;
         System.out.println( a + b );
     }
 }

对应的字节码：

javap -v -p MethodAreaDemo.class > test.txt

 1 Classfile /F:/ideaproject/JVM_Study/src/org/ybl/jvm/java1/MethodAreaDemo.class
 2    Last modified 2021-1-5; size 450 bytes
 3    MD5 checksum f8fe0b840afbb4fcda6f69f4cc1ed662
 4    Compiled from "MethodAreaDemo.java"
 5  public class org.ybl.jvm.java1.MethodAreaDemo
 6    minor version: 0
 7    major version: 52
 8    flags: ACC_PUBLIC, ACC_SUPER
 9  Constant pool:
10     #1 = Methodref          #5.#14         // java/lang/Object."<init>":()V
11     #2 = Fieldref           #15.#16        // java/lang/System.out:Ljava/io/PrintStream;
12     #3 = Methodref          #17.#18        // java/io/PrintStream.println:(I)V
13     #4 = Class              #19            // org/ybl/jvm/java1/MethodAreaDemo
14     #5 = Class              #20            // java/lang/Object
15     #6 = Utf8               <init>
16     #7 = Utf8               ()V
17     #8 = Utf8               Code
18     #9 = Utf8               LineNumberTable
19    #10 = Utf8               main
20    #11 = Utf8               ([Ljava/lang/String;)V
21    #12 = Utf8               SourceFile
22    #13 = Utf8               MethodAreaDemo.java
23    #14 = NameAndType        #6:#7          // "<init>":()V
24    #15 = Class              #21            // java/lang/System
25    #16 = NameAndType        #22:#23        // out:Ljava/io/PrintStream;
26    #17 = Class              #24            // java/io/PrintStream
27    #18 = NameAndType        #25:#26        // println:(I)V
28    #19 = Utf8               org/ybl/jvm/java1/MethodAreaDemo
29    #20 = Utf8               java/lang/Object
30    #21 = Utf8               java/lang/System
31    #22 = Utf8               out
32    #23 = Utf8               Ljava/io/PrintStream;
33    #24 = Utf8               java/io/PrintStream
34    #25 = Utf8               println
35    #26 = Utf8               (I)V
36  {
37    public org.ybl.jvm.java1.MethodAreaDemo();
38      descriptor: ()V
39      flags: ACC_PUBLIC
40      Code:
41        stack=1, locals=1, args_size=1
42           0: aload_0
43           1: invokespecial #1                  // Method java/lang/Object."<init>":()V
44           4: return
45        LineNumberTable:
46          line 9: 0
47  ​
48    public static void main(java.lang.String[]);
49      descriptor: ([Ljava/lang/String;)V
50      flags: ACC_PUBLIC, ACC_STATIC
51      Code:
52        stack=3, locals=5, args_size=1
53           0: sipush        500
54           3: istore_1
55           4: bipush        100
56           6: istore_2
57           7: iload_1
58           8: iload_2
59           9: idiv
60          10: istore_3
61          11: bipush        50
62          13: istore        4
63          15: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
64          18: iload_3
65          19: iload         4
66          21: iadd
67          22: invokevirtual #3                  // Method java/io/PrintStream.println:(I)V
68          25: return
69        LineNumberTable:
70          line 11: 0
71          line 12: 4
72          line 13: 7
73          line 14: 11
74          line 15: 15
75          line 16: 25
76  }
77  SourceFile: "MethodAreaDemo.java"

 

方法区的演进

1、首先明确：只有HotSpot才有永久代 BEA JRockit、IBM J9等来说，是不存在永久代的概念的。原则上如何实现方法区属于虚拟机实现细节，不受《Java虚拟机规范》管束，并不要求统一。

2、HotSpot中方法区的变化：

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

方法区的垃圾收集

有些人认为方法区(如HotSpot虚拟机中的元空间或者永久代)是没有垃圾收集行为的，其实不然。《Java虚拟机规范》对方法区的约束是非常宽松的，提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在(如JDK1时期的ZGC收集器就不支持类卸载)。

一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻。但是这部分区域的回收又是又确实是必要的。以前Sun公司的Bug列表中，曾经出现过的若干个严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄露。

方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型。

  • 方法区内常量池中主要存放的两大类常量：字面量和符号引用。字面量比较接近Java语言层次的常量概念，如文本字符串。被声明为final的常量值等。二符号引用则属于编译原理方面的概念，包括下面三类常量：

    • 类和接口的全限定名

    • 字段的名称和描述符

    • 方法的名称和描述符

  • HotSpot虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收

  • 回收废弃常量与回收Java堆中的对象非常类似。

  • 判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件：

    • 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例。

    • 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGI、JSP的重加载等，否则通常是很难达成的。

    • 该类对应的java.lang.Class对象没有在任何地方被引用，无法再任何地方通过反射访问该类的方法。

  • Java虚拟机被允许对满足上述三个条件的吴用类进行回收，这里锁的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会会回收。关于是否要对类型进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class以及-XX:+TraceClass-Loading、-XX:+TraceClassUnLoading查看类加载和卸载信息

  • 在大量使用反射、动态代理、CGLib等字节码框架，动态生成JSP以及OSGI这类频繁自定义类加载器的场景中，通常都需要Java虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力。

6.运行时常量池

它是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项是常量池，用于存放编译期生成的各种字面量和符号引用。

并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用得到比较多的便是String类的intern()方法受方法区内存的限制，当常量池无法再申请到内存时会抛出OutOfMemoryError异常。

  • 运行时常量池是方法区的一部分

  • 常量池表示Class文件的一部分，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中

  • 运行时常量池，在加载类和接口到虚拟机后，就会创建对应的运行时常量池。

  • JVM为每个已加载的类型(类或接口)都维护一个常量池。池中的数据项想数组项一样，是通过索引访问的。

  • 运行四川航两次中包含多种不同的常量，包括编译期就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或者字段引用。此时不在是常量池中的符号地址了，这里换位真实地址。

    • 运行时常量池，相对于Class文件常量池的另一重要特征是：具备动态性

      • String.intern();

  • 运行时常量池类似于传统编程语言中的符号表(symbol table),但是它锁包含的数据却比符号表要更加丰富一些。

  • 当创建类或接口的运行时常量池时，如果构造运行时常量池所需的内存空间超过了方法区所能提供的最大值，则JVM会抛出OutOfMemoryError异常。

方法区包含了运行时常量池。字节码文件，内部包含了常量池。要弄清楚方法区，需要理解ClassFile，因为加载类的信息都在方法区。要弄清楚方法区的运行时常量池，需要理解秦楚ClassFile的常量池。

一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述信息外，还包含一项信息那就是常量池表(Constant Pool Table)，包括各种字面量和对类型、域和方法的符号引用。

为什么需要常量池？

一个java源文件中的类、接口，变异后产生一个字节码文件。而Java中的字节码需要数据支持，通常这种数据会很大以至于不能直接存到字节码里，换另一种方式，可以存到常量池，这个字节码包含了指向常量池的引用。在动态链接的时候会用到运行时常量池，之前有介绍。

如：

1 public class SimpleClass{
2      public void sayHello(){
3          System.out.println("hello");
4      }
5  }

虽然只有194字节，但是里面却使用了String、System、PrintStream及Object等结构。这里代码量其实已经很小了。如果代码多，引用到的结构会更多！这里就需要常量池了。

7.直接内存

它不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。

JDK 1.4中新加入了NIO(New Input/Output)类，引入了一种基于通道与缓冲区的I/O方式，他可以使用native函数库直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。因为避免了在Java堆和Native堆中来回复制数据，所以能在一些场景中显著提高性能。各个内存区域总和大于物理内存限制，从而导致动态扩展时出现OutOfMemoryError异常

概述

  • 首先明确一点，它不是虚拟机运行时数据区的一部分,也不是《Java虚拟机规范》中定义的内存区域

  • 直接内存是在Java堆外的、直接向系统申请的内存区间

  • 来源于NIO，通过存在堆中的DirectByteBuffer操作Native内存

  •  
     1 public class BufferTest {
 2      private static final int BUFFER = 1024 * 1024 * 1024;//1GB
 3  ​
 4      public static void main(String[] args) {
 5          ByteBuffer byteBuffer = ByteBuffer.allocateDirect( BUFFER );
 6          System.out.println( "分配内存成功，请操作" );
 7          Scanner scanner = new Scanner( System.in );
 8          scanner.next();
 9          System.out.println( "直接内存开始释放" );
10          byteBuffer = null;
11          System.gc();
12          scanner.next();
13      }
14  }

  • 通常，访问直接内存的速度会优于Java堆。即读写性能高

    • 因此处于性能考虑，读写频繁的场合可能会直接使用直接内存。

    • Java的NIO库允许Java程序使用直接内存，用于数据缓冲区。

  • 也可能导致OutOfMemoryError：Direct buffer memory 异常

  • 由于直接内存在Java堆外，因此它的大小不会直接受限于-Xmx指定的最大小，但是系统内存是有限的，Java堆和直接内存的总和依然受限于操作系统能给出的最大内存。

  • 缺点：

    • 分配回收成本较高

    • 不受JVM内存回收管理

  • 直接内存大小可以通过MaxDirectMemorySize设置

  • 如果不指定，默认与堆的最大值-Xmx参数值一致。

posted @ 2021-10-26 18:35  程序员清风  阅读(165)  评论(0)    收藏  举报