??????? 虚拟机栈是每个线程有一个私有的栈，随着线程的创建而创建。栈里面存着的是一种叫“栈帧”的东西，每调用一个方法会创建一个栈帧（Stack Frame），栈帧中存放了局部变量表（基本数据类型和对象引用）、操作数栈、方法出口等信息。栈的大小可以固定也可以动态扩展。当栈调用深度大于JVM所允许的范围，会抛出StackOverflowError的错误，不过这个深度范围不是一个恒定的值。

????????每个方法被调用和完成的过程，都对应一个栈帧从虚拟机栈上入栈和出栈的过程。虚拟机栈的生命周期和线程是相同的。

????????虚拟机栈是一个后入先出（FILO）的栈。栈帧是保存在虚拟机栈中的，栈帧是用来存储数据和存储部分过程结果的数据结构，同时也被用来处理动态链接（Dynamic Linking）、方法返回值和异常分派（Dispatch Exception）。线程运行过程中，只有一个栈帧是处于活跃状态，称为“当前活跃栈帧”，当前活动栈帧始终是虚拟机栈的栈顶元素。

我们对一个活动线程的栈帧进行分析：

1.局部变量表

????????局部变量表(Local Variable Table)是一组局部变量值存储空间，用于存放方法参数和方法内部定义的局部变量。局部变量表的容量以变量槽(Variable Slot)为最小单位，Java虚拟机规范并没有定义一个槽所应该占用内存空间的大小，但是规定了一个槽应该可以存放一个32位以内的数据类型。

????????在Java文件编译为Class文件时，就在方法表的Code属性的max_locals数据项中确定了该方法需要分配的最大局部变量表的容量。(最大Slot数量)

????????一个局部变量可以保存一个类型为boolean、byte、char、short、int、float、reference和returnAddress类型的数据。reference类型表示对一个对象实例的引用。returnAddress类型是为jsr、jsr_w和ret指令服务的，目前已经很少使用了。

????????虚拟机通过索引定位的方法查找相应的局部变量，索引的范围是从0~局部变量表最大容量。如果Slot是32位的，则遇到一个64位数据类型的变量(如long或double型)，则会连续使用两个连续的Slot来存储。

2.操作数栈

????????操作数栈(Operand Stack)也常被称为操作栈，它是一个后入先出栈(LIFO)。JVM底层字节码指令集是基于栈类型的，所有的操作码都是对操作数栈上的数据进行操作，对于每一个方法的调用，JVM会建立一个操作数栈，以供计算使用。

????????和局部变量一样。操作数栈的最大深度也是编译的时候写入到方法表的code属性的max_stacks数据项中。操作数栈的每一个元素可以是任意的Java数据类型，包括long、double。

32位数据类型所占的栈容量为1，

64位数据类型所占的栈容量为2。

栈容量的单位为“字宽”，

对于32位虚拟机来说，一个“字宽”占4个字节，

对于64位虚拟机来说，一个“字宽”占8个字节。

????????当一个方法刚刚执行的时候，这个方法的操作数栈是空的，在方法执行的过程中，会有各种字节码指向操作数栈中写入和提取值，也就是入栈与出栈操作。

????????另外，在概念模型中，两个栈帧作为虚拟机栈的元素，相互之间是完全独立的，但是大多数虚拟机的实现里都会作一些优化处理，令两个栈帧出现一部分重叠。让下栈帧的部分操作数栈与上面栈帧的部分局部变量表重叠在一起，这样在进行方法调用返回时就可以共用一部分数据，而无须进行额外的参数复制传递了。

3.动态连接

????????每个栈帧都包含一个指向运行时常量池中该栈帧所属性方法的引用，持有这个引用是为了支持方法调用过程中的动态连接(Dynamic Linking)。

????????在Class文件的常量池中存有大量的符号引用，字节码中的方法调用指令就以常量池中指向方法的符号引用为参数。这些符号引用一部分会在类加载阶段或第一次使用的时候转化为直接引用，这种转化称为静态解析；另外一部分将在每一次的运行期期间转化为直接引用，这部分称为动态连接。

4.方法返回地址

当一个方法被执行后，有两种方式退出这个方法：

????????第一种方式是执行引擎遇到任意一个方法返回的字节码指令，这时候可能会有返回值传递给上层的方法调用者(调用当前方法的的方法称为调用者)，是否有返回值和返回值的类型将根据遇到何种方法返回指令来决定，这种退出方法方式称为正常完成出口(Normal Method Invocation Completion)。

????????另外一种退出方式是，在方法执行过程中遇到了异常，并且这个异常没有在方法体内得到处理，无论是Java虚拟机内部产生的异常，还是代码中使用athrow字节码指令产生的异常，只要在本方法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出，这种退出方式称为异常完成出口(Abrupt Method Invocation Completion)。

一个方法使用异常完成出口的方式退出，是不会给它的调用都产生任何返回值的。

????????无论采用何种方式退出，在方法退出之前，都需要返回到方法被调用的位置，程序才能继续执行，方法返回时可能需要在栈帧中保存一些信息，用来帮助恢复它的上层方法的执行状态。一般来说，方法正常退出时，调用者PC计数器的值就可以作为返回地址，栈帧中很可能会保存这个计数器值。而方法异常退出时，返回地址是要通过异常处理器来确定的，栈帧中一般不会保存这部分信息。方法退出的过程实际上等同于把当前栈帧出栈，因此退出时可能执行的操作有：恢复上层方法的局部变量表和操作数栈，把返回值(如果有的话)压入调用都栈帧的操作数栈中，调用PC计数器的值以指向方法调用指令后面的一条指令等。

5.附加信息

????????虚拟机规范允许具体的虚拟机实现增加一些规范里没有描述的信息到栈帧中，例如与高度相关的信息，这部分信息完全取决于具体的虚拟机实现。在实际开发中，一般会把动态连接，方法返回地址与其它附加信息全部归为一类，称为栈帧信息。

二、本地方法栈：

????????本地方法栈（Native Method Stacks）与 Java 虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行 Java 方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的 Native 方法服务。虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。

????????然而什么是Navtive方法呢，我们知道JVM的底层实际上使用了很多C语言的函数库，Navtive 方法是 Java 通过 JNI 直接调用本地 C/C++ 库，可以认为是 Native 方法相当于 C/C++ 暴露给 Java 的一个接口，Java 通过调用这个接口从而调用到 C/C++ 方法。当线程调用 Java 方法时，虚拟机会创建一个栈帧并压入 Java 虚拟机栈。然而当它调用的是 native 方法时，虚拟机会保持 Java 虚拟机栈不变，也不会向 Java 虚拟机栈中压入新的栈帧，虚拟机只是简单地动态连接并直接调用指定的 native 方法。

????????一个线程可能在整个生命周期中都执行Java方法，操作它的Java栈；或者它可能毫无障碍地在Java栈和本地方法栈之间跳转。

例如：

????????该线程首先调用了两个Java方法，而第二个Java方法又调用了一个本地方法，这样导致虚拟机使用了一个本地方法栈。假设这是一个C语言栈，其间有两个C函数，第一个C函数被第二个Java方法当做本地方法调用，而这个C函数又调用了第二个C函数。之后第二个C函数又通过本地方法接口回调了一个Java方法（第三个Java方法），最终这个Java方法又调用了一个Java方法（它成为图中的当前方法）。

????????本地方法栈是一个后入先出（LIFO）栈。

????????由于是线程私有的，生命周期随着线程，线程启动而产生，线程结束而消亡。

????????本地方法栈会抛出 StackOverflowError 和 OutOfMemoryError 异常。

三、 PC寄存器：

????????程序计数寄存器(Program Counter Register)这里并非广义上所指的物理寄存器，或许将其翻译为PC计数器会更加贴切。JVM中的PC寄存器是对物理PC寄存器的一种抽象模拟。

PC寄存器用来存储指向下一条指令的地址，也就是即将要执行的指令代码。

它是一块很小的内存空间，几乎可以忽略不记。也是运行速度最快的存储区域
在JVM规范中，每个线程都有它自己的程序计数器，是线程私有的，生命周期与线程的生命周期保持一致。
任何时间一个线程都只有一个方法在执行，也就是所谓的当前方法。
程序计数器会存储当前线程正在执行的Java方法的JVM指令地址，若在执行native方法，则是未指定值(undefined)

