运行时内存
程序计数器
- 作用:记录每个线程的代码执行到哪一条指令了
- 为了保证程序(在操作系统中理解为进程)能够连续地执行下去,CPU必须具有某些手段来确定下一条指令的地址。而程序计数器正是起到这种作用,所以通常又称为指令计数器。
- 在程序开始执行前,必须将它的起始地址,即程序的一条指令所在的内存单元地址送入PC,因此程序计数器(PC)的内容即是从内存提取的第一条指令的地址。当执行指令时,CPU将自动修改Pc的内容,即每执行一条指令Pc增加一个量,这个量等于指令所含的字节数,以便使其保持的总是将要执行的下一条指令的地址。
- 由于大多数指令都是按顺序来执行的,所以修改的过程通常只是简单的对Pc加1。
- 当程序转移时,转移指令执行的最终结果就是要改变PC的值,此PC值就是转去的地址,以此实现转移。有些机器中也称PC为指令指针IP (Instruction Pointer)
- 任何时间一个线程都只有一个方法在执行,也就是所谓的当前方法。程序计数器会存储当前线程正
在执行的Java方法的JVM指令地址;或者,如果是在执行native方法,则是未指定值(
undefined)。:native 本地方法是大多是通过c实现,并未编译成需要执行的字节码指令,所以在计数器中当然是空 (undefined)
- 小结:
- 它是程序控制流的指示器,分支、循环、跳转、异常处理、线程恢复等基础功能都个计数器来完成。
- PC寄存器用来存储指向下一条指令的地址,也即将要执行的指令代码。执行引擎的器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。
- 它是一块很小的内存空间,几乎可以忽略不记。也是运行速度最快的存储区域。不会随着程序的运行需要更大的空间。
- 在JVM规范中,每个线程都有它自己的程序计数器,是线程私有的,生命周期与线程的生命周期保持一致。
- 它是唯一一个在了ava 虚拟机规范中没有规定任何Outot/emoryError 情况的区城。
栈基础
- 栈管运行,堆管存储
- 作用:
- 主管Java程序的运行,它保存方法的局部变量(8种基本数据类型、对象的引用地址)、部分结果,并参与方法的调用和返回。
- 局部变量 Vs 成员变量(或属性)
- 基本数据变量 vs 引用类型变量(类、数组、接口)
- 栈和堆堆区别:
- 角度一 是否存在GC和OOM :
- 角度二 内存大小和数据结构: 栈小堆大 ;栈就是一个栈,堆空间更复杂,可以有各种数据结构.
- 角度三执行效率:栈快堆慢
- 角度四内容:栈存基本变量和引用地址,堆存放原类型
- 角度五作用:栈管运行,堆管存储
- 栈中不存在垃圾回收,栈会溢出
- 栈溢出的原因:
- 递归
- 局部变量表过大
- 栈溢出的原因:
- 栈大小如何设置:
- -Xss size :默认1M (即: -XX: ThreadStackSize ) 这个命令在IDEA Run configuration里面去编辑,VM options
- 设置过大,导致系统可用创建线程的数量减少.一般有3000-5000个线程
- 5.0之前默认大小 256k
- 5.0之后默认大小 1024k
栈帧
- 方法和栈帧的关系:
- 在这个线程上正在执行的每个方法都各自对应一个栈帧(Stack Frame)
- 栈帧是一个内存区块,是一个数据集,维系着方法执行过程中的各种数据信息。
- 在一条活动线程中,一个时间点上,只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧(栈顶栈帧)是有效的,这个栈帧被称为当前栈帧(Current Frame),与当前栈帧相对应的方法就是当前方法(Current Method),定义这个方法的类就是当前类(Current Class)
- 如果在该方法中调用了其他方法,对应的新的栈帧会被创建出来,放在栈的顶端,成为新的当前帧。
- 执行引擎运行的所有字节码指令只针对当前栈帧进行操作。
- Java栈操作:
- JVM直接对Java栈的操作只有两个:
- 每个方法执行,伴随着进栈(入栈、压栈)
- 执行结束后的出栈工作
- 遵循“先进后出”/“后进先出”原则
- 不同线程中所包含的栈帧是不允许存在相互引用的,即不可能在一个栈帧之中引用另外一个线程的栈帧。
- 如果当前方法调用了其他方法,方法返回之际,当前栈帧会传回此方法的执行结果给前一个栈帧,接着,虚拟机会丢弃当前栈帧,使得前一个栈帧重新成为当前栈帧。
- Java方法有两种返回函数的方式,一种是正常的函数返回,使用return指令;另外一种是抛出异常。不管使用哪种方式,都会导致栈帧被弹出。
- JVM直接对Java栈的操作只有两个:
- 栈帧内部结构:
- 局部变量表(Local Variables) ,用来存放操作数栈
- 操作数栈(Operand Stack)(或表达式栈)
- 动态链接(Dynamic Linking)(或指向运行时常量池的方法引用)
- 方法返回地址(Return Address)(或方法正常退出或者异常退出的定义)
- 一些附加信息
局部变量表
- 本质就是一个数组
- 局部变量表也被称之为局部变量数组或本地变量表
- 定义为一个数字数组,主要用于存储方法参数和定义在方法体内的局部变量,这些数据类型包括各类基本数据类型(8种)、对象引用(reference),以及returnAddress类型。
- 局部变量表所需的容量大小是在编译期确定下来的,并保存在方法的Code属性的maximum local variables数据项中。在方法运行期间是不会改变局部变量表的大小的。局部变量表越大,栈帧也会越大
- 方法嵌套调用的次数由栈的大小决定。一般来说,栈越大,方法嵌套调用次数越多。对一个函数而言,它的参数和局部变量越多,使得局部变量表膨胀,它的栈帧就越大,以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间,导致其嵌套调用次数就会减少
- 局部变量表中的变量只在当前方法调用中有效。在方法执行时,虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后,随着方法栈帧的销毁,局部变量表也会随之销毁。
- 非静态的方法里面,默认有一个this参数作为0号参数.
- double和long会占用两个局部变量表的slot(槽位).
- 局部变量由于不是成员变量,没有初始化过程,在未赋值的情况下是不可以直接调用的
- slot的理解
- 参数值的存放总是在局部变量数组的index为0开始,到数组长度-1的索引结束。
- 局部变量表,最基本的存储单元是Slot(变量槽)
- 在局部变量表里,32位以内的类型只占用一个slot(包括returnAddress类型),64位的类型(1ong和double)占用两个slot。
- byte 、short 、char 在存储前被转换为int, boolean 也被转换为int,0 表示false,非0表示true。
- long 和double则占据两个Slot。
- ]VM会为局部变量表中的每一个S1ot都分配一个访问索引,通过这个索引即可成功访问到局部变量表中指定的局部变量值
- 当一个实例方法被调用的时候,它的方法参数和方法体内部定义的局部变量将会按照顺序被复制到局部变量表中的每一个Slot上.
- 如果需要访问局部变量表中一个64bit的局部变量值时,只需要使用前一个索引即可。(访问long或double类型变量)
- 如果当前帧是由构造方法或者实例方法创建的,那么该对象引用this将会存放在index为Q的slot处,其余的参数按照参数表顺序继续排列。
- 槽位复用
- 栈帧中的局部变量表中的槽位是可以重用的,如果一个局部变量过了其作用域,那么在其作用域之后申明的新的局部变量就很有可能会复用过期局部变量的槽位,从而达到节省资源的目的。
-
// slot = 3 public void test4() { int a = 0; { int b = 0; b = a + 1; } //变量c的位置:复用了变量b的slot int c = a + 1; }
- 局部变量表结构:
- index索引:槽位slot的起始地址
- Name 名称:
- Descriptor描述: 主要是表示类型
- StartPC Length:作用域,存储的是地址索引的偏移量,
- StartPC :起始值
- Length:长度
- 与GC Roots的关系
- 局部变量表中的变量也是重要的垃圾回收根节点,只要被局部变量表中直接或间接引用的对象都不会被回收。
- 局部变量表中的变量也是重要的垃圾回收根节点,只要被局部变量表中直接或间接引用的对象都不会被回收。
操作数栈
- 不存在垃圾回收
- 入栈指令:
- 局部变量压栈指令: push
- 常量入栈指令: push ldc
- 出栈装入局部变量表指令: store
- 基本概念:
- 我们说Java虚拟机的解释引擎是基于栈的执行引擎,其中的栈指的就是操作数栈。
- 每一个独立的栈帧中除了包含局部变量表以外,还包含一个后进先出(Last-In-First-out)的操作数栈,也可以称之为表达式栈(ExpressionStack)。
- 操作数栈就是JVM执行引擎的一个工作区,当一个方法刚开始执行的时候,一个新的栈帧也会随之被创建出来,这个方法的操作数栈是空的。
- 每一个操作数栈都会拥有一个明确的栈深度用于存储数值,其所需的最大深度在编译期就定义好了,保存在方法的Code属性中,为max_stack的值。
- 栈中的任何一个元素都是可以任意的Java数据类型。
- 32bit的类型占用一个栈单位深度
- 64bit的类型占用两个栈单位深度
- 操作数栈,在方法执行过程中,根据字节码指令,并非采用访问索引的方式来进行数据访问的,而是只能通过标准的入栈 (push) 和出栈 (pop)操作,往栈中写入数据或提取数据来完成一次数据访问。
- 某些字节码指令将值压入操作数栈,其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈。比如:执行复制、交换、求和等操作
- 如果被调用的方法带有返回值的话,其返回值将会被压入当前栈帧的操作数栈中,并更新Pc寄存器中下一条需要执行的字节码指令。
- 操作数栈,主要用于保存计算过程的中间结果,同时作为计算过程中变量临时的存储空间。
- 操作数栈中元素的数据类型必须与字节码指令的序列严格匹配,这由编译器在编译器期间进行验证,同时在类加载过程中的类检验阶段的数据流分析阶段要再次验证。
- return操作是在操作数栈里面弹出去的,先iload然后ireturn
- 栈顶缓存技术
- 前面提过,基于栈式架构的虚拟机所使用的零地址指令更加紧凑,但完成一项操作的时候必然需要使用更多的入栈和出栈指令,这同时也就意味着将需要更多的指令分派(instruction dispatch) 次数和内存读/写次数。
- 由于操作数是存储在内存中的,因此频繁地执行内存读/写操作必然会影响执行速度。为了解决这个问题,HotSpotJVM的设计者们提出了栈顶缓存(ToS, Top-of-Stack Cashing)技术,将栈顶元素全部缓存在物理CPu的寄存器中,以此降低对内存的读/写次
数,提升执行引擎的执行效率。
- 思考:为什么需要操作数栈.
- Java语言指令基于栈设计,非常简单,他只需要执行load操作就行,就会加入到栈中,不需要像C语言一样,还需要管理寄存器,从哪个寄存器取数,之后再放到哪里,Java不需要管,指令更简单.
动态链接
- 动态链接是一个指向调用当前函数的函数的栈帧的指针。
- 主要目的:它的主要目的是在当前函数执行完成后,能够找到上一个函数(即调用当前函数的函数)的栈帧。通过动态链接,程序可以在函数调用链中向上跟踪,返回到之前的函数调用。
- 每一个栈帧内部都包含一个指向运行时常量池中该栈帧所属方法的引用。包含这个引用的目的就是为了支持当前方法的代码能够实现动态链接(Dynamic Linking)。比如invokedynamic指令.
- 在Java源文件被编译到字节码文件中时,所有的变量和方法引用都作为符号引用(Symbolie Reference) 保存在class文件的常量池里。比如:描述一个方法调用了另外的其他方法时,就是通过常量池中指向方法的符号引用来表示的,那么动态链接的作用就是为了将这些符号引用转换为调用方法的直接引用。
- 为什么需要动态链接:
- 便于调用其他方法,字节码指令是指向了调用方法的符号引用,这里需要将符号引用动态转化为直接引用,所以叫动态链接.
- 方法调用:
- 在JVM中,将符号引用转换为调用方法的直接引用与方法的绑定机制相关。
- 静态链接:
- 当一个字节码文件被装载进JVM内部时,如果被调用的目标方法在编译期可知,且运行期保持不变时。这种情况下将
调用方法的符号引用转换为直接引用的过程称之为静态链接。
- 当一个字节码文件被装载进JVM内部时,如果被调用的目标方法在编译期可知,且运行期保持不变时。这种情况下将
- 动态链接:
- 如果被调用的方法在编译期无法被确定下来,也就是说,只能够在程序运行期将调用方法的符号引用转换为直接引用由于这种引用转换过程具备动态性,因此也就被称之为动态链接。
- 对应的方法的绑定机制为:早期绑定(Early Binding) 和晚期绑定(Late Binding)。绑定是一个字段、方法或者类在符号引用被替换为直接引用的过程,这仅仅发生一次。
- 早期绑定:
- 早期绑定就是指被调用的目标方法如果在编译期可知,且运行期保持不变时,即可将这个方法与所属的类型进行绑定这样一来,由于明确了被调用的目标方法究竟是哪一个,因此也就可以使用静态链接的方式将符号引用转换为直接引用。
- 晚期绑定:
- 如果被调用的方法在编译期无法被确定下来,只能够在程序运行期根据实际的类型绑定相关的方法,这就被称之为晚期绑定。
方法返回地址
- 存放调用该方法的pc寄存器的值。方法返回地址是一个指向调用当前函数的函数中的下一条指令的地址。
- 一个方法的结束,有两种方式:
- 正常执行完成
- 出现未处理的异常,非正常退出
- 无论通过哪种方式退出,在方法退出后都返回到该方法被调用的位置。方法正常退出时,调用者的pc计数器的值作为適回地址,即调用该方法的指令的下一条指令的地址。而通过异常退出的,返回地址是要通过异常表来确定,栈帧中一般不会保存这部分信息。
- 当一个方法开始执行后,只有两种方式可以退出这个方法:
- 执行引擎遇到任意一个方法返回的字节码指令(return),会有返回值传递给上层的方法调用者简称正常完成出口:
- 一个方法在正常调用完成之后究竟需要使用哪一个返回指令还需要根据方法返回值的实际数据类型而定。
- 在字节码指令中,返回指令包含ireturn(当返回值是boolean、 byte、char、short和int类型时使用)、lreturn、freturn、 dreturn 以及areturn,另外还有一个return指令供声明为void的方法、实例初始化方法、类和接口的初始化方法使用。
- 在方法执行的过程中遇到了异常(Exception),并且这个异常没有在方法内进行处理,也就是只要在本方法的异常表中没有搜索到匹配的异常处理器,就会导致方法退出。简称异常完成出口。
- 方法执行过程中抛出异常时的异常处理,存储在一个异常处理表,方便在发生异常的时候找到处理异常的代码。
- 执行引擎遇到任意一个方法返回的字节码指令(return),会有返回值传递给上层的方法调用者简称正常完成出口:
- 本质上,方法的退出就是当前栈帧出栈的过程。此时,需要恢复上层方法的局部变量表、操作数栈、将返回值压入调用者栈帧的操作数栈、设置PC寄存器值等,让调用者方法继续执行下去。
- 正常完成出口和异常完成出口的区别在于:通过异常完成出口退出的不会给他的上层调用者产生任何的返回值.
栈面试的五个问题
- 问题一:栈溢出的情况?
- 栈溢出:StackoverflowError;
- 举个简单的例子:在main方法中调用main方法,就会不断压栈执行,直到栈溢出;
- 栈的大小可以是固定大小的,也可以是动态变化(动态扩展)的。
- 如果是固定的,可以通过-Xss设置栈的大小;
- 如果是动态变化的,当栈大小到达了整个内存空间不足了,就是抛出OutofMemory异常(java. lang. OutofMemoryError)
- 问题二:调整栈大小,就能保证不出现溢出吗?
- 不能。因为调整栈大小,只会减少出现溢出的可能,栈大小不是可以无限扩大的,所以不能保证不出现溢出
- 问题三:分配的栈内存越大越好吗?
- 不是,因为增加栈大小,会造成每个线程的栈都变的很大,使得一定的栈空间下,能创建的线程数量会变小
- 问题四:垃圾回收是否会涉及到虚拟机栈?
- 不会;垃圾回收只会涉及到方法区和堆中,方法区和堆也会存在溢出的可能;
- 程序计数器,只记录运行下一行的地址,不存在溢出和垃圾回收;
- 虚拟机栈和本地方法栈,都是只涉及压栈和出栈,可能存在栈溢出,不存在垃圾回收。
- 问题五:方法中定义的局部变量是否线程安全?
- 具体问题具体分析
- 结论:如果局部变量在内部产生并在内部消亡的,那就是线程安全的
//s1的声明方式是线程安全的,因为线程私有,在线程内创建的s1 ,不会被其它线程调用
public static void method1() {
//StringBuilder:线程不安全
StringBuilder s1 = new StringBuilder();
s1.append("a");
s1.append("b");
//...
}
//stringBuilder的操作过程:是线程不安全的,
// 因为stringBuilder是外面传进来的,有可能被多个线程调用
public static void method2(StringBuilder stringBuilder) {
stringBuilder.append("a");
stringBuilder.append("b");
//...
}
//stringBuilder的操作:是线程不安全的;因为返回了一个stringBuilder,
// stringBuilder有可能被其他线程共享
public static StringBuilder method3() {
StringBuilder stringBuilder = new StringBuilder();
stringBuilder.append("a");
stringBuilder.append("b");
return stringBuilder;
}
//stringBuilder的操作:是线程安全的;因为返回了一个stringBuilder.toString()相当于new了一个String,
// 所以stringBuilder没有被其他线程共享的可能
public static String method4() {
StringBuilder stringBuilder = new StringBuilder();
stringBuilder.append("a");
stringBuilder.append("b");
return stringBuilder.toString();
}
本地方法栈
- 简单地讲,一个Native Method就是一个JaVa调用非Java代码的接口。一个Native Method是这样一个Java方法:该方法的实现由非Java语言实现,比如C。这个特征并非Java所特有,很多其它的编程语言都有这一机制,比如在C++中,你可以用extern "C"告知c++编译器去调用一个c的函数。
- “A native method is a Java method whose implementation is provided by non - java code.”
- 在定义一个native method时,并不提供实现体(有些像定义一个Java interface),因为其实现体是由非java语言在外面实现的。
- 本地接口的作用是融合不同的编程语言为Java所用,它的初衷是融合 C/C++程序。
- 当某个线程调用一个本地方法时,它就进入了一个全新的并且不再受虚拟机限制的世界。它和虚拟机拥有同样的权限。
- 本地方法可以通过本地方法接口来访问虚拟机内部的运行时数据区。
- 它甚至可以直接使用本地处理器中的寄存器
- 直接从本地内存的堆中分配任意数量的内存。
- 并不是所有的JVM都支持本地方法。因为Java虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构等。如果JVM产品不打算支持native方法,也可以无需实现本地方法栈。
堆空间
- 概念
- 一个JVM实例只存在一个堆内存,堆也是Java内存管理的核心区域。
- Java 堆区在JVM启动的时候即被创建,其空间大小也就确定了。是JVM管理的最大一块内存空间。
- 堆内存的大小是可以调节的。
- 《Java虚拟机规范》规定,堆可以处于物理上不连续的内存空间中,但在逻辑上它应该被视为连续的。
- 堆,是GC(Garbage Collection,垃圾收集器)执行垃圾回收的重点区域。
- 在方法结束后,堆中的对象不会马上被移除,仅仅在垃圾收集的时候才会被移除。
- 堆的一些特性:
- 所有的对象实例和数组都应该分配在堆空间上
- 特例:栈上分配,优化行为
- 所有的线程共享Java堆
- 在这里还可以划分线程私有的缓冲区(Thread LocalAllocation Buffer,TLAB)。
- 所有的对象实例和数组都应该分配在堆空间上
- 堆的内部结构:
- 现代垃圾收集器大部分都基于分代收集理论设计,堆空间细分为:
- 年轻代与老年代
- 存储在]VM中的Java对象可以被划分为两类:
- 一类是生命周期较短的瞬时对象,这类对象的创建和消亡都非常迅速
- 另外一类对象的生命周期却非常长,在某些极端的情况下还能够与JVM的生命周期保持一致。
- Java堆区进一步细分的话,可以划分为年轻代(YoungGen) 和老年代(0ldGen)
- 其中年轻代又可以划分为Eden空间、Survivoro空间和Survivor1空间(有时也叫做from区、to区)。
- 几乎所有的Java对象都是在Eden区被new出来的。
- 大对象直接进入老年代
- 绝大部分的Java对象的销毁都在新生代进行了。
- IBM 公司的专门研究表明,新生代中80% 的对象都是“朝生夕死”的。
- 对象在Eden创建,幸存的进入survivor,然后进入老年代.
- 存储在]VM中的Java对象可以被划分为两类:
- 堆内存的大小
- Java堆区用于存储Java对象实例,那么堆的大小在JVM启动时就已经设定好了,大家可以通过选项”-Xmx”和”-Xms”来进行设置。
- “-Xms”用于表示堆区的起始内存,等价于-XX:InitialHeapSize
- “-Xmx’”则用于表示堆区的最大内存,等价于-XX:MaxHeapSize
- 一旦堆区中的内存大小超过“-Xmx”所指定的最大内存时,将会抛出OutofMemoryError异常。
- 通常会将 -Xms 和 -Xmx两个参数配置相同的值,其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小,从而提高性能。
- heap默认最大值计算方式:如果物理内存少于192M,那么heap最大值为物理内存的一半如果物理内存大于等于1G,那么heap的最大值为物理内存的1/4。
- heap默认最小值计算方式:最少不得少于8M,如果物理内存大于等于1G,== ==,即1024/64=16M。最小堆内存在jvm启动的时候就会被初始化。
- Java堆区用于存储Java对象实例,那么堆的大小在JVM启动时就已经设定好了,大家可以通过选项”-Xmx”和”-Xms”来进行设置。
- 新生代和老年代比例
- 下面这参数开发中一般不会调:
- 配置新生代与老年代在堆结构的占比。
- 默认-XX:NewRatio=2,表示新生代占1,老年代占2,新生代占整个堆的1/3
- 可以修改-XX:NewRatio=4,表示新生代占1,老年代占4,新生代占整个堆的1/5
- 可以使用选项”-Xmn ”设置新生代最大内存大小
- 这个参数一般使用默认值就可以了。
- 在HotSpot中,Eden空间和另外两个Survivor空间缺省所占的比例是8:1:1
- 当然开发人员可以通过选项“-XX:SurvivorRatio”调整这个空间比例。比如-XX: SurvivorRatio=8
- 正常情况下是6:1:1
- 对象的分配:
-
为新对象分配内存是一件非常严谨和复杂的任务,JVM的设计者们不仅需要考虑内存如何分配在哪里分配等问题,并且由于内存分配算法与内存回收算法密切相关,所以还需要考虑GC执行完内存回收后是否会在内存空间中产生内存碎片。
-
金句:
- 针对幸存者s0,s1区的总结:复制之后有交换,谁空谁是to.
- 关于垃圾回收:
- 频繁在新生区收集
- 很少在养老区收集
- 几乎不在永久区/元空间收集
-
过程剖析:
- new的对象先放伊甸园区。此区有大小限制。
- 当伊甸园的空间填满时,程序又需要创建对象,]VM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC/YGc),将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区
- 然后将伊甸园中的剩余对象移动到幸存者0区。
- 如果再次触发垃圾回收,此时上次幸存下来的放到幸存者0区的,如果没有回收,就会放到幸存者1区。
- 如果再次经历垃圾回收,此时会重新放回幸存者0区,接着再去幸存者1区。
- 啥时候能去养老区呢?可以设置次数。默认是15次。
- 可以设置参数:-XX:MaxTenuringThreshold=〈N〉设置对象晋升老年代的年龄阈值
- 在养老区,相对悠闲。当养老区内存不足时,再次触发GC:Major GC,进行养老区的内存清理。
- 若养老区执行了Major GC之后发现依然无法进行对象的保存,就会产生OOM异常
- java. lang. OutOfMemoryError:Java heap space
-
内存分配原则
- 针对不同年龄段的对象分配原则如下所示:
- 优先分配到Eden
- 大对象直接分配到老年代
- 尽量避免程序中出现过多的大对象
- 长期存活的对象分配到老年代
- 动态对象年龄判断
- 如果Survivor 区中相同年龄的所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象可以直接进入老年代,无须等到MaxTenuringThreshold 中要求的年龄。
- 空间分配担保
- -XX:HandlePromotionFailure
- 针对不同年龄段的对象分配原则如下所示:
-
- 空间分配担保策略
0. 名称解释:
- Minor GC: 针对新生代的垃圾回收
- 非Minor GC:对老年代的垃圾回收
- Full GC:- HandlePromotionFailure :是否使用空间担保策略
- 在发生Minor Gc之前,虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间,
- 如果大于,则此次Minor Gc是安全的
- 如果小于,则虚拟机会查看-XX:HandlePromotionFailure设置值是否允许担保失败
- 如果HandlePromotionFailure = true,那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小,如果大于,则尝试进行一次MinorGC,但这次MinorGc依然是有风险的:如果小于或HandlePromotionFailure=false,则改为进行一次Full GC。
- 在JDK 6 Update 24之后,HandlePromotionFailure参数不会再影响到虚拟机的空间分配担保策略,观察OpenJDK中的源码变化,虽然源码中还定义了HandlePromotionFailure参数,但是在代码中已经不会再使用它。JDK 6 Update 24之后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC,否则将进行Full GC。
- Minor GC 、Major GC 、 Full GC
- JVM在进行Gc时,并非每次都对上面三个内存(新生代、老年代:方法区)区域一起回收的,大部分时候回收的都是指新生代。
- 针对HotSpot VM的实现,它里面的Gc按照回收区域又分为两大种类型:
- 一种是部分收集 (Partial Gc)
- 一种是整堆收集(Fu11 Gc)
- 部分收集:不是完整收集整个Java堆的垃圾收集。其中又分为:
- 新生代收集 (Minor GC Young Gc):只是新生代(Eden so, S1)的垃圾收集
- 老年代收集(Major GC / old Gc):只是老年代的垃圾收集。
- 目前,只有CMS GC会有单独收集老年代的行为。
- 注意,很多时候Major GC会和Full Gc混淆使用,需要具体分辨是老年代回收还是整堆回收。
- 混合收集(Mixed GC):收集整个新生代以及部分老年代的垃圾收集。
- 目前,只有G1 GC会有这种行为
- 整堆收集(Full GC):收集整个java堆和方法区的垃圾收集。
- 年轻代GC(Minor Gc)触发机制:
- 当年轻代空间不足时,就会触发Minor GC。这里的年轻代满指的是Eden区满,Survivor满不会引发GC。(每次 Minor GC 会清理年轻代的内存。)
- 因为 Java 对象大多都具备朝生夕灭的特性,所以MinorGC 非常频繁,一般回收速度也比较快。
- Minor Gc会引发STW,暂停其它用户的线程,等垃圾回收结束,用户线程才恢复运行
- 老年代GC (Major GC/Full Gc)触发机制:
- 指发生在老年代的GC,对象从老年代消失时,我们说“Major Gc”或“Full GC”发生了。
- 出现了Major GC,经常会伴随至少一次的Minor Gc(但非绝对的,在ParallelScavenge收集器的收集策略里就有直接进行Major Gc的策略选择过程
- 也就是在老年代空间不足时,会先尝试触发Minor GC(与老年代无关,只是会先触发,避免刚刚把老年代清理,又触发了Major GC)。如果之后空间还不足,则触发Major GC
- Major Gc的速度一般会比Minor GC慢10倍以上,STW的时间更长。
- 如果Major GC 后,内存还不足,就报OOM了。
- 指发生在老年代的GC,对象从老年代消失时,我们说“Major Gc”或“Full GC”发生了。
- Full Gc触发机制:
- 触发Ful1 GC 执行的情况有如下五种:
- 调用System.gc()时,系统建议执行Fu11 GC,但是不必然执行
- 老年代空间不足
- 方法区空间不足
- 通过Minor Gc后进入老年代的平均大小大于老年代的可用内存
- 由Eden区、survivorspace0 (From Space)区向survivor space1 (To Space)区复制时,对象大小大于To Space可用内存,则把该对象转存到老年代,且老年代的可用内存小于该对象大小
- 说明:full gc是开发或调优中尽量要避免的。这样暂时时间会短一些。
- 触发Ful1 GC 执行的情况有如下五种:
- 有时候在Major GC之前会触发Minor GC,这个时候就叫Full GC。
- OOM如何解决
- 要解诀QOM异常或heap space的异常,一般的手段是首先通过内存映像分析工具(如Eclipse Memory Analyzer)对dump 出来的堆转储快照进行分析,重点是确认内存中的对象是否是必要的,也就是要先分清楚到底是出现了==内存泄漏(Memory Leak)还是内存溢出==Memory Overflow).
- 如果是内存泄漏,可进一步通过工具查看泄漏对象到GC Roots 的引用链。于是就能找到泄漏对象是通过怎样的路径与GC Roots 相关联并导致垃圾收集器无法自动回收它们的。掌握了泄漏对象的类型信息,以及GC Roots引用链的信息,就可以比较准确地定位出泄漏代码的位置。
- 如果不存在内存泄漏,换句话说就是内存中的对象确实都还必须存活着,那就应当检查虚拟机的堆参数(-Xmx 与-Xms),与机器物理内存对比看是否还可以调大,从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况,尝试减少程序运行期的内存消耗。
- 堆空间的分代思想
- 经研究,不同对象的生命周期不同。70%-99%的对象是临时对象。
- 新生代:有Eden、两块大小相同的Survivor(又称为from/to,sO/s1)构成,to总为空。
- 老年代:存放新生代中经历多次GC仍然存活的对象。
- 为什么需要把Java堆分代?不分代就不能正常工作了吗?
- 其实不分代完全可以,分代的唯一理由就是优化Gc性能。如果没有分代,那所有的对象都在一块,就如同把一个学校的人都关在一个教室。Gc的时候要找到哪些对象没用,这样就会对堆的所有区域进行扫描。而很多对象都是朝生夕死的,如果分代的话,把新创建的对象放到某一地方,当GC 的时候先把这块存储“朝生夕死”对象的区域进行回收,这样就会腾出很大的空间出来。
- 经研究,不同对象的生命周期不同。70%-99%的对象是临时对象。
- 快速分配策略:TLAB
- 概念:
- 从内存模型而不是垃圾收集的角度,对Eden区域继续进行划分,JVM为每个线程分配了一个私有缓存区域,它包含在Eden空间内。主要是各个对象如果要new对象的话,在自己的空间里,不涉及加锁,性能会更好
- 据我所知所有OpenJDK衍生出来的JVM都提供了TLAB的设计。
- 为什么有TLAB
- 堆区是线程共享区域,任何线程都可以访问到堆区中的共享数据
- 由于对象实例的创建在JVM中非常频繁,因此在并发环境下从堆区中划分内存空间是线程不安全的
- 为避免多个线程操作同一地址,需要使用加锁等机制,进而影响分配速度。
- 所以,多线程同时分配内存时,使用TLAB可以避免一系列的非线程安全问题,同时还能够提升内存分配的吞吐量,因此我们可以将这种内存分配方式称之为快速分配策咯。
- 所以说堆空间也不是全部都是共享的
- TLAB的再说明:
- 尽管不是所有的对象实例都能够在TLAB中成功分配内存,但JVM确实是将TLAB作为内存分配的首选。
- 在程序中,开发人员可以通过选项“-XX:+/-UseTLAB” 设置是否开启TLAB空间。默认开启
- 默认情况下,TLAB空间的内存非常小,仅占有整个Eden空间的1%,当然我们可以通过选项“-XX:TLABWasteTargetPercent”设置TLAB经间所占用Eden空间的百分比大小。
- 一旦对象在TLAB空间分配内存失败时,JVM就会尝试着通过使用加锁机制确保数据操作的原子性,从而直接在Eden空间中分配内存。
- 概念:
- 参数设置小结
- -Xms -Xmx : 堆的初始 和 最大
- -Xmn : 新生代最大内存
- -XX:NewRatio : 新生代和老年代的比例, 设置为2时代表 新生代:老年代 = 1:2
- -XX:SurvivorRatio : 幸存区和Eden的比例,默认为6,就是E:S0:S1 = 6:1:1
- -XX MaxTenuring Threshold : 由新生代晋升到老年代的阈值,每经历一次回收,对象的年龄会+1,达到阈值时就进入老年代
- -XX:+PrintGCDetails :垃圾回收参数,启动详细的垃圾回收日志
- -XX:HandlePromotionFailure 空间分配担保策略
- -XX:+ PrintFlagsFinal : 输出 JVM 启动时的所有标志(flags)及其最终值。
方法区
- 方法区回收效果更差
- 栈、堆、方法区关系
- 位置:
《Java虚拟机规范》中明确说明:“尽管所有的方法区在逻辑上是属于堆的一部分,但一些简单的实现可能不会选择去进行垃圾收集或者进行压缩。”但对于HotSpotJVM而言,方法区还有一个别名叫做Non-Heap(非堆),目的就是要和堆分开。所以,方法区看作是一块独立于Java 堆的内存空间。 - 方法区的理解:
-
线程共享角度:
- 方法区(Method Area) 与Java堆一样,是各个线程共享的内存区域。
- 方法区在JVM启动的时候被创建,并且它的实际的物理内存空间中和Java堆区一样都可以是不连续的。
- 方法区的大小,跟堆空间一样,可以选择固定大小或者可扩展。
- 方法区的大小决定了系统可以保存多少个类,如果系统定义了太多的类,导致方法区溢出,虚拟机同样会抛出内存溢出错误:java.lang. OutofMemoryError:PermGen space 或者java. lang.OutofMemoryError: Metaspace
- 加载大量的第三方的jar包;Tomcat部署的工程过多(30-50个);大量动态的生成反射类
- 关闭JVM就会释放这个区域的内存。
-
- HotSpot中方法区的演进
- 在jdk7及以前,习惯上把方法区,称为永久代。jdk8开始,使用元空间取代了永久代。
- 本质上,方法区和永久代并不等价。仅是对hotspot而言的。《Java虚拟机规范》对如何实现方法区,不做统一要求。例如:BEA JRockit/ IBM 19中不存在永久代的概念。
- 现在来看,当年使用永久代,不是好的idea。导致Java程序更容易00M(超过 -XX: MaxPermSize上限)
- 而到了JDK 8,终于完全废弃了永久代的概念,改用与JRockit、]9一样在本地内存中实现的元空间来代替
- 元空间的本质和永久代类似,都是对JVM规范中方法区的实现。不过元空间与永久代最大的区别在于:元空间不在虚拟机设置的内存中,而是使用本地内存。
- 永久代、元空间二者并不只是名字变了,内部结构也调整了。
- 根据《Java虚拟机规范》的规定,如果方法区无法满足新的内存分配需求时,将抛出OOM异常。
- 现在来看,当年使用永久代,不是好的idea。导致Java程序更容易00M(超过 -XX: MaxPermSize上限)
- Java 8 中,String常量池和静态变量都在堆中。
- StringTable为什么要调整?
idk7中将StringTable放到了堆空间中。因为永久代的回收效率很低,在fu11 gc的时候才会触发。而Full gc是老年代的空间不足、永久代不足时才会触发。这就导致stringTable回收效率不高。而我们开发中会有大量的字符串被创建,回收效率低,导致永久代内存不足。放到堆里,能及时回收内存。 - 方法区是否存在GC?回收什么
- 有些人认为方法区(如HotSpot虚拟机中的元空间或者永久代)是没有垃圾收集行为的,其实不然。《Java虚拟机规范》对方法区的约束是非常宽松的,提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在(如JDK 11时期的ZGc收集器就不支持类卸载)。
- 一般来说这个区域的回收效果比较难令人满意,尤其是类型的卸载,条件相当苛刻。但是这部分区域的回收有时又确实是必要的。以前Sun公司的Bug列表中,曾出现过的若干个严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏。
- 方法区的垃圾收集主要回收两部分内容:常量池中废弃的常量和不再使用的类型。
- 先来说说方法区内常量池之中主要存放的两大类常量:字面量和符号引用。字面量比较接近Java语言层次的常量概念,如文本字符串、被声明为final的常量值等。而符号引用则属于编译原理方面的概念,包括下面三类常量:
- 类和接口的全限定名
- 字段的名称和描述符
- 方法的名称和描述符
- HotSpot虚拟机对常量池的回收策略是很明确的,只要常量池中的常量没有被任何地方引用,就可以被回收
- 先来说说方法区内常量池之中主要存放的两大类常量:字面量和符号引用。字面量比较接近Java语言层次的常量概念,如文本字符串、被声明为final的常量值等。而符号引用则属于编译原理方面的概念,包括下面三类常量: