Java虚拟机-虚拟机栈，堆，方法区

PC 寄存器（程序计数器）

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

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

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

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

字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。
它是唯一一个在 Java 虚拟机规范中没有规定任何 OutofMemoryError 情况的区域。没有垃圾回收。

PC 寄存器的作用

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

使用 PC 寄存器存储字节码指令地址有什么用呢？或者问为什么使用 PC 寄存器来记录当前线程的执行地址呢？

因为 CPU 需要不停的切换各个线程，这时候切换回来以后，就得知道接着从哪开始继续执行。
JVM 的字节码解释器就需要通过改变 PC 寄存器的值来明确下一条应该执行什么样的字节码指令。

PC 寄存器为什么被设定为私有的？

我们都知道所谓的多线程在一个特定的时间段内只会执行其中某一个线程的方法，CPU 会不停地做任务切换，这样必然导致经常中断或恢复，如何保证分毫无差呢？为了能够准确地记录各个线程正在执行的当前字节码指令地址，最好的办法自然是为每一个线程都分配一个 PC 寄存器，这样一来各个线程之间便可以进行独立计算，从而不会出现相互干扰的情况。

虚拟机栈

概述

由于跨平台性的设计，Java 的指令都是根据栈来设计的。不同平台 CPU 架构不同，所以不能设计为基于寄存器的【如果设计成基于寄存器的，耦合度高，性能会有所提升，因为可以对具体的 CPU 架构进行优化，但是跨平台性大大降低】。
优点是跨平台，指令集小，编译器容易实现，缺点是性能下降，实现同样的功能需要更多的指令。

内存中的栈与堆
首先栈是运行时的单位，而堆是存储的单位。
即：栈解决程序的运行问题，即程序如何执行，或者说如何处理数据。堆解决的是数据存储的问题，即数据怎么放，放哪里

Java 虚拟机栈是什么？
Java 虚拟机栈（Java Virtual Machine Stack），早期也叫 Java 栈。每个线程在创建时都会创建一个虚拟机栈，其内部保存一个个的栈帧（Stack Frame），对应着一次次的 Java 方法调用，栈是线程私有的

虚拟机栈的生命周期

生命周期和线程一致，也就是线程结束了，该虚拟机栈也销毁了

虚拟机栈的作用

主管 Java 程序的运行，它保存方法的局部变量（8 种基本数据类型、对象的引用地址）、部分结果，并参与方法的调用和返回。
局部变量，它是相比于成员变量来说的（或属性）
基本数据类型变量 VS 引用类型变量（类、数组、接口）

虚拟机栈的特点

栈是一种快速有效的分配存储方式，访问速度仅次于程序计数器。
JVM 直接对 Java 栈的操作只有两个：
每个方法执行，伴随着进栈（入栈、压栈）
执行结束后的出栈工作
对于栈来说不存在垃圾回收问题
栈不需要 GC，但是可能存在 OOM

虚拟机栈的异常

Java 虚拟机规范允许 Java 栈的大小是动态的或者是固定不变的。
1，如果采用固定大小的 Java 虚拟机栈，那每一个线程的 Java 虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过 Java 虚拟机栈允许的最大容量，Java 虚拟机将会抛出一个StackoverflowError 异常。
2，如果 Java 虚拟机栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈，那 Java 虚拟机将会抛出一个 OutofMemoryError 异常。
我们可以使用参数 -Xss 选项来设置线程的最大栈空间，栈的大小直接决定了函数调用的最大可达深度。

栈中存储什么？

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

栈运行原理

JVM 直接对 Java 栈的操作只有两个，就是对栈帧的压栈和出栈，遵循先进后出（后进先出）原则。
在一条活动线程中，一个时间点上，只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧（栈顶栈帧）是有效的。这个栈帧被称为当前栈帧（Current Frame），与当前栈帧相对应的方法就是当前方法（Current Method），定义这个方法的类就是当前类（Current Class）
执行引擎运行的所有字节码指令只针对当前栈帧进行操作。
如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，放在栈的顶端，成为新的当前帧。