????????每个线程启动的时候，都会创建一个PC寄存器。 PC寄存器的内容总是指向下一条将被执行指令的地址，这里的地址可以是一个本地指针，也可以是在方法区中相对应于该方法起始指令的偏移量。

????????我们都清楚，处理器在处理的时候，会不停的切换各个线程，这时候切换回来以后，必然导致经常中断或恢复，如何保证分毫无差呢？

??????? PC寄存器存在的意义，就是保证切换回来以后，知道接着从哪开始继续执行。JVM的字节码解释器需要通过改变PC寄存器的值来明确下一条应该执行什么样的字节码指令。

????????为了能够准确地记录各个线程正在执行的当前字节码指令地址，最好的办法自然是为每一个线程都分配一个PC寄存器，这样一来各个线程之间便可以进行独立计算，从而不会出现相互干扰的情况。

四、堆：

????????类的对象放在heap（堆）中，所有的类对象都是通过new方法创建，创建后，在stack（栈）会创建类对象的引用（内存地址）。

????????一种常规用途的内存池（也在RAM（随机存取存储器）区域），其中保存了Java对象。和栈不同：“内存堆”或“堆”最吸引人的地方在于编译器不必知道要从堆里分配多少存储空间，也不必知道存储的数据要在堆里停留多长的时间。因此，用堆保存数据时会得到更大的灵活性。要求创建一个对象时，只需用new命令编辑相应的代码即可。执行这些代码时，会在堆里自动进行数据的保存。当然，为达到这种灵活性，必然会付出一定的代价：在堆里分配存储空间时会花掉更长的时间。

????????JVM将所有对象的实例（即用new创建的对象）（对应于对象的引用（引用就是内存地址））的内存都分配在堆上，堆所占内存的大小由-Xmx指令和-Xms指令来调节。

?我们讨论堆，一般就会讨论到JVM的垃圾回收机制：

GC：

在JDK1.2之前，使用的是引用计数器算法，

??????? 计数器算法就是当这个类被加载到内存以后，就会产生方法区，堆栈、程序计数器等一系列信息，当创建对象的时候，为这个对象在堆栈空间中分配对象，同时会产生一个引用计数器，同时引用计数器+1，当有新的引用的时候，引用计数器继续+1，而当其中一个引用销毁的时候，引用计数器-1，当引用计数器被减为零的时候，标志着这个对象已经没有引用了，可以回收了。但是这种回收方式在相互引用的情况下会出现问题：

比如执行下面的代码：

?ObjA.obj = ObjB
 ObjB.obj = ObjA

????????在这种情况下，objA指向objB，而objB又指向objA，这样当其他所有的引用都消失了之后，objA和objB还有一个相互的引用，他没有额外的引用了，已经是垃圾了。但是GC算法无法清除。

所以在JDK1.2之后引入了根搜索算法：

????????根搜索算法是从离散数学中的图论引入的，程序把所有的引用关系看作一张图，从一个节点GC ROOT开始，寻找对应的引用节点，找到这个节点以后，继续寻找这个节点的引用节点，当所有的引用节点寻找完毕之后，剩余的节点则被认为是没有被引用到的节点，即无用的节点。

????????目前java中可作为GC Root的对象有主要是全局性的，如常量、静态属性，执行上下文（栈帧中的本地变量表）一般是如下对象：

虚拟机栈中引用的对象（本地变量表）
方法区中静态属性引用的对象
方法区中常量引用的对象
本地方法栈中引用的对象（Native对象）

不同的对象引用类型， GC会采用不同的方法进行回收，JVM对象的引用分为了四种类型：

强引用：默认情况下，对象采用的均为强引用（这个对象的实例没有其他对象引用，GC时才会被回收）
软引用：软引用是Java中提供的一种比较适合于缓存场景的应用（只有在内存不够用的情况下才会被GC）
弱引用：在GC时一定会被GC回收
虚引用：由于虚引用只是用来得知对象是否被GC，在这个对象呗收集器回收时收到一个系统通知

????????方法区的数据因为回收率非常小，而成本又比较高，一般认为是“性价比”非常差的，方法区的回收条件非常苛刻，只有同时满足以下三个条件才会被回收！

