JVM--L2运行时数据区

一、运行时数据区

• Java虚拟机定义了若干种程序运行期间会使用到的运行时数据区。其中有一些会随着虚拟机启动而创建，随着虚拟机的退出而销毁。另外一些数据区域与线程一一对应，会随着线程开始和结束而创建和销毁。
• 灰色的为单独线程私有的，红色的为多个线程共享的。即：
  • 线程独有：独立包括程序计数器、栈、本地方法栈
  • 线程间共享：堆、方法区（jdk7和以前的版本使用的是堆上的永久代实现的方法区，而在jdk8及以后使用的是元数据区实现方法区）
• 每个JVM只有一个Runtime实例，即为运行时环境
• 在HotspotJVM里，每个线程都与操作系统的本地线程直接映射。当一个Java线程准备好执行以后，一个操作系统的本地线程也同时创建。Java线程执行终止后，本地线程也会回收。操作系统负责将线程安排调度到任何一个可用的CPU上，一旦本地线程初始化成功，它就会调用Java线程中的run()方法

二、程序计数器（ProgramCounterRegister）

• Register的命名源于CPU的寄存器，寄存器存储指令相关的现场信息，CPU只有把数据装载到寄存器才能够运行。JVM中的PC寄存器是对物理PC寄存器的一种抽象模拟，它是一块很小的内存空间，几乎可以忽略不记。也是运行速度最快的存储区域。
• 在JVM规范中，每个线程都有它自己的程序计数器，是线程私有的，生命周期与线程的生命周期保持一致。
• 任何时间一个线程都只有一个方法在执行，也就是所谓的当前方法。程序计数器会存储当前线程正在执行的Java方法的JVM指令地址；或者，如果是在执行native方法，则是未指定值（undefined）。它是程序控制流的指示器，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
• 它是唯一一个在Java虚拟机规范中没有规定任何OutofMemoryError情况的区域。
• PC寄存器用来存储指向下一条指令的地址，也就是即将要执行的指令代码。由执行引擎读取下一条指令，并执行该指令
  

三、虚拟机栈

• 由于跨平台性的设计，Java的指令都是根据栈来设计的。优点是跨平台，指令集小，编译器容易实现，缺点是性能下降，实现同样的功能需要更多的指令。
• 虚拟机栈是一种快速有效的分配存储方式，访问速度仅次于程序计数器。

  • 栈中的数据都是以栈帧（StackFrame）为基本单位存储的，虚拟机栈对应线程上正在执行的每个方法都对应一个栈帧

    • 一个方法的执行对应一个栈帧的入栈，一个方法的执行结束对应一个栈帧的出栈
    • Java方法有两种返回函数的方式（一种是正常的函数返回，另外一种是抛出异常），但不管使用哪种方式，都会导致栈帧被弹出

  • 对于虚拟机栈来说不存在GC问题

• 栈中可能出现的异常
  • 对于固定大小的虚拟机栈，如果线程请求分配的栈容量超过虚拟机栈允许的最大容量，会抛出StackoverflowError异常。
  • 如果虚拟机栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够内存去创建对应的虚拟机栈，会抛出OutOfMemoryError异常。
• 我们可以使用参数-Xss选项来设置线程的最大栈空间，栈的大小直接决定了函数调用的最大可达深度。
  • -Xss1024m //栈内存为1024MBS
  • -Xss1024k //栈内存为1024KB
• 栈帧内部结构

3.1 局部变量表

• 局部变量表是一个数字数组，用于存储方法参数和定义在方法体内的局部变量，这些数据类型包括基本数据类型、对象引用（reference），以及returnAddress(返回值)类型。

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

• 局部变量表中的变量只在当前方法调用中有效，且必须人为地初始化，否则无法使用

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

• 局部变量表，最基本的存储单元是Slot（变量槽），JVM会为局部变量表中的每一个Slot都分配一个访问索引，通过这个索引即可成功访问到局部变量表中指定的局部变量值，当方法被调用的时候，它的方法参数和方法体内部定义的局部变量将会按照顺序被复制到局部变量表中的每一个slot上

• 32位以内的类型只占用一个slot（包括引用类型、returnAddress类型），64位的类型（long和double）占用两个slot

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

• Slot的重复利用：

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

3.2 操作数栈（OperandStack）

• 每一个独立的栈帧除了包含局部变量表以外，还包含一个后进先出（Last-In-First-Out）的操作数栈。在方法执行过程中，根据字节码指令，往栈中写入数据或提取数据，即入栈（push）和出栈（pop）

• 某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈，比如：执行复制、交换、求和等操作

• 每一个操作数栈都会拥有一个明确的栈深度用于存储数值（32bit的类型占用一个栈单位深度，64bit的类型占用两个栈单位深度），其所需的最大深度在编译期就定义好了，保存在方法的Code属性中

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

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

• 栈顶缓存技术：

  • 基于栈式架构的虚拟机所使用的零地址指令更加紧凑，但完成一项操作的时候必然需要使用更多的入栈和出栈指令，这同时也就意味着将需要更多的指令分派次数和内存读/写次数。
  • 由于操作数是存储在内存中的，因此频繁地执行内存读/写操作必然会影响执行速度。为了解决这个问题，HotSpotJVM的设计者们提出了栈顶缓存技术，将栈顶元素全部缓存在物理CPU的寄存器中，以此降低对内存的读/写次数，提升执行引擎的执行效率。

3.3 动态链接（DynamicLinking）

• 每一个栈帧内部都包含一个指向运行时常量池中该栈帧所属方法的引用，包含这个引用的目的就是为了支持当前方法的代码能够实现动态链接，比如：invokedynamic指令
• 一个方法调用了另外的其他方法时，就是通过常量池中指向方法的符号引用来表示的，那么动态链接的作用就是为了将这些符号引用转换为调用方法的直接引用

3.3.1 方法的绑定机制

• 在JVM中，将符号引用转换为调用方法的直接引用与方法的绑定机制相关
  • 静态链接：当一个字节码文件被装载进JVM内部时，如果被调用的目标方法在编译期确定，且运行期保持不变时，这种情况下将调用方法的符号引用转换为直接引用的过程称之为静态链接
  • 动态链接：如果被调用的方法在编译期无法被确定下来，也就是说，只能够在程序运行期将调用的方法的符号转换为直接引用，由于这种引用转换过程具备动态性，因此也被称之为动态链接。
• 静态链接和动态链接对应的方法的绑定机制为：早期绑定（EarlyBinding）和晚期绑定（LateBinding）。绑定是一个字段、方法或者类在符号引用被替换为直接引用的过程。

3.3.2 虚方法和非虚方法

• 如果方法在编译期就确定了具体的调用版本，这个版本在运行时是不可变的。这样的方法称为非虚方法。
  • 静态方法、私有方法、final方法、实例构造器都是非虚方法。非虚方法的调用指令包括：
    • invokestatic：调用静态方法，解析阶段确定唯一方法版
    • invokespecial：调用方法、私有及父类方法，解析阶段确定唯一方法版本
  • 其他方法称为虚方法。虚方法的调用指令包括：
    • invokevirtual：调用所有虚方法
    • invokeinterface：调用接口方法
    • invokedynamic：动态解析出需要调用的方法，然后执行

3.3.3 invokedynamic指令

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

• 但是在Java7中并没有提供直接生成invokedynamic指令的方法，直到Java8的Lambda表达式的出现，invokedynamic指令在Java中才有了直接的生成方式。

• 动态类型语言和静态类型语言：
  

  • 动态类型语言和静态类型语言两者的区别就在于对类型的检查是在编译期还是在运行期，满足前者就是静态类型语言，反之是动态类型语言
  • 静态类型语言是判断变量自身的类型信息，动态类型语言是判断变量值的类型信息。变量没有类型信息，变量值才有类型信息，这是动态语言的一个重要特征。

3.3.4 虚方法表

• 方法重写的本质：

  • 如果在类型C中找到与常量中的描述符合简单名称都相符的方法，则进行访问权限校验，如果通过则返回这个方法的直接引用，查找过程结束，如果不通过，则返回java.lang.IllegalAccessError异常
  • 否则，按照继承关系从下往上依次对C的各个父类进行第2步的搜索和验证过程。
  • 如果始终没有找到合适的方法，则抛出java.lang.AbstractMethodError异常。

• 在面向对象的编程中，会很频繁的使用到动态分派，如果在每次动态分派的过程中都要重新在类的方法元数据中搜索合适的目标的话就可能影响到执行效率。

  • 为了提高性能，JVM采用在类的方法区建立一个虚方法表来实现（非虚方法不会出现在表中），使用索引表来代替查找。
  • 每个类中都有一个虚方法表，表中存放着各个方法的实际入口。虚方法表会在类加载的链接阶段被创建并开始初始化，类的变量初始值准备完成之后，JVM会把该类的虚方法表也初始化完毕。
  • 如果类中重写了方法，那么调用的时候，就会直接在该类的虚方法表中查找

3.4 方法返回地址

• 这块区域用于存放调用该方法的pc寄存器的值。
• 一个方法的结束，有两种方式：
  • 正常执行完成
  • 出现未处理的异常，非正常退出
• 本质上，方法的退出就是当前栈帧出栈的过程。此时，需要恢复上层方法的局部变量表、操作数栈、将返回值压入调用者栈帧的操作数栈、设置PC寄存器值等，让调用者方法继续执行下去。
• 正常完成出口和异常完成出口的区别在于：通过异常完成出口退出的不会给他的上层调用者产生任何的返回值。

四、本地方法栈

4.1 本地方法

• NativeMethod是Java调用非Java代码的接囗，该方法的实现由非Java语言实现，比如C。
• 在定义一个NativeMethod时，并不提供实现体，因为其实现体是由非java语言在外面实现的。

4.2 本地方法栈

• 本地方法栈，是线程私有的，在内存溢出方面和虚拟机栈相同。Java虚拟机栈用于管理Java方法的调用，而本地方法栈用于管理本地方法的调用。
• 本地方法一般是使用C语言实现的。它的具体做法是NativeMethodStack中登记Native方法，在ExecutionEngine执行时加载本地方法库。
• 当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限制的世界。
  • 本地方法可以通过本地方法接口来访问虚拟机内部的运行时数据区
  • 它甚至可以直接使用本地处理器中的寄存器
  • 直接从本地内存的堆中分配任意数量的内存
• Java虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构等。如果JVM产品不打算支持native方法，也可以无需实现本地方法栈。在HotspotJVM中，直接将本地方法栈和虚拟机栈合二为一。

五、堆

5.1 核心概述

• 一个进程对应一个JVM实例，一个JVM实例对应一个堆空间，进程包含多个线程，所以线程之间共享同一个堆空间
• Java堆区在JVM启动的时候即被创建，其空间大小也就确定了，堆是JVM管理的最大一块内存空间。

5.2 设置堆内存大小

• 堆的大小在JVM启动时就已经设定好了，可以通过选项"-Xms"和"-Xmx"来进行设置

  • -Xms用于表示堆区的初始内存，等价于-XX:InitialHeapSize

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

    
    

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

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

• 为什么设置600MB，算出来只有575MB
  

  • from区和to区只能有一个区存放对象，所以相加的时候只能加上一个区的大小
  • 可以看到新生区的大小=伊甸园区大小+幸存者from/to区大小

5.3 年轻代与老年代

• Java7及之前堆内存逻辑上分为三部分：新生区+养老区+永久区

• Java8及之后堆内存逻辑上分为三部分：新生区+养老区+元空间

• 堆空间逻辑上包括永久代/元空间，实际上控制不到

• 配置新生代与老年代在堆结构的占比（下面这些参数在开发中一般不会调）

  • 默认-XX:NewRatio=2，表示新生代占1，老年代占2，新生代占整个堆的1/3
  • 当发现在整个项目中，生命周期长的对象偏多，那么就可以通过调整老年代的大小，来进行调优

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

  • 可以通过选项-XX:SurvivorRatio调整这个空间比例，比如-XX:SurvivorRatio=8
  • 绝大部分的Java对象的销毁都在新生代进行了（有些大的对象在Eden区无法存储时候，将直接进入老年代）
  • 可以使用选项"-Xmn"设置新生代最大内存大小，但这个参数一般使用默认值就可以了。

  

5.4 对象的内存分配

• 创建的对象，一般都是存放在Eden区的，当我们的Eden区满了后，就会触发GC操作，一般被称为YGC/MinorGC操作