1，不同线程中所包含的栈帧是不允许存在相互引用的，即不可能在一个栈帧之中引用另外一个线程的栈帧。
2，如果当前方法调用了其他方法，方法返回之际，当前栈帧会传回此方法的执行结果给前一个栈帧，接着，虚拟机会丢弃当前栈帧，使得前一个栈帧重新成为当前栈帧。
3，Java 方法有两种返回函数的方式。
一种是正常的函数返回，使用 return 指令。
另一种是方法执行中出现未捕获处理的异常，以抛出异常的方式结束。
但不管使用哪种方式，都会导致栈帧被弹出。

栈帧的内部结构

每个栈帧中存储着：
局部变量表（Local Variables）LV

1，局部变量表也被称之为局部变量数组或本地变量表
2，定义为一个数字数组，主要用于存储方法参数和定义在方法体内的局部变量，这些数据类型包括各类基本数据类型、对象引用（reference），以及 returnAddress 返回值类型。
3，由于局部变量表是建立在线程的栈上，是线程的私有数据，因此不存在数据安全问题
4，局部变量表所需的容量大小是在编译期确定下来的，并保存在方法的 Code 属性的 maximum local variables 数据项中。在方法运行期间是不会改变局部变量表的大小的。
5，方法嵌套调用的次数由栈的大小决定。一般来说，栈越大，方法嵌套调用次数越多。
对一个函数而言，它的参数和局部变量越多，使得局部变量表膨胀，它的栈帧就越大，以满足方法调用所需传递的信息增大的需求。
进而函数调用就会占用更多的栈空间，导致其嵌套调用次数就会减少。
6，局部变量表中的变量只在当前方法调用中有效。
在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。
当方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁。

关于 Slot 的理解
参数值的存放总是从局部变量数组索引 0 的位置开始，到数组长度-1 的索引结束。
局部变量表，最基本的存储单元是 Slot（变量槽），局部变量表中存放编译期可知的各种基本数据类型（8 种），引用类型（reference），returnAddress 类型的变量。
在局部变量表里，32 位以内的类型只占用一个 slot（包括 returnAddress 类型），64 位的类型占用两个 slot（long 和 double 8 字节）。
byte、short、char 在储存前被转换为 int，boolean 也被转换为 int，0 表示 false，非 0 表示 true
long 和 double 则占据两个 slot

JVM 会为局部变量表中的每一个 Slot 都分配一个访问索引，通过这个索引即可成功访问到局部变量表中指定的局部变量值
当一个实例方法被调用的时候，它的方法参数和方法体内部定义的局部变量将会按照顺序被复制到局部变量表中的每一个 slot 上
如果需要访问局部变量表中一个 64bit 的局部变量值时，只需要使用前一个索引即可。（比如：访问 long 或 double 类型变量）
如果当前帧是由构造方法或者实例方法创建的，那么该对象引用 this 将会存放在 index 为 0 的 slot 处，其余的参数按照参数表顺序继续排列。（this 也相当于一个变量）
静态方法中不可使用 this，因为 this 方法变量不存在与当前方法的局部变量表中。

变量的分类：

1、按照数据类型分：① 基本数据类型 ② 引用数据类型
2、按照在类中声明的位置分：
2-1、成员变量：在使用前，都经历过默认初始化赋值
2-1-1、类变量: linking 的 prepare 阶段：给类变量默认赋值
—> initial 阶段：给类变量显式赋值即静态代码块赋值
2-1-2、实例变量：随着对象的创建，会在堆空间中分配实例变量空间，并进行默认赋值
2-2、局部变量：在使用前，必须要进行显式赋值的！否则，编译不通过。

参数表分配完毕之后，再根据方法体内定义的变量的顺序和作用域分配。
我们知道成员变量有两次初始化的机会，第一次是在“准备阶段”，执行系统初始化，对类变量设置零值，另一次则是在“初始化”阶段，赋予程序员在代码中定义的初始值。
和类变量初始化不同的是，局部变量表不存在系统初始化的过程，这意味着一旦定义了局部变量则必须人为的初始化，否则无法使用。

补充：
在栈帧中，与性能调优关系最为密切的部分就是前面提到的局部变量表。在方法执行时，虚拟机使用局部变量表完成方法的传递。
局部变量表中的变量也是重要的垃圾回收根节点，只要被局部变量表中直接或间接引用的对象都不会被回收。

Slot 的重复利用

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

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

操作数栈的特点

