美文网首页Jvm
JVM内存结构

JVM内存结构

作者: 漆先生 | 来源:发表于2022-03-04 23:21 被阅读0次

    原文链接:https://www.pdai.tech/md/java/jvm/java-jvm-struct.html

    image.png

    一、运行时数据区

    内存是非常重要的系统资源,是硬盘和 CPU 的中间仓库及桥梁,承载着操作系统和应用程序的实时运行。JVM 内存布局规定了 Java 在运行过程中内存申请、分配、管理的策略,保证了 JVM 的高效稳定运行。不同的 JVM 对于内存的划分方式和管理机制存在着部分差异。

    下图是 JVM 整体架构,中间部分就是 Java 虚拟机定义的各种运行时数据区域。


    image.png

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

    • 线程私有:程序计数器、虚拟机栈、本地方法栈
    • 线程共享:堆、方法区, 堆外内存(Java7的永久代或JDK8的元空间、代码缓存)

    二、程序计数器

    程序计数寄存器(Program Counter Register),JVM 中的程序计数寄存器是对物理寄存器的一种抽象模拟。程序计数寄存器是一块较小的内存空间,可以看作是当前线程所执行的字节码的行号指示器

    1.作用

    计数器用来存储指向下一条指令的地址,即将要执行的指令代码。由执行引擎读取下一条指令。

    • 通过进入class文件所在目录,命令javap -v xx.class反解析出,查看当前类的汇编指令。
    • 给ide安转jclasslib插件,进行查看


      image.png

    2.总结

    • 它是一块很小的内存空间,几乎可以忽略不计。也是运行速度最快的存储区域。
    • 在 JVM 规范中,每个线程都有它自己的程序计数器,是线程私有的,生命周期与线程的生命周期一致。
    • 任何时间一个线程都只有一个方法在执行,也就是所谓的当前方法。如果当前线程正在执行的是 Java 方法,程序计数器记录的是 JVM 字节码指令地址,如果是执行 native 方法,则是未指定值(undefined)。
    • 它是程序控制流的指示器,分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
    • 字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。
    • 它是唯一一个在 JVM 规范中没有规定任何 OutOfMemoryError 情况的区域

    3.使用PC寄存器存储字节码指令地址有什么用呢?

    因为CPU需要不停的切换各个线程,这时候切换回来以后,就得知道接着从哪开始继续执行。

    4.PC寄存器为什么会被设定为线程私有的?

    多线程在一个特定的时间段内只会执行其中某一个线程方法,CPU会不停的做任务切换,这样必然会导致经常中断或恢复。为了能够准确的记录各个线程正在执行的当前字节码指令地址,所以为每个线程都分配了一个程序计数寄存器,每个线程都独立计算,不会互相影响。

    二、虚拟机栈

    1.概述

    Java 虚拟机栈(Java Virtual Machine Stacks),早期也叫 Java 栈。每个线程在创建的时候都会创建一个虚拟机栈,其内部保存一个个的栈帧(Stack Frame),对应着一次次 Java 方法调用,是线程私有的,生命周期和线程一致。

    作用

    主管 Java 程序的运行,它保存方法的局部变量、部分结果,并参与方法的调用和返回。

    特点
    • 栈是一种快速有效的分配存储方式,访问速度仅次于程序计数器
    • JVM 直接对虚拟机栈的操作只有两个:每个方法执行,伴随着入栈(进栈/压栈),方法执行结束出栈
    • 栈不存在垃圾回收问题
    栈中可能出现的异常:

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

    • 如果采用固定大小的 Java 虚拟机栈,那每个线程的 Java 虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过 Java 虚拟机栈允许的最大容量,Java 虚拟机将会抛出一个 StackOverflowError 异常
    • 如果 Java 虚拟机栈可以动态扩展,并且在尝试扩展的时候无法申请到足够的内存,或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈,那 Java 虚拟机将会抛出一个OutOfMemoryError异常

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

    2.栈的存储单位

    • 每个线程都有自己的栈,栈中的数据都是以栈帧(Stack Frame)的格式存在
    • 在这个线程上正在执行的每个方法都各自有对应的一个栈帧
    • 栈帧是一个内存区块,是一个数据集,维系着方法执行过程中的各种数据信息

    3.栈运行原理

    • JVM 直接对 Java 栈的操作只有两个,对栈帧的压栈出栈,遵循“先进后出/后进先出”原则
    • 在一条活动线程中,一个时间点上,只会有一个活动的栈帧,这个栈帧被称为当前栈帧(Current Frame),与当前栈帧对应的方法就是当前方法(Current Method),定义这个方法的类就是当前类(Current Class)
    • 执行引擎运行的所有字节码指令只针对当前栈帧进行操作
    • 如果在该方法中调用了其他方法,对应的新的栈帧会被创建出来,放在栈的顶端,称为新的当前栈帧
    • 不同线程中所包含的栈帧是不允许存在相互引用的,即不可能在一个栈帧中引用另外一个线程的栈帧
    • 如果当前方法调用了其他方法,方法返回之际,当前栈帧会传回此方法的执行结果给前一个栈帧,接着,虚拟机会丢弃当前栈帧,使得前一个栈帧重新成为当前栈帧
    • Java 方法有两种返回函数的方式,一种是正常的函数返回,使用 return 指令,另一种是抛出异常,不管用哪种方式,都会导致栈帧被弹出

    4.栈帧的内部结构

    每个栈帧(Stack Frame)中存储着:

    • 局部变量表(Local Variables)
    • 操作数栈(Operand Stack)(或称为表达式栈)
    • 动态链接(Dynamic Linking):指向运行时常量池的方法引用
    • 方法返回地址(Return Address):方法正常退出或异常退出的地址
    • 一些附加信息

    三、本地方法栈

    1.本地方法接口

    一个 Native Method 就是一个 Java 调用非 Java 代码的接口
    要使用本地方法的原因:

    • 与java环境外交互:有时 Java 应用需要与 Java 外面的环境交互,这就是本地方法存在的原因
    • 与操作系统的交互:JVM 支持 Java 语言本身和运行时库,但是有时仍需要依赖一些底层系统的支持。通过本地方法,我们可以实现用 Java 与实现了 jre 的底层系统交互, JVM 的一些部分就是 C 语言写的。

    2.本地方法栈(Native Method Stack)

    • Java 虚拟机栈用于管理 Java 方法的调用,而本地方法栈用于管理本地方法的调用
    • 本地方法栈也是线程私有的
    • 允许线程固定或者可动态扩展的内存大小
    • 本地方法是使用 C 语言实现的
    • 它的具体做法是 Native Method Stack 中登记 native 方法,在 Execution Engine 执行时加载本地方法库,当某个线程调用一个本地方法时,它就进入了一个全新的并且不再受虚拟机限制的世界。它和虚拟机拥有同样的权限。
    • 本地方法可以通过本地方法接口来访问虚拟机内部的运行时数据区,它甚至可以直接使用本地处理器中的寄存器,直接从本地内存的堆中分配任意数量的内存
    • 并不是所有 JVM 都支持本地方法。因为 Java 虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构等。如果 JVM 产品不打算支持 native 方法,也可以无需实现本地方法栈
    • 在 Hotspot JVM 中,直接将本地方法栈和虚拟机栈合二为一

    四、堆内存

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

    1.内存划分

    对于大多数应用,Java 堆是 Java 虚拟机管理的内存中最大的一块,被所有线程共享。此内存区域的唯一目的就是存放对象实例,几乎所有的对象实例以及数据都在这里分配内存。

    为了进行高效的垃圾回收,虚拟机把堆内存逻辑上划分成三块区域:

    • 新生带(年轻代):新对象和没达到一定年龄的对象都在新生代
    • 老年代(养老区):被长时间使用的对象,老年代的内存空间应该要比年轻代更大
    • 元空间(JDK1.8 之前叫永久代):像一些方法中的操作临时对象等,JDK1.8 之前是占用 JVM 内存,JDK1.8 之后直接使用物理内存
    image.png
    Java 虚拟机规范规定,Java 堆可以是处于物理上不连续的内存空间中,只要逻辑上是连续的即可,像磁盘空间一样。实现时,既可以是固定大小,也可以是可扩展的,主流虚拟机都是可扩展的(通过 -Xmx-Xms 控制),如果堆中没有完成实例分配,并且堆无法再扩展时,就会抛出 OutOfMemoryError 异常。
    年轻带(Young Generation)

    年轻代是所有新对象创建的地方。当填充年轻代时,执行垃圾收集。这种垃圾收集称为 Minor GC。年轻一代被分为三个部分——伊甸园(Eden Memory)和两个幸存区(Survivor Memory,被称为from/to或s0/s1),默认比例是8:1:1

    • 大多数新创建的对象都位于 Eden 内存空间中
    • 当 Eden 空间被对象填充满时,执行Minor GC,并将所有幸存者对象移动到一个幸存者空间中
    • Minor GC 检查幸存者对象,并将它们移动到另一个幸存者空间。所以每次,一个幸存者空间总是空的
    • 经过多次 GC 循环后存活下来的对象被移动到老年代。通常,这是通过设置年轻一代对象的年龄阈值来实现的,然后他们才有资格提升到老一代
    老年代(Old Generation)

    旧的一代内存包含那些经过许多轮小型 GC 后仍然存活的对象。通常,垃圾收集是在老年代内存满时执行的。老年代垃圾收集称为 主GC(Major GC),通常需要更长的时间。

    大对象直接进入老年代(大对象是指需要大量连续内存空间的对象)。这样做的目的是避免在 Eden 区和两个Survivor 区之间发生大量的内存拷贝


    image.png
    元空间

    不管是 JDK8 之前的永久代,还是 JDK8 及以后的元空间,都可以看作是 Java 虚拟机规范中方法区的实现。

    设置堆内存大小和OOM

    Java 堆用于存储 Java 对象实例,那么堆的大小在 JVM 启动的时候就确定了,我们可以通过 -Xmx 和 -Xms 来设定。

    • -Xms 用来表示堆的起始内存,等价于 -XX:InitialHeapSize
    • -Xmx 用来表示堆的最大内存,等价于 -XX:MaxHeapSize

    如果堆的内存大小超过 -Xmx 设定的最大内存, 就会抛出 OutOfMemoryError 异常。
    我们通常会将 -Xmx-Xms 两个参数配置为相同的值,其目的是为了能够在垃圾回收机制清理完堆区后不再需要重新分隔计算堆的大小,从而提高性能。

    • 默认情况下,初始堆内存大小为:电脑内存大小/64
    • 默认情况下,最大堆内存大小为:电脑内存大小/4

    代码查看堆内存大小,以下是kotlin代码:

            //查看jvm大小
            //返回 JVM 堆大小
            val initalMemory = Runtime.getRuntime().totalMemory() / 1024 / 1024
            System.out.println("MainActivity:" + initalMemory)
            //返回 JVM 堆的最大内存
            val maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024
            System.out.println("MainActivity:" + maxMemory)
    
    查看 JVM 堆内存分配
    1. 在默认不配置 JVM 堆内存大小的情况下,JVM 根据默认值来配置当前内存大小
    2. 默认情况下新生代和老年代的比例是 1:2,可以通过 –XX:NewRatio 来配置.
      新生代中的 Eden:From Survivor:To Survivor 的比例是 8:1:1,可以通过 -XX:SurvivorRatio 来配置
    3. 若在 JDK 7 中开启了 -XX:+UseAdaptiveSizePolicy,JVM 会动态调整 JVM 堆中各个区域的大小以及进入老年代的年龄。
      此时 –XX:NewRatio-XX:SurvivorRatio 将会失效,而 JDK 8 是默认开启-XX:+UseAdaptiveSizePolicy
      在 JDK 8中,不要随意关闭-XX:+UseAdaptiveSizePolicy,除非对堆内存的划分有明确的规划

    每次 GC 后都会重新计算 Eden、From Survivor、To Survivor 的大小。计算依据是GC过程中统计的GC时间、吞吐量、内存占用量。

    2.对象在堆中的声明周期

    • 在 JVM 内存模型的堆中,堆被划分为新生代和老年代
      • 新生代又被进一步划分为 Eden区Survivor区,Survivor 区由 From SurvivorTo Survivor 组成
    • 当创建一个对象时,对象会被优先分配到新生代的 Eden 区
      • 此时 JVM 会给对象定义一个对象年轻计数器-XX:MaxTenuringThreshold
    • 当 Eden 空间不足时,JVM 将执行新生代的垃圾回收(Minor GC)
      • JVM 会把存活的对象转移到 Survivor 中,并且对象年龄 +1
      • 对象在 Survivor 中同样也会经历 Minor GC,每经历一次 Minor GC,对象年龄都会+1
    • 如果分配的对象超过了-XX:PetenureSizeThreshold,对象会直接被分配到老年代

    3.对象的分配过程

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

    1. new 的对象先放在伊甸园区,此区有大小限制
    2. 当伊甸园的空间填满时,程序又需要创建对象,JVM 的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC),将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区
    3. 然后将伊甸园中的剩余对象移动到幸存者 0 区
    4. 如果再次触发垃圾回收,此时上次幸存下来的放到0 区的幸存者 ,如果没有回收,就会放到幸存者1 区
    5. 如果再次经历垃圾回收且没被回收,此时会重新放回幸存者 0 区,如此循环
    6. 什么时候才会去养老区呢? 默认是 15 次回收标记
    7. 在养老区,相对悠闲。当养老区内存不足时,再次触发 Major GC,进行养老区的内存清理
    8. 若养老区执行了 Major GC 之后发现依然无法进行对象的保存,就会产生 OOM 异常

    4.GC垃圾回收简介

    JVM 在进行 GC 时,并非每次都对堆内存(新生代、老年代;方法区)区域一起回收的,大部分时候回收的都是指新生代。
    针对 HotSpot VM 的实现,它里面的 GC 按照回收区域又分为两大类:部分收集(Partial GC),整堆收集(Full GC)

    • 部分收集:不是完整收集整个 Java 堆的垃圾收集。其中又分为:
      1. 新生代收集(Minor GC/Young GC):只是新生代的垃圾收集
      2. 老年代收集(Major GC/Old GC):只是老年代的垃圾收集
        • 目前,只有 CMS GC 会有单独收集老年代的行为
        • 很多时候 Major GC 会和 Full GC 混合使用,需要具体分辨是老年代回收还是整堆回收
      3. 混合收集(Mixed GC):收集整个新生代以及部分老年代的垃圾收集
        • 目前只有 G1 GC 会有这种行为
    • 整堆收集(Full GC):收集整个 Java 堆和方法区的垃圾

    5.TLAB

    什么是 TLAB (Thread Local Allocation Buffer)?
    • 从内存模型而不是垃圾回收的角度,对 Eden 区域继续进行划分,JVM 为每个线程分配了一个私有缓存区域,它包含在 Eden 空间内
    • 多线程同时分配内存时,使用 TLAB 可以避免一系列的线程安全问题,同时还能提升内存分配的吞吐量,因此我们可以将这种内存分配方式称为快速分配策略
    • OpenJDK 衍生出来的 JVM 大都提供了 TLAB 设计
    为什么要有 TLAB ?
    • 堆区是线程共享的,任何线程都可以访问到堆区中的共享数据
    • 由于对象实例的创建在 JVM 中非常频繁,因此在并发环境下从堆区中划分内存空间是线程不安全的
    • 为避免多个线程操作同一地址,需要使用加锁等机制,进而影响分配速度

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

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

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

    逃逸分析

    逃逸分析(Escape Analysis)是目前 Java 虚拟机中比较前沿的优化技术。这是一种可以有效减少 Java 程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。通过逃逸分析,Java Hotspot 编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。

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

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

    示例如下:

    //例子1
    public static StringBuffer craeteStringBuffer1(String s1, String s2) {
        StringBuffer sb = new StringBuffer();
        sb.append(s1);
        sb.append(s2);
        return sb;
    }
    //例子2
    public static String createStringBuffer2(String s1, String s2) {
        StringBuffer sb = new StringBuffer();
        sb.append(s1);
        sb.append(s2);
        return sb.toString();
    }
    

    例子1中,StringBuffer sb是一个方法内部变量,上述代码中直接将sb返回,这样这个 StringBuffer 有可能被其他方法所改变,这样它的作用域就不只是在方法内部,虽然它是一个局部变量,称其逃逸到了方法外部。甚至还有可能被外部线程访问到,譬如赋值给类变量或可以在其他线程中访问的实例变量,称为线程逃逸。
    例子2中,不直接返回 StringBuffer,那么 StringBuffer 将不会逃逸出方法。

    参数设置

    • 在 JDK 6u23 版本之后,HotSpot 中默认就已经开启了逃逸分析
    • 如果使用较早版本,可以通过-XX"+DoEscapeAnalysis显式开启

    开发中使用局部变量,就不要在方法外定义。

    使用逃逸分析,编译器可以对代码做优化:

    • 栈上分配:将堆分配转化为栈分配。如果一个对象在子程序中被分配,要使指向该对象的指针永远不会逃逸,对象可能是栈分配的候选,而不是堆分配
    • 同步省略:如果一个对象被发现只能从一个线程被访问到,那么对于这个对象的操作可以不考虑同步
    • 分离对象或标量替换:有的对象可能不需要作为一个连续的内存结构存在也可以被访问到,那么对象的部分(或全部)可以不存储在内存,而存储在 CPU 寄存器

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

    常见栈上分配的场景:成员变量赋值、方法返回值、实例引用传递

    代码优化之栈上分配
    我们通过 JVM 内存分配可以知道 JAVA 中的对象都是在堆上进行分配,当对象没有被引用的时候,需要依靠 GC 进行回收内存,如果对象数量较多的时候,会给 GC 带来较大压力,也间接影响了应用的性能。为了减少临时对象在堆内分配的数量,JVM 通过逃逸分析确定该对象不会被外部访问。那就通过标量替换将该对象分解在栈上分配内存,这样该对象所占用的内存空间就可以随栈帧出栈而销毁,就减轻了垃圾回收的压力。

    代码优化之同步省略(消除)

    • 线程同步的代价是相当高的,同步的后果是降低并发性和性能
    • 在动态编译同步块的时候,JIT 编译器可以借助逃逸分析来判断同步块所使用的锁对象是否能够被一个线程访问而没有被发布到其他线程。如果没有,那么 JIT 编译器在编译这个同步块的时候就会取消对这个代码的同步。这样就能大大提高并发性和性能。这个取消同步的过程就叫做同步省略,也叫锁消除
    public void keep() {
        Object keeper = new Object();
        synchronized(keeper) {
            System.out.println(keeper);
        }
    }
    

    如上代码,代码中对 keeper 这个对象进行加锁,但是 keeper 对象的生命周期只在 keep()方法中,并不会被其他线程所访问到,所以在 JIT编译阶段就会被优化掉。优化成:

    public void keep() {
        Object keeper = new Object();
        System.out.println(keeper);
    }
    

    代码优化之标量替换
    标量(Scalar)是指一个无法再分解成更小的数据的数据。Java 中的原始数据类型就是标量。
    相对的,那些的还可以分解的数据叫做聚合量(Aggregate),Java 中的对象就是聚合量,因为其还可以分解成其他聚合量和标量。
    在 JIT 阶段,通过逃逸分析确定该对象不会被外部访问,并且对象可以被进一步分解时,JVM 不会创建该对象,而会将该对象成员变量分解若干个被这个方法使用的成员变量所代替。这些代替的成员变量在栈帧或寄存器上分配空间。这个过程就是标量替换
    通过 -XX:+EliminateAllocations 可以开启标量替换,-XX:+PrintEliminateAllocations 查看标量替换情况。

    
    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;
    }
    

    以上代码中,point 对象并没有逃逸出 alloc() 方法,并且 point 对象是可以拆解成标量的。那么,JIT 就不会直接创建 Point 对象,而是直接使用两个标量 int x ,int y 来替代 Point 对象。

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

    总结
    虽然经过逃逸分析可以做标量替换、栈上分配、同步省略。但是逃逸分析自身也是需要进行一系列复杂的分析的,这其实也是一个相对耗时的过程。

    一个极端的例子,就是经过逃逸分析之后,发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。

    虽然这项技术并不十分成熟,但是他也是即时编译器优化技术中一个十分重要的手段。

    五、方法区

    • 方法区(Method Area)与 Java 堆一样,是所有线程共享的内存区域。
    • 虽然 Java 虚拟机规范把方法区描述为堆的一个逻辑部分,但是它却有一个别名叫 Non-Heap(非堆),目的应该是与 Java 堆区分开。
    • 运行时常量池(Runtime Constant Pool)是方法区的一部分。Class 文件中除了有类的版本/字段/方法/接口等描述信息外,还有一项信息是常量池(Constant Pool Table),用于存放编译期生成的各种字面量和符号引用,这部分内容将类在加载后进入方法区的运行时常量池中存放。运行期间也可能将新的常量放入池中,这种特性被开发人员利用得比较多
    • 方法区的大小和堆空间一样,可以选择固定大小也可选择可扩展,方法区的大小决定了系统可以放多少个类,如果系统类太多,导致方法区溢出,虚拟机同样会抛出内存溢出错误
    • JVM 关闭后方法区即被释放

    1.解惑

    • 方法区(method area)只是 JVM 规范中定义的一个概念,用于存储类信息、常量池、静态变量、JIT编译后的代码等数据,并没有规定如何去实现它,不同的厂商有不同的实现。而永久代(PermGen)Hotspot 虚拟机特有的概念, Java8 的时候又被元空间取代了,永久代和元空间都可以理解为方法区的落地实现。
    • 永久代物理是堆的一部分,和新生代,老年代地址是连续的(受垃圾回收器管理),而元空间存在于本地内存(我们常说的堆外内存,不受垃圾回收器管理),这样就不受 JVM 限制了,也比较难发生OOM(都会有溢出异常)
    • Java7 中我们通过-XX:PermSize-xx:MaxPermSize 来设置永久代参数,Java8 之后,随着永久代的取消,这些参数也就随之失效了,改为通过-XX:MetaspaceSize-XX:MaxMetaspaceSize 用来设置元空间参数
    • 存储内容不同,元空间存储类的元信息,静态变量和常量池等并入堆中。相当于永久代的数据被分到了堆和元空间中
    • 如果方法区域中的内存不能用于满足分配请求,则 Java 虚拟机抛出 OutOfMemoryError
    • JVM 规范说方法区在逻辑上是堆的一部分,但目前实际上是与 Java 堆分开的(Non-Heap)

    对于方法区,jdk8之后的变化:

    • 移除了永久代(PermGen),替换为元空间(Metaspace);
    • 永久代中的 class metadata 转移到了 native memory(本地内存,而不是虚拟机);
    • 永久代中的 interned Strings 和 class static variables 转移到了 Java heap;
    • 永久代参数 (PermSize MaxPermSize) -> 元空间参数(MetaspaceSize MaxMetaspaceSize)

    2.设置方法区内存的大小

    • 元数据区大小可以使用参数 -XX:MetaspaceSize-XX:MaxMetaspaceSize 指定,替代上述原有的两个参数
    • 默认值依赖于平台。Windows 下,-XX:MetaspaceSize 是 21M,-XX:MaxMetaspacaSize 的值是 -1,即没有限制
    • 与永久代不同,如果不指定大小,默认情况下,虚拟机会耗尽所有的可用系统内存。如果元数据发生溢出,虚拟机一样会抛出异常 OutOfMemoryError:Metaspace
    • -XX:MetaspaceSize :设置初始的元空间大小。对于一个 64 位的服务器端 JVM 来说,其默认的 -XX:MetaspaceSize 的值为20.75MB,这就是初始的高水位线,一旦触及这个水位线,Full GC 将会被触发并卸载没用的类(即这些类对应的类加载器不再存活),然后这个高水位线将会重置,新的高水位线的值取决于 GC 后释放了多少元空间。如果释放的空间不足,那么在不超过 MaxMetaspaceSize时,适当提高该值。如果释放空间过多,则适当降低该值
    • 如果初始化的高水位线设置过低,上述高水位线调整情况会发生很多次,通过垃圾回收的日志可观察到 Full GC 多次调用。为了避免频繁 GC,建议将 -XX:MetaspaceSize 设置为一个相对较高的值。

    3.方法区内部结构

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

    类型信息

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

    • 这个类型的完整有效名称(全名=包名.类名)
    • 这个类型直接父类的完整有效名(对于 interface或是 java.lang.Object,都没有父类)
    • 这个类型的修饰符(public,abstract,final 的某个子集)
    • 这个类型直接接口的一个有序列表
    域(Field)信息
    • JVM 必须在方法区中保存类型的所有域的相关信息以及域的声明顺序
    • 域的相关信息包括:域名称、域类型、域修饰符(public、private、protected、static、final、volatile、transient 的某个子集)
    方法(Method)信息

    JVM 必须保存所有方法的

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

    运行时常量池

    运行时常量池(Runtime Constant Pool)是方法区的一部分,理解运行时常量池的话,我们先来说说字节码文件(Class 文件)中的常量池(常量池表)

    为什么要用到常量池

    一个 Java 源文件中的类、接口,编译后产生一个字节码文件。而 Java 中的字节码需要数据支持,通常这种数据会很大以至于不能直接存到字节码里,换另一种方式,可以存到常量池,这个字节码包含了指向常量池的引用。在动态链接的时候用到的就是运行时常量池。
    常量池可以看作是一张表,虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等类型。

    运行时常量池
    • 在加载类和结构到虚拟机后,就会创建对应的运行时常量池
    • 常量池表(Constant Pool Table)是 Class 文件的一部分,用于存储编译期生成的各种字面量和符号引用,这部分内容将在类加载后存放到方法区的运行时常量池中
    • JVM 为每个已加载的类型(类或接口)都维护一个常量池。池中的数据项像数组项一样,是通过索引访问的
    • 运行时常量池中包含各种不同的常量,包括编译器就已经明确的数值字面量,也包括到运行期解析后才能够获得的方法或字段引用。此时不再是常量池中的符号地址了,这里换为真实地址
      1. 运行时常量池,相对于 Class 文件常量池的另一个重要特征是:动态性,Java 语言并不要求常量一定只有编译期间才能产生,运行期间也可以将新的常量放入池中,String 类的 intern() 方法就是这样的
    • 当创建类或接口的运行时常量池时,如果构造运行时常量池所需的内存空间超过了方法区所能提供的最大值,则 JVM 会抛出 OutOfMemoryError 异常。

    4.方法区再JDK6、7、8中的演进细节

    只有 HotSpot 才有永久代的概念


    image.png
    移除永久代的原因
    • 为永久代设置空间大小是很难确定的。
    • 对永久代进行调优较困难

    5.方法区的垃圾回收

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

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

    • 类和接口的全限定名
    • 字段的名称和描述符
    • 方法的名称和描述符

    HotSpot 虚拟机对常量池的回收策略是很明确的,只要常量池中的常量没有被任何地方引用,就可以被回收
    判定一个类型是否属于“不再被使用的类”,需要同时满足三个条件:

    • 该类所有的实例都已经被回收,也就是 Java 堆中不存在该类及其任何派生子类的实例
    • 加载该类的类加载器已经被回收,这个条件除非是经过精心设计的可替换类加载器的场景,如 OSGi、JSP 的重加载等,否则通常很难达成
    • 该类对应的 java.lang.Class 对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法

    Java 虚拟机被允许堆满足上述三个条件的无用类进行回收,这里说的仅仅是“被允许”,而并不是和对象一样,不使用了就必然会回收。是否对类进行回收,HotSpot 虚拟机提供了 -Xnoclassgc 参数进行控制,还可以使用 -verbose:class 以及 -XX:+TraceClassLoading-XX:+TraceClassUnLoading 查看类加载和卸载信息。

    相关文章

      网友评论

        本文标题:JVM内存结构

        本文链接:https://www.haomeiwen.com/subject/leiurrtx.html