• 进行一次垃圾收集后，红色的对象将会被回收，而绿色的对象还被占用着，存放在S0(SurvivorFrom)区。经过一次回收后还存在的对象，将其年龄+1。

• Eden区继续存放对象，当Eden区再次存满的时候，又会触发一个MinorGC操作，此时GC将会把Eden和SurvivorFrom中的对象进行一次垃圾收集，把存活的对象放到SurvivorTo区（复制后有交换，谁空谁是To），同时让存活的对象年龄+1

• 当Survivor中的对象的年龄达到15（可调节）的时候，将会触发一次Promotion晋升的操作，也就是将年轻代中的对象晋升到老年代中

• 特别注意，只有Eden区满了才会触发MinorGC，幸存者区满了后不会触发MinorGC操作。如果Survivor区满了后，将会触发一些特殊的规则（可能直接晋升老年代）

• 完整的过程：

  • 一个新对象，先看Eden是否放的下
    • 如果Eden放得下，则直接放到Eden区
    • 如果Eden放不下，则触发YGC，看看还能不能放下
  • 如果Eden执行了YGC还是无法放不下该对象，只能说明是超大对象，只能直接放到老年代
  • 那万一老年代都放不下，则先触发FGC，再看看能不能放下，如果还是放不下，那只能报OOM
  • 如果Eden区满了，将对象往幸存区拷贝时，发现幸存区放不下，那么某些新对象直接晋升至老年区

5.5 分代收集

• JVM在进行GC时，并非每次都对所有内存区域一起回收的。针对Hotspot VM的实现，它里面的GC按照回收区域分为两大种类型：一种是部分收集（Partial GC），一种是整堆收集（FullGC）

  • 部分收集：不是完整收集整个Java堆的垃圾收集。其中又分为：
    • 新生代收集（ Minor GC/Young GC ）：只是新生代( Eden、S0/S1 )的垃圾收集
    • 老年代收集（ Major GC/Old GC ）：只是老年代的垃圾收集（目前，只有CMS GC会有单独收集老年代的行为）
    • 混合收集（Mixed GC）：收集整个新生代以及部分老年代的垃圾收集（目前，只有G1 GC会有这种行为）。
  • 整堆收集（Full GC）：收集整个java堆和方法区的垃圾收集。

• Young/Minor GC的触发机制：

  • 当年轻代空间不足时，就会触发Minor GC，这里的年轻代满指的是Eden区满，Survivor区满不会触发GC。
  • 因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。
  • Minor GC会引发STW，暂停其它用户的线程，等待垃圾回收线程结束，用户线程才恢复运行。

• Full GC的触发机制：（Full GC在开发或调优中要尽量避免，这样STW时间会短一些）

  • 调用System.gc( )时，系统建议执行Full GC，但是不必然执行
  • 老年代空间不足
  • 方法区空间不足
  • 通过Minor GC后进入老年代的平均大小大于老年代的可用内存
  • 由Eden区、survivor space0（From Space）区向survivor space1（To Space）区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小

• 为什么要把Java堆分代？
  
  

  • 经研究，不同对象的生命周期不同，70%-99%的对象是临时对象。
  • 不分代完全可以，分代的唯一理由就是优化GC性能。
    • 如果没有分代，GC的时候要找到哪些对象没用，需要对堆的所有区域进行扫描。
    • 而很多对象都是朝生夕死的，如果分代的话，把新创建的对象放到某一地方，当GC的时候先把这块存储“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。

5.6 内存分配策略

• 对象晋升（Promotion）规则
  • 如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并将对象年龄设为1。
  • 对象在Survivor区中每熬过一次MinorGC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁，其实每个JVM、每个GC都有所不同）时，就会被晋升到老年代
  • 晋升老年代的年龄阀值，可以通过选项-XX:MaxTenuringThreshold来设置
• 针对不同年龄段的对象分配原则如下所示：

  • 优先分配到Eden

  • 大对象直接分配到老年代：

    • 尽量避免程序中出现过多的大对象

  • 长期存活的对象分配到老年代

  • 动态对象年龄判断：

    • 如果Survivor区中相同年龄的所有对象大小的总和大于 Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

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

    • 如果大于，则此次Minor GC是安全的
    • 如果小于，则虚拟机会查看-XX:HandlePromotionFailure设置值是否允许担保失败。
      • 如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小
        • 如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的；
        • 如果小于，则进行一次Full GC。
    • 如果HandlePromotionFailure=false，则进行一次Full GC。
    • JDK6 Update 24之后的规则：只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则将进行Full GC，即HandlePromotionFailure=true