每一个独立的栈帧除了包含局部变量表以外，还包含一个后进先出（Last - In - First -Out）的 操作数栈，也可以称之为表达式栈（Expression Stack）

操作数栈，在方法执行过程中，根据字节码指令，往栈中写入数据或提取数据，即入栈（push）和 出栈（pop）
某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈，
比如：执行复制、交换、求和等操作

操作数栈的作用

操作数栈，主要用于保存计算过程的中间结果，同时作为计算过程中变量临时的存储空间。
操作数栈就是 JVM 执行引擎的一个工作区，当一个方法刚开始执行的时候，一个新的栈帧也会随之被创建出来，这时方法的操作数栈是空的。
每一个操作数栈都会拥有一个明确的栈深度用于存储数值，其所需的最大深度在编译期就定义好了，保存在方法的 Code 属性中，为 maxstack 的值。
栈中的任何一个元素都是可以任意的 Java 数据类型
32bit 的类型占用一个栈单位深度
64bit 的类型占用两个栈单位深度
操作数栈并非采用访问索引的方式来进行数据访问的，而是只能通过标准的入栈和出栈操作来完成一次数据访问。只不过操作数栈是用数组这个结构来实现的而已
如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，并更新 PC 寄存器中下一条需要执行的字节码指令。
操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，这由编译器在编译器期间进行验证，同时在类加载过程中的类检验阶段的数据流分析阶段要再次验证。
另外，我们说 Java 虚拟机的解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈。

栈顶缓存技术

Top Of Stack Cashing（tos）
前面提过，基于栈式架构的虚拟机所使用的零地址指令更加紧凑，但完成一项操作的时候必然需要使用更多的入栈和出栈指令，这同时也就意味着将需要更多的指令分派（instruction dispatch）次数（也就是你会发现指令很多）和导致内存读/写次数多，效率不高。

由于操作数是存储在内存中的，因此频繁地执行内存读/写操作必然会影响执行速度。为了解决这个问题，HotSpot JVM 的设计者们提出了栈顶缓存（Tos，Top-of-Stack Cashing）技术，将栈顶元素全部缓存在物理 CPU 的寄存器中，以此降低对内存的读/写次数，提升执行引擎的执行效率。
寄存器的主要优点：指令更少，执行速度快，但是指令集（也就是指令种类）很多

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

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

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

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

存放调用该方法的 pc 寄存器的值。

一个方法的结束，有两种方式：

正常执行完成
出现未处理的异常，非正常退出

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

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

一些附加信息

并行每个线程下的栈都是私有的，因此每个线程都有自己各自的栈，并且每个栈里面都有很多栈帧，栈帧的大小主要由局部变量表 和 操作数栈决定的

OOM 垃圾回收区域

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

如果只有一个线程才可以操作此数据，则必是线程安全的。
如果有多个线程操作此数据，则此数据是共享数据。如果不考虑同步机制的话，会存在线程安全问题。
如果对象是在内部产生，并在内部消亡，没有返回到外部，那么它就是线程安全的，反之则是线程不安全的。

堆

一个运行时数据区只有一个堆和一个方法区。但是进程包含多个线程，他们是共享同一堆空间的。

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

Java 堆区在 JVM 启动的时候即被创建，其空间大小也就确定了，堆是 JVM 管理的最大一块内存空间，并且堆内存的大小是可以调节的。-Xms -Xms

《Java 虚拟机规范》规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。
所有的线程共享 Java 堆，在这里还可以划分线程私有的缓冲区（Thread Local Allocation Buffer，TLAB）。

从实际使用角度看：“几乎”所有的对象实例都在堆分配内存，但并非全部。因为还有一些对象是在栈上分配的（逃逸分析，标量替换）

数组和对象可能永远不会存储在栈上（不一定），因为栈帧中保存引用（局部变量表），这个引用指向对象或者数组在堆中的位置。

堆详细组成

-Xms 用于表示堆区的起始内存，等价于**-XX:InitialHeapSize**
-Xmx 则用于表示堆区的最大内存，等价于**-XX:MaxHeapSize**

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

通常会将-Xms 和-Xmx 两个参数配置相同的值

原因：假设两个不一样，初始内存小，最大内存大。在运行期间如果堆内存不够用了，会一直扩容直到最大内存。如果内存够用且多了，也会不断的缩容释放。频繁的扩容和释放造成不必要的压力，避免在 GC 之后调整堆内存给服务器带来压力。

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