所有实例被回收
加载该类的ClassLoader被回收
Class对象无法通过任何途径访问(包括反射)

收集后的垃圾，一般通过以下几种算法进行处理：

1.标记-清除算法

????????标记-清除算法采用从根集合进行扫描，对存活的对象对象标记，标记完毕后，再扫描整个空间中未被标记的对象，进行回收。标记-清除算法不需要进行对象的移动，并且仅对不存活的对象进行处理，在存活对象比较多的情况下极为高效，但由于标记-清除算法直接回收不存活的对象，因此会造成内存碎片。

2.复制算法

????????复制算法采用从根集合扫描，并将存活对象复制到一块新的，没有使用过的空间中，这种算法当控件存活的对象比较少时，极为高效，但是带来的成本是需要一块内存交换空间用于进行对象的移动。

3. 标记-整理算法

????????标记-整理算法采用标记-清除算法一样的方式进行对象的标记，但在清除时不同，在回收不存活的对象占用的空间后，会将所有的存活对象往左端空闲空间移动，并更新对应的指针。标记-整理算法是在标记-清除算法的基础上，又进行了对象的移动，因此成本更高，但是却解决了内存碎片的问题。

4.分代收集算法

????????当前的商业虚拟机的垃圾收集都采用分代收集算法，根据对象存活周期的不同将内存划分为几块，java堆中的新生代中，每次垃圾收集时都有大批对象死去，只有少量存活，就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高，没有额外空间对它进行分配担保，就必须使用“标记——清理”或者“标记——整理”算法进行回收。

????????在Java虚拟机中，我们为了更好的GC，根据对象存活的周期不同，把堆内存划分为几块，一般分为新生代、老年代和永久代（对HotSpot虚拟机而言），这就是JVM的内存分代策略。

1.永久代：

????????永久代是HotSpot虚拟机特有的概念（JDK1.8之后为元空间（metaspace）替代永久代），它采用永久代的方式来实现方法区，其他的虚拟机实现没有这一概念，而且HotSpot也有取消永久代的趋势，在JDK 1.7中HotSpot已经开始了“去永久化”，把原本放在永久代的字符串常量池移出。永久代主要存放常量、类信息、静态变量等数据，与垃圾回收关系不大，新生代和老年代是垃圾回收的主要区域。

元空间并不在JVM中，而是使用本地内存。

2.新生代：

????????新生成的对象优先存放在新生代中，新生代对象朝生夕死，存活率很低，在新生代中，常规应用进行一次垃圾收集一般可以回收70% ~ 95% 的空间，回收效率很高。

????????HotSpot将新生代划分为三块，一块较大的Eden（伊甸）空间和两块较小的Survivor（幸存者）空间，默认比例为8：1：1。划分的目的是因为HotSpot采用复制算法来回收新生代，设置这个比例是为了充分利用内存空间，减少浪费。新生成的对象在Eden区分配（大对象除外，大对象直接进入老年代），当Eden区没有足够的空间进行分配时，虚拟机将发起一次Minor GC。

????????GC开始时，对象只会存在于Eden区和From Survivor区，To Survivor区是空的（作为保留区域）。

????????GC进行时，Eden区中所有存活的对象都会被复制到To Survivor区，而在From Survivor区中，仍存活的对象会根据它们的年龄值决定去向，年龄值达到年龄阀值（默认为15，新生代中的对象每熬过一轮垃圾回收，年龄值就加1，GC分代年龄存储在对象的header中）的对象会被移到老年代中，没有达到阀值的对象会被复制到To Survivor区。

????????接着清空Eden区和From Survivor区，新生代中存活的对象都在To Survivor区。

????????接着， From Survivor区和To Survivor区会交换它们的角色，也就是新的To Survivor区就是上次GC清空的From Survivor区，新的From Survivor区就是上次GC的To Survivor区，总之，不管怎样都会保证To Survivor区在一轮GC后是空的。

????????GC时当To Survivor区没有足够的空间存放上一次新生代收集下来的存活对象时，需要依赖老年代进行分配担保，将这些对象存放在老年代中。

大概如下图所示：

3.老年代:

　　在新生代中经历了多次（具体看虚拟机配置的阀值）GC后仍然存活下来的对象会进入老年代中。老年代中的对象生命周期较长，存活率比较高，在老年代中进行GC的频率相对而言较低，而且回收的速度也比较慢。

简单总结一下GC：

????????JVM在进行GC时，可能针对三个区域进行垃圾回收分别是新生代、老年代、方法区，大部分时候回收的都是新生代。GC类型主要有以下四种类型。

新生代收集（Minor GC/Young GC）：只针对新生代的垃圾收集。具体点的是Eden区满时触发GC。 Survivor满不会触发Minor GC 。
老年代收集（Major GC/Old GC）：只针对老年代的垃圾收集。目前，只有CMS收集器会有单独收集老年代的行为。
混合收集（Mixed GC）：指目标是收集整个新生代以及部分老年代的垃圾收集。目前只有G1收集器会有这种行为。
整堆收集（Full GC）：收集整个Java堆和方法区的垃圾收集。

Minor GC：

????????当年轻代（Eden区）满时就会触发 Minor GC，这里的年轻代满指的是 Eden区满。Survivor 满不会触发 Minor GC 。对于大部分应用程序，Minor GC 操作时应用程序停顿导致的延迟都是可以忽略不计的。大部分 Eden 区中的对象都能被认为是垃圾，永远也不会被复制到 Survivor 区或者老年代空间。如果正好相反，Eden 区大部分新生对象不符合 GC 条件，Minor GC 执行时暂停的时间将会长很多。

Major GC：

????????当老年代满时会触发MajorGC，只有CMS收集器会有单独收集老年代的行为，其他收集器均无此行为。而针对新生代的MinorGC，各个收集器均支持。总之，单独发生收集行为的只有新生代，除了CMS收集器，都不支持单独回收老年代。

Full GC：

　FullGC是针对新生代，老年代和方法区（元空间）的垃圾收集。FullGC产生的条件：

调用System.gc时，系统建议执行Full GC，但是不一定会执行。
老年代空间不足。
方法区空间不足，类卸载（类卸载三个条件）。
通过 Minor GC 后进入老年代的空间大于老年代的可用内存
内存空间担保。

????????一个JVM实例只有一个堆内存，堆也是Java内存管理的核心区域，堆在JVM启动的时候创建，其空间大小也被创建，是JVM中最大的一块内存空间，所有线程共享Java堆，物理上不连续的逻辑上连续的内存空间，几乎所有的实例都在这里分配内存，在方法结束后，堆中的对象不会马上删除，仅仅在垃圾收集的时候被删除，堆是GC（垃圾收集器）执行垃圾回收的重点区域。

?五、方法区：

????????method（方法区）又叫静态区，存放所有的类（class），静态变量（static变量），静态方法，常量和成员方法。比如spring 使用IOC或者AOP创建bean时，或者使用cglib，反射的形式动态生成class信息等）。

跟堆一样，被所有的线程共享。
方法区中存放的都是在整个程序中永远唯一的元素。这也是方法区被所有的线程共享的原因。

????????方法区的大小由-XX:PermSize和-XX:MaxPermSize来调节，类太多有可能撑爆永久代。静态变量或常量也有可能撑爆方法区。

在讨论方法区的时候，我们更多的是需要理解常量池：

运行时常量池(Runtime Constant Pool)是方法区的一部分。

????????运行时常量池是当Class文件被加载到内存后，Java虚拟机会将Class文件常量池里的内容转移到运行时常量池里(运行时常量池也是每个类都有一个)。运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量一定只有编译期才能产生，也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中

????????该区域存放类和接口的常量，除此之外，它还存放成员变量和成员方法的所有引用。当一个成员变量或者成员方法被引用的时候，JVM就通过运行常量池中的这些引用来查找成员变量和成员方法在内存中的的实际地址。

不仅是运行时常量池，常量池一般分为三个：

????????Classs常量池，运行时常量池和字符串常量池。

Class常量池：

????????我们写的每一个Java类被编译后，就会形成一份class文件；class文件中除了包含类的版本、字段、方法、接口等描述信息外，还有一项信息就是常量池(constant pool table)，用于存放编译器生成的各种字面量(Literal)和符号引用(Symbolic References)；每个class文件都有一个class常量池。