5.7 TLAB

5.7.1 TLAB概述

• 堆空间都是共享的么？
  • 不一定，有TLAB（Thread Local Allocation Buffer）这个概念，在堆中划分出一块区域，为每个线程所独占
• 堆区是线程共享区域，对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的，为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度。TLAB应运而生，其是为每个线程单独分配了一个缓冲区，它包含在Eden空间内。
• TLAB是从内存模型角度，对Eden区域的继续划分
• 使用TLAB可以避免一系列的非线程安全问题，同时还能够提升内存分配的吞吐量，因此我们可以将这种内存分配方式称之为快速分配策略。

5.7.2 TLAB的分配过程

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

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

• 随着JIT编译期的发展与逃逸分析（Escape Analysis）技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。
• 在Java虚拟机中，如果经过逃逸分析后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。这也是最常见的堆外存储技术。
• 此外，前面提到的基于OpenJDK深度定制的TaoBao VM( 淘宝虚拟机 )，其中创新的GCIH（GC invisible heap）技术实现off-heap，将生命周期较长的Java对象从heap中移至heap外，并且GC不能管理GCIH内部的Java对象，以此达到降低GC的回收频率和提升GC的回收效率的目的。

5.8.1 逃逸分析

• 逃逸分析的基本行为就是分析对象动态作用域：
  • 当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸。
  • 当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。例如作为调用参数传递到其他地方中。
• 在JDK 1.7 版本之后，HotSpot中默认就已经开启了逃逸分析。如果使用的是较早的版本，开发人员则可以通过-XX:+DoEscapeAnalysis显式开启逃逸分析
• 使用逃逸分析，编译器可以对代码做如下优化：
  • 栈上分配
  • 同步省略
  • 分离对象或标量替换

5.8.2 栈上分配

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

5.8.3 同步省略

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

• JIT编译器借助逃逸分析如果判断同步块所使用的锁对象只能够被一个线程访问而没有被发布到其他线程，就会取消对这部分代码的同步。这个取消同步的过程就叫同步省略，也叫锁消除。

• 注意：字节码文件中并没有进行优化，可以看到加锁和释放锁的操作依然存在，同步省略操作是在解释运行时发生的

5.8.4 标量替换

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

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

  class Point {
      private int x;
      private int y;
  }
  private static void alloc() {
      Point point = new Point(1,2);
      System.out.println("point.x" + point.x + ";point.y" + point.y);
  }
  //上述代码经过标量替换后就会变成
  private static void alloc() {
  int x = 1;
  int y = 2;
  System.out.println("point.x = " + x + "; point.y=" + y);
  }
  

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

5.8.5 逃逸分析的总结

• 关于逃逸分析的论文在1999年就已经发表了，但直到JDK1.6才有实现，而且这项技术到如今也并不是十分成熟的。其根本原因就是无法保证逃逸分析的性能消耗一定能高于他的消耗（需要进行一系列复杂的分析的）。
• 虽然这项技术并不十分成熟，但是它也是即时编译器优化技术中一个十分重要的手段。对象在栈上分配理论上是可行的，但是取决于JVM设计者的选择。Oracle Hotspot JVM中并未这么做，所以可以明确Hotspot中所有的对象实例都是创建在堆上。
• Oracle Hotspot JVM默认开启标量替换，但其是将对象打散成标量类型，并不是将对象在栈上分配。
• JDK7以后字符串常量池和静态变量直接在堆上分配，所以这一点同样符合前面一点的结论：对象实例都是分配在堆上。

六、方法区

6.1 栈、堆、方法区的交互

6.2 核心概述