堆的分区？

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

默认**-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

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

绝大部分的 Java 对象的销毁都在新生代进行了（有些大的对象在 Eden 区无法存储时候，将直接进入老年代），IBM 公司的专门研究表明，新生代中 80%的对象都是“朝生夕死”的。
可以使用选项”-Xmn”设置新生代最大内存大小，但这个参数一般使用默认值就可以了。

具体过程

new 的对象先放伊甸园区。此区有大小限制。

当伊甸园的空间填满时，程序又需要创建对象，JVM 的垃圾回收器将对伊甸园区进行垃圾回收（MinorGC），将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区。

然后将伊甸园中的剩余对象移动到幸存者 0 区。

如果再次触发垃圾回收，此时上次幸存下来的放到幸存者 0 区的，如果没有回收，就会放到幸存者 1 区。
如果再次经历垃圾回收，此时会重新放回幸存者 0 区，接着再去幸存者 1 区。

啥时候能去养老区呢？可以设置次数。默认是 15 次。可以设置新生区进入养老区的年龄限制，设置 JVM 参数：**-XX:MaxTenuringThreshold**=N 进行设置

在养老区，相对悠闲。当养老区内存不足时，再次触发 GC：Major GC，进行养老区的内存清理
若养老区执行了 Major GC 之后，发现依然无法进行对象的保存，就会产生 OOM 异常。

关于垃圾回收：频繁在新生区收集，很少在养老区收集，几乎不在永久区/元空间收集。
幸存者 s0，s1 区，复制之后有交换，谁空谁是 to

特殊情况

对象分配的特殊情况

1，如果来了一个新对象，先看看 Eden 是否放的下？
如果 Eden 放得下，则直接放到 Eden 区
如果 Eden 放不下，则触发 YGC ，执行垃圾回收，看看还能不能放下？

2，将对象放到老年区又有两种情况：
如果 Eden 执行了 YGC 还是无法放不下该对象，那没得办法，只能说明是超大对象，只能直接放到老年代
那万一老年代都放不下，则先触发 FullGC ，再看看能不能放下，放得下最好，但如果还是放不下，那只能报 OOM

3，如果 Eden 区满了，将对象往幸存区拷贝时，发现幸存区放不下啦，那只能便宜了某些新对象，让他们直接晋升至老年区

JVM 的调优的一个环节，也就是垃圾收集，我们需要尽量的避免垃圾回收，因为在垃圾回收的过程中，容易出现 STW（Stop the World）的问题，而 Major GC 和 Full GC 出现 STW 的时间，是 Minor GC 的 10 倍以上。

JVM 在进行 GC 时，并非每次都对上面三个内存区域（新生代，老年代：方法区（元空间））一起回收的，大部分时候回收的都是指新生代。针对 Hotspot VM 的实现，它里面的 GC 按照回收区域又分为两大种类型：一种是部分收集（Partial GC），一种是整堆收集（FullGC）

部分收集：不是完整收集整个 Java 堆的垃圾收集。其中又分为：
新生代收集（Minor GC/Young GC）：只是新生代（Eden，s0，s1）的垃圾收集
老年代收集（Major GC/Old GC）：只是老年代的圾收集。
目前，只有CMS GC 会有单独收集老年代的行为。

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

混合收集（Mixed GC）：收集整个新生代以及部分老年代的垃圾收集。目前，只有 G1 GC 会有这种行为
整堆收集（Full GC）：收集整个 java 堆和方法区的垃圾收集。

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

调用 System.gc()时，系统建议执行 FullGC，但是不必然执行

老年代空间不足

方法区（元空间，永久代）空间不足

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

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

TLAB 为对象分配内存（保证线程安全）

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

TLAB（Thread Local Allocation Buffer）（buffer 缓冲区）

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

尽管不是所有的对象实例都能够在 TLAB 中成功分配内存，但 JVM 确实是将 TLAB 作为内存分配的首选。
在程序中，开发人员可以通过选项“**-XX:UseTLAB**”设置是否开启 TLAB 空间。

默认情况下，TLAB 空间的内存非常小，仅占有整个 Eden 空间的 1%，当然我们可以通过选项“**-XX:TLABWasteTargetPercent**”设置 TLAB 空间所占用 Eden 空间的百分比大小。

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

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