字面量包括：
- 1.文本字符串
- 2.八种基本类型的值
- 3.被声明为final的常量等;
符号引用包括：
- 1.类和方法的全限定名
- 2.字段的名称和描述符
- 3.方法的名称和描述符。

运行时常量池：

????????运行时就是我们之前提到过的，也就是class常量池被加载到内存之后的版本。

????????不同之处是：它的字面量可以动态的添加(String#intern()),符号引用可以被解析为直接引用

????????JVM在执行某个类的时候，必须经过加载、连接、初始化，而连接又包括验证、准备、解析三个阶段。而当类加载到内存中后，jvm就会将class常量池中的内容存放到运行时常量池中，由此可知，运行时常量池也是每个类都有一个。在解析阶段，会把符号引用替换为直接引用，解析的过程会去查询字符串常量池，也就是我们上面所说的StringTable，以保证运行时常量池所引用的字符串与字符串常量池中是一致的。

字符串常量池：

????????字符串常量池又称为：字符串池，全局字符串池,英文也叫String Pool。在工作中，String类是我们使用频率非常高的一种对象类型。JVM为了提升性能和减少内存开销，避免字符串的重复创建，其维护了一块特殊的内存空间，这就是我们今天要讨论的核心：字符串常量池。字符串常量池由String类私有的维护。（享元模式的一种体现）

在JDK7之前字符串常量池是在永久代里边的，但是在JDK7之后，把字符串常量池分进了堆里边。

堆里边的字符串常量池存放的是字符串的引用或者字符串(两者都有)

????????字符串池的实现有一个前提条件：String对象是不可变的。因为这样可以保证多个引用可以同时指向字符串池中的同一个对象。如果字符串是可变的，那么一个引用操作改变了对象的值，对其他引用会有影响，这样显然是不合理的。

我们知道，在Java中有两种创建字符串对象的方式：

采用字面值的方式赋值
采用new关键字新建一个字符串对象。这两种方式在性能和内存占用方面存在着差别。

????????采用字面值的方式创建一个字符串时，JVM首先会去字符串池中查找是否存在这个对象，如果不存在，则在字符串池中创建这个对象，然后将池中对象的引用地址返回给字符串常量，这样字符串会指向池中的这个字符串对象；如果存在，则不创建任何对象，直接将池中对象的地址返回，赋给字符串常量。

?????????而采用new关键字新建一个字符串对象时，JVM首先在字符串常量池中查找有没有这个字符串对象，如果有，则不在池中再去创建这个对象了，直接在堆中创建一个字符串对象，然后将堆中的这个对象的地址返回赋给引用，这样，字符串就指向了堆中创建的这个字符串对象；如果没有，则首先在字符串常量池池中创建一个字符串对象，然后再在堆中创建一个字符串对象，然后将堆中这个字符串对象的地址返回赋给引用，这样，字符串指向了堆中创建的这个字符串对象。

????????

????????字符串池的优点就是避免了相同内容的字符串的创建，节省了内存，省去了创建相同字符串的时间，同时提升了性能；另一方面，字符串池的缺点就是牺牲了JVM在常量池中遍历对象所需要的时间，不过其时间成本相比而言比较低。

六、元空间：

之前我们就有提到，在JDK 1.7中HotSpot已经开始了“去永久化”

????????JDK1.7中，存储在永久代的部分数据就已经转移到了Java Heap或者是 Native Heap。但永久代仍存在于JDK1.7中，并没完全移除，譬如符号引用(Symbols)转移到了native heap；字面量(interned strings)转移到了java heap；类的静态变量(class statics)转移到了java heap。

????????去永久化的原因我们在上面已经提到过了，类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难。静态区中类太多有可能撑爆永久代。静态变量或常量也有可能撑爆方法区。并且永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。

????????元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过以下参数来指定元空间的大小：

　　-XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。 　　

   -XX:MaxMetaspaceSize，最大空间，默认是没有限制的。

除了上面两个指定大小的选项以外，还有两个与 GC 相关的属性：　　??????
?

        -XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集 　　

        -XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集

????????所以相比永久代有撑爆的风险，元空间的生命周期一类加载器一致，类加载的时候进行空间分配，就可以更好的控制存储空间。