• 《Java虚拟机规范》中明确说明：所有的方法区在逻辑上是属于堆的一部分。但是在HotSpotJVM中，方法区还有一个别名叫做Non-Heap（非堆），目的就是要和堆分开。所以，方法区可以看作是一块独立于Java堆的内存空间。
• 方法区是各个线程共享的内存区域，在JVM启动的时候被创建，关闭JVM就会释放这个区域的内存。和Java堆区一样，它的实际物理内存空间可以是不连续的，并可以选择固定大小或者可扩展。
• 多个线程同时加载统一个类时，只能有一个线程能加载该类，其他线程只能等等待该线程加载完毕，然后直接使用该类，即类只能加载一次。
• 如果系统定义了太多的类（加载大量的第三方的jar包、Tomcat部署的工程过多、大量动态的生成反射类），导致方法区溢出，虚拟机同样会抛出内存溢出错误：
  • java.lang.OutofMemoryError:PermGen space（JDK7之前）
  • java.lang.OutOfMemoryError:Metaspace（JDK8之后）
• 方法区是规范，元空间或者永久代是方法区的实现

6.3 设置方法区大小

• 方法区的大小不必是固定的，JVM可以根据应用的需要动态调整
  • jdk7之前永久代：
    • -XX:Permsize：永久代初始分配空间，默认20.75M
    • -XX:MaxPermsize：永久代最大可分配空间，默认82M
    • 当JVM加载的类信息容量超过了最大可分配空间，会抛出OutofMemoryError:PermGen space。
  • jdk8元空间：
    • 元数据区大小可以使用参数 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 指定
    • 如果元数据区发生溢出，虚拟机会抛出异常 OutOfMemoryError:Metaspace 。与永久代不同，-XX:MaxMetaspaceSize的默认值是-1，即没有限制 ，如果不指定大小，默认情况下，虚拟机会耗尽所有的可用系统内存 。
    • -XX:MetaspaceSize是初始的高水位线 ，一旦触及这个水位线，Full GC将会被触发并卸载没用的类，然后这个高水位线将会重置，新的高水位线的值取决于Full GC后释放了多少元空间。
      • 如果释放的空间不足，那么在不超过MaxMetaspaceSize的范围内，适当提高该值。
      • 如果释放空间过多，则适当降低该值。
    • 如果初始化的高水位线设置过低，上述高水位线调整情况会发生很多次（Full GC多次触发），因此建议将-XX:MetaspaceSize设置为一个相对较高 的值。
• 解决OOM：
  • 一般的手段是首先对堆转储快照 进行分析，重点是确认到底是出现了内存泄漏（Memory Leak） 还是内存溢出（Memory Overflow）
  • 内存泄漏就是有大量的对象以后不会使用了，但是还和GC ROOT有关联，导致这些对象不会被回收 。如果是内存泄漏，可进一步通过工具找到泄漏对象是通过怎样的路径与GC Roots相关联的，就可以比较准确地定位出泄漏代码的位置。
  • 内存溢出是说内存中的对象确实都还必须存活着，那就应当检查虚拟机的相关参数 ，与机器物理内存对比看是否还可以调大 ，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长 的情况，尝试减少程序运行期的内存消耗。

6.4 方法区的内部结构

6.4.1 类信息

• 类型信息
  • 对每个加载的类型（类class、接口interface、枚举enum、注解annotation），JVM必须在方法区中存储以下类型信息：
    • 这个类型的完整有效名称（全类名=包名.类名）
    • 这个类型直接父类的完整有效名（对于interface或是java.lang.Object，都没有父类）
    • 这个类型的修饰符（public，abstract，final的某个子集）
    • 这个类型直接接口的一个有序列表
  • 在运行时方法区中，类信息中记录了哪个加载器加载了该类，同时类加载器也记录了它加载了哪些类
• 域（Field）信息
  • JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。
  • 域信息通俗来讲是类的成员变量
  • 域的相关信息包括：
    • 域名称
    • 域类型
    • 域修饰符（public，private，protected，static，final，volatile，transient的某个子集）
• 方法（Method）信息
  • JVM必须保存所有方法的（包括native方法）以下信息，同域信息一样包括声明顺序：
    • 方法名称
    • 方法的返回类型（包括 void 返回类型）
    • 方法参数的数量和类型（按顺序）
    • 方法的修饰符（public，private，protected，static，final，synchronized，native，abstract的一个子集）
    • 方法的字节码、操作数栈、局部变量表及大小（abstract和native方法除外）
    • 异常表（abstract和native方法除外），异常表记录每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引

6.4.2 运行时常量池

运行时常量池存在于方法区中，常量池是字节码文件的一部分