在《深入理解 Java 虚拟机》中关于 Java 堆内存有这样一段描述：
随着 JIT 编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。

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

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

逃逸分析

如何将堆上的对象分配到栈，需要使用逃逸分析手段。
这是一种可以有效减少 Java 程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。
通过逃逸分析，Java Hotspot 编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。

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

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

如何快速的判断是否发生了逃逸分析，大家就看 new 的对象实体是否有可能在方法外被调用。

逃逸分析的不足

其根本原因就是无法保证逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。

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

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

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

方法区

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

方法区主要存放的是 Class，而堆中主要存放的是实例化的对象

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

方法区（Method Area）与 Java 堆一样，是各个线程共享的内存区域。多个线程同时加载统一个类时，只能有一个线程能加载该类，其他线程只能等等待该线程加载完毕，然后直接使用该类，即类只能加载一次。

方法区在 JVM 启动的时候被创建，并且它的实际的物理内存空间中和 Java 堆区一样都可以是不连续的。
方法区的大小，跟堆空间一样，可以选择固定大小或者可扩展。

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

加载大量的第三方的 jar 包
Tomcat 部署的工程过多（30~50 个）
大量动态的生成反射类
关闭 JVM 就会释放这个区域的内存。

类型信息
对每个加载的类型（类 class、接口 interface、枚举 enum、注解 annotation），JVM 必须在方法区中存储以下类型信息：
这个类型的完整有效名称（全名=包名.类名）
这个类型直接父类的完整有效名（对于 interface 或是 java.lang.Object，都没有父类）
这个类型的修饰符（public，abstract，final 的某个子集）
这个类型直接接口的一个有序列表

域（Field）信息
也就是我们常说的成员变量，域信息是比较官方的称呼
JVM 必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。
域的相关信息包括：域名称，域类型，域修饰符（public，private，protected，static，final，volatile，transient 的某个子集）

方法（Method）信息
JVM 必须保存所有方法的以下信息，同域信息一样包括声明顺序：
方法名称
方法的返回类型（包括 void 返回类型），void 在 Java 中对应的为 void.class
方法参数的数量和类型（按顺序）
方法的修饰符（public，private，protected，static，final，synchronized，native，abstract 的一个子集）
方法的字节码（bytecodes）、操作数栈、局部变量表及大小（abstract 和 native 方法除外）
异常表（abstract 和 native 方法除外），异常表记录每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引

non-final 类型的类变量
静态变量和类关联在一起，随着类的加载而加载，他们成为类数据在逻辑上的一部分
类变量被类的所有实例共享，即使没有类实例时，你也可以访问它

全局常量：static final
全局常量就是使用 static final 进行修饰
被声明为 final 的类变量的处理方法则不同，每个全局常量在编译的时候就会被分配了。
staitc 和 final 同时修饰的 number 的值在编译上的时候已经写死在字节码文件中了。

运行时常量池

运行时常量池 VS 常量池

方法区，内部包含了运行时常量池
字节码文件，内部包含了常量池。（之前的字节码文件中已经看到了很多 Constant pool 的东西，这个就是常量池）
要弄清楚方法区，需要理解清楚 ClassFile，因为加载类的信息都在方法区。
要弄清楚方法区的运行时常量池，需要理解清楚 ClassFile 中的常量池。

常量池

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

为什么需要常量池？

一个 java 源文件中的类、接口，编译后产生一个字节码文件。而 Java 中的字节码需要数据支持，通常这种数据会很大以至于不能直接存到字节码里，换另一种方式，可以存到常量池。这个字节码包含了指向常量池的引用。在动态链接的时候会用到运行时常量池。
public class SimpleClass {
public void sayHello() {
System.out.println(“hello”);
}
}
虽然上述代码只有 194 字节，但是里面却使用了 String、System、PrintStream 及 Object 等结构。
比如说我们这个文件中有 6 个地方用到了”hello”这个字符串，如果不用常量池，就需要在 6 个地方全写一遍，造成臃肿。我们可以将”hello”等所需用到的结构信息记录在常量池中，并通过引用的方式，来加载、调用所需的结构

常量池总结
常量池、可以看做是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等类型。

运行时常量池

运行时常量池（Runtime Constant Pool）是方法区的一部分。
常量池表（Constant Pool Table）是 Class 字节码文件的一部分，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。（运行时常量池就是常量池在程序运行时的称呼）

运行时常量池，在加载类和接口到虚拟机后，就会创建对应的运行时常量池。
JVM 为每个已加载的类型（类或接口）都维护一个常量池。池中的数据项像数组项一样，是通过索引访问的。
运行时常量池中包含多种不同的常量，包括编译期就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或者字段引用。此时不再是常量池中的符号地址了，这里换为真实地址。

运行时常量池，相对于 Class 文件常量池的另一重要特征是：具备动态性。
运行时常量池类似于传统编程语言中的符号表（symbol table），但是它所包含的数据却比符号表要更加丰富一些。
当创建类或接口的运行时常量池时，如果构造运行时常量池所需的内存空间超过了方法区所能提供的最大值，则 JVM 会抛 OutofMemoryError 异常。

演变

永久代为什么要被元空间替代？

随着 Java8 的到来，HotSpot VM 中再也见不到永久代了。但是这并不意味着类的元数据信息也消失了。这些数据被移到了一个与堆不相连的本地内存区域，这个区域叫做元空间（Metaspace）。

由于类的元数据分配在本地内存中，元空间的最大可分配空间就是系统可用内存空间。

这项改动是很有必要的，原因有：
1，永久代设置空间大小是很难确定的。在某些场景下，如果动态加载类过多，容易产生 Perm 区的 OOM。比如某个实际 Web 工程中，因为功能点比较多，在运行过程中，要不断动态加载很多类，经常出现致命错误。Exception in thread ‘dubbo client x.x connector’ java.lang.OutOfMemoryError:PermGen space 而元空间和永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。 因此，默认情况下，元空间的大小仅受本地内存限制。

2，对永久代进行调优是很困难的。方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再用的类型，方法区的调优主要是为了降低 Full GC

有些人认为方法区（如 HotSpot 虚拟机中的元空间或者永久代）是没有垃圾收集行为的，其实不然。《Java 虚拟机规范》对方法区的约束是非常宽松的，提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在（如 JDK11 时期的 ZGC 收集器就不支持类卸载）。
一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻。但是这部分区域的回收有时又确实是必要的。以前 Sun 公司的 Bug 列表中，曾出现过的若干个严重的 Bug 就是由于低版本的 HotSpot 虚拟机对此区域未完全回收而导致内存泄漏。

字符串常量池

字符串常量池 StringTable 为什么要调整位置？
JDK7 中将 StringTable 放到了堆空间中。因为永久代的回收效率很低，在 Full GC 的时候才会执行永久代的垃圾回收，而 Full GC 是老年代的空间不足、永久代不足时才会触发。
这就导致 StringTable 回收效率不高，而我们开发中会有大量的字符串被创建，回收效率低，导致永久代内存不足。放到堆里，能及时回收内存。

静态变量放在哪里

对象实体在哪里放着？
private static byte[] arr = new byte[1024 * 1024 * 100];//100MB
静态引用对应的对象实体(也就是这个 new byte[1024 * 1024 * 100])始终都存在堆空间，

只是那个变量(相当于下面的 arr 变量名)在 JDK6,JDK7,JDK8 存放位置中有所变化

变量(名)存放在哪里？

从《Java 虚拟机规范》所定义的概念模型来看，所有 Class 相关的信息都应该存放在方法区之中，但方法区该如何实现，《Java 虚拟机规范》并未做出规定，这就成了一件允许不同虚拟机自己灵活把握的事情。JDK7 及其以后版本的 HotSpot 虚拟机选择把静态变量与类型在 Java 语言一端的映射 Class 对象存放在一起，存储于 Java 堆之中

方法区的垃圾回收

方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型。
先来说说方法区内常量池之中主要存放的两大类常量：字面量和符号引用。字面量比较接近 Java 语言层次的常量概念，如文本字符串、被声明为 final 的常量值等。而符号引用则属于编译原理方面的概念，包括下面三类常量：
类和接口的全限定名
字段的名称和描述符
方法的名称和描述符

HotSpot 虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。
回收废弃常量与回收 Java 堆中的对象非常类似。（关于常量的回收比较简单，重点是类的回收）

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

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

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

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