• 常量池
  • 一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述符信息外，还包含一项信息就是常量池表，包括各种字面量和对类型、域和方法的符号引用
  • 为什么需要常量池？
    • 如果不使用常量池，就需要将当前类用到的类信息、方法信息等记录在当前的字节码文件中，造成文件臃肿。所以我们将所需用到的结构信息记录在常量池中，并通过引用的方式，来加载、调用所需的结构
  • 常量池，可以看做是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等信息
• 运行时常量池
  • 常量池表是Class字节码文件的一部分，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。运
  • JVM为每个已加载的类型（类或接口）都维护一个运行时常量池。池中的数据项像数组项一样，是通过索引访问的。
  • 加载类和接口到虚拟机后，就会创建对应的运行时常量池。
  • 运行时常量池中包含多种不同的常量，包括编译期就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或者字段引用。
  • 如果构造运行时常量池所需的内存空间超过了方法区所能提供的最大值，则JVM会抛OutOfMemoryError异常。
• 关于【符号引用 --> 直接引用】的理解
  • 调用 System.out.println( ) 方法时，首先需要看 System 类有没有加载，再看看 PrintStream 类有没有加载。如果没有加载，则执行加载，并将常量池中的符号引用转换为直接引用（真正的地址值）

6.5 方法区的演进

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

• Hotspot中方法区的变化：

  JDK版本	演变细节
  1.6及以前	有永久代（permanent generation），静态变量存储在永久代上
  1.7	有永久代，但已经逐步 “去永久代”，字符串常量池、静态变量从永久代中移除，保存在堆中
  1.8	无永久代，类型信息，字段，方法，常量保存在本地内存的元空间，但字符串常量池、静态变量仍然在堆中

  • JDK6：方法区由永久代实现，使用 JVM 虚拟机内存
  • JDK7：方法区由永久代实现，使用 JVM 虚拟机内存
  • JDK及以后：方法区由元空间实现，使用物理机本地内存

• 元空间和永久代都是对方法区的实现，最大的区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存。永久代、元空间二者并不只是名字变了，内部结构也调整了。

• 永久代为什么要被元空间替代？
  元空间的最大可分配空间就是系统可用内存空间，这项改动是很有必要的，原因有：

  • 为永久代设置空间大小是很难确定的
    • 在某些场景下，如果动态加载类过多，容易产生Perm区的OOM。
  • 对永久代进行调优是很困难的
    • 方法区的垃圾收集主要回收两部分内容：运行时常量池中废弃的常量和不再用的类型，方法区的调优主要是为了降低Full GC频率
    • 一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻。但是这部分区域的回收有时又确实是必要的。（Sun公司的很多Bug是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏）

• 字符串常量池（StringTable）为什么要调整位置？

  • 我们开发中会有大量的字符串被创建。永久代的回收效率很低，在Full GC的时候才会执行永久代的垃圾回收，这就导致StringTable回收效率不高。相比之下，放到堆里，能及时回收StringTable的内存。

• 静态变量的位置：

  • 静态变量引用的对象实体始终都在堆空间中
  • 静态变量（基本数据类型就是值本身，引用类型则是引用地址）与Java语言一端的Class对象存放在一起，存储于Java堆之中

6.6 方法区的垃圾回收

• 方法区常量的回收
  • 先方法区内常量池之中主要存放的两大类常量：字面量和符号引用
  • 只要常量池中的常量没有被任何地方引用，就可以被回收（与回收Java堆中的对象非常类似）。
• 方法区类的回收
  • 判定一个类型是否属于“不再被使用的类”的条件比较苛刻，需要同时满足下面三个条件：
    • 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例。
    • 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的。
    • 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
  • 类的回收而并不是和对象一样，没有引用了就必然会回收。关于是否要对类型进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制。
  • 在频繁自定义类加载器的场景中，通常都需要Java虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力。

七、运行时数据区总结

• 线程私有结构：程序计数器、虚拟机栈、本地方法栈
• 每个虚拟机栈由具体的栈帧组成，在栈帧的动态链接中，保存至对方法的引用
• 方法区在 JDK7 之前，使用永久代实现，在 JDK8 之后，使用元空间实现
• Minor GC 针对于新生区，Major GC 针对于老年区，Full GC针对于整个堆空间和方法区