（十二）JVM内存空间划分与作用详解

1.JVM内存空间

• 虚拟机栈：Stack Frame 栈帧
• 程序计数器
• 本地方法栈：主要处理本地方法
• 堆（Heap）:栈中引用指向堆内村对象地址，对象分为两部分对象本身真正拥有的实例数据，对象所属的类型（元数据信息，只拥有一部分），储存在方法区（堆内）。这样方式在垃圾回收的时候，指针的移动的频率相当高。
  • 第一种方式：栈中引用不是指向对象本身，堆中对象拥有真正实例数据的指针和元数据指针，实例数据指向另一块堆内地址，但是元数据指针依然指向方法区中的类元数据的地址。。
  • 第二种方式：栈中引用不是指向对象本身，堆中对象直接存放真正实例数据，但是元数据指针依然指向方法区中的类元数据的地址。（HostPot采用这种方式）
  • 差异：发生垃圾回收的概率较高，不同的垃圾回收算法不一样，但是都会涉及到压缩，压缩一定有对象的移动，为了腾出更大的连续空间存放对象。
• 方法区：存储元信息。永久代（Permanet Generation），很少发生垃圾回收机制，易发生内存溢出，JDK1.8彻底废除，使用元空间（meta space）.
• 运行时常量池：方法区的一部分内容。
• 直接内存：Direct Memory 堆外内存，很难进行垃圾回收。
  

2. 运行时数据区域

由于直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。但是这部分内存也被频繁地使用，而且也可能导致内存溢出异常（OutOfMemoryError）出现，所以也放到这部分进行介绍。

Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途以及创建和销毁的时间。有的区域（线程共享的数据区域）随着虚拟机的启动而存在，有的区域（线程隔离的数据区域）则要依赖用户线程的启动和结束来创建或者是销毁。

2.1 程序计数器

程序计数器（Program Counter Register）是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里（仅是概念模型，各种虚拟机可能会通过一些更高效的方式去实现），字节码解释器工作时就是通过改变这个计算器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。

由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）都会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立储存，我们称这类内存区域为“线程私有”的内存。

2.2 Java虚拟机栈

与程序计数器一样，Java虚拟机栈（Java Virtual Machine Stacks） 也是线程私有的，它的生命周期与线程相同。虚拟机描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应这一个栈帧在虚拟机栈中入栈和出栈的过程。

大多数程序员理解的栈就是虚拟机栈中局部变量表部分，我们现在所讲的就是Java虚拟机栈。

局部变量存放了编译器可知的各种基本数据类型、对象引用（reference类型，它不等同与对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他于此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）。

其中64位长度的long和double类型的数据占用2个局部变量空间（Slot）,其余的数据类型只占用1个。局部变量表所需要的内存空间在编译时期完成分配。当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。

在Java虚拟机规范中，对这个区域规定了两种异常状况：如果线程请求的的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常：如果虚拟机栈可以动态扩展（当前大部分的Java虚拟机都可动态扩展，只不过Java虚拟机中也允许固定长度的虚拟机栈），如果扩展时无法申请到足够的内存，就会跑出OutOfMemoryError异常。

2.3 本地方法栈

本地方法栈（Native Method Stack)与虚拟机栈所发挥的作用是非常相似的，他们之间的区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。在虚拟机规范中对本地栈中方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机直接就把本地方法栈和虚拟机栈合二为一。

2.4 Java堆

对于大多数应用来说，Java堆（Java Heap）是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。这一点在Java虚拟机规范中的描述是：所有的对象实例以及数组都要在堆上分配，但是随着JIT编译器的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化产生，所有的对象分配在堆上也渐渐变得不是那么“绝对”了。

Java堆是垃圾收集器管理的主要区域，因此很多时候也被称为“GC堆”。Java堆还可以细分为新生代和老年代等等。这一部分在讲垃圾回收算法的时候还会继续介绍。

根据Java虚拟机规范规定，Java堆可以处于物理上不连续的内存空间中，即只要逻辑上是连续的即可，就像我们磁盘空间一样。在实现时，可以固定大小，也可是可拓展的，主流的虚拟机都是按照可拓展来实现的（通过-Xmx和-Xms来控制）。如果在堆中没有内存完成实例分配，并且堆也无法继续拓展时，将会抛出OutOfMemortError异常。

2.5方法区

方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java虚拟机将其描述为堆的一个逻辑部分，但是它却有一个别名叫做Non-Heap（非堆）。目的是与Java堆区分开来。（以前很多人把方法区称为永久代，现在JDK1.8中已经用元数据区域取代了永久代）。

在jdk1.8中，永久代已经不存在，存储的类信息、编译后的代码数据等已经移动到了元空间（MetaSpace）中，元空间并没有处于堆内存上，而是直接占用的本地内存（NativeMemory）。

对于习惯在HotSpot虚拟机上开发、部署程序的开发者来说，很多人都更愿意把方法区成为"永久代",本质上两者不等价，仅仅是因为HotSpot虚拟机的设计团队选择把GC分带收集扩展至方法区，或者说使用永久代实现方法区而已，这样HotSpot的垃圾收集器可以想管理Java堆一样管理这部分内存，能够专门为方法区编写管理代码的工作。使用永久代来实现方法区，现在看来并不是一个好主意，因为这样风更容易遇到内存溢出问题，因此，对于HotSpot虚拟机，放弃永久代并逐步改为采用Native Memory来实现方法区的规划，字符串常量池已经被溢出。

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

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

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

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

在Java7之前，HotSpot虚拟机中将GC分代收集扩展到了方法区，使用永久代来实现了方法区。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载。而在Java8中，已经彻底没有了永久代，将方法区直接放在一个与堆不相连的本地内存区域，这个区域被叫做元空间。

常量池里存储着字面量和符号引用。

符号引用包括：1.类的全限定名，2.字段名和属性，3.方法名和属性。

字符串池里的内容是在类加载完成，经过验证，准备阶段之后在堆中生成字符串对象实例，然后将该字符串对象实例的引用值存到string pool中（记住：string pool中存的是引用值而不是具体的实例对象，具体的实例对象是在堆中开辟的一块空间存放的。）。 在HotSpot VM里实现的string pool功能的是一个StringTable类，它是一个哈希表，里面存的是驻留字符串(也就是我们常说的用双引号括起来的)的引用（而不是驻留字符串实例本身），也就是说在堆中的某些字符串实例被这个StringTable引用之后就等同被赋予了”驻留字符串”的身份。这个StringTable在每个HotSpot VM的实例只有一份，被所有的类共享。

1. 字符串池常量池在每个VM中只有一份，存放的是字符串常量的引用值,存放在堆中.
2. class常量池是在编译的时候每个class都有的，在编译阶段，存放的是常量的符号引用。
3. 运行时常量池是在类加载完成之后，将每个class常量池中的符号引用值转存到运行时常量池中，也就是说，每个class都有一个运行时常量池，类在解析之后，将符号引用替换成直接引用，与全局常量池中的引用值保持一致。

2.6 运行时常量池

运行时常量池是方法区（Runtime Constant Pool）的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息就是常量池，用于存放编译时期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。

Java虚拟机对Class文件每一部分的格式都有严格规定，每一个字节用于储存那种数据都必须符合规范上面的要求才会被虚拟机认可、装载和执行。但对于运行时常量池没有做任何细节的要求。不过，一般来说，出了保存Class文件中描述的符号引用外，还会把翻译出来的直接引用也储存在运行时常量池中。

运行时常量池具备动态性，Java语言并不要求常量一定只有编译期才能产生，也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的便是String类的intern()方法。

在JDK1.7之前运行时常量池逻辑包含字符串常量池存放在方法区, 此时hotspot虚拟机对方法区的实现为永久代

在JDK1.7 字符串常量池被从方法区拿到了堆中, 这里没有提到运行时常量池,也就是说字符串常量池被单独拿到堆,运行时常量池剩下的东西还在方法区, 也就是hotspot中的永久代

在JDK1.8 hotspot移除了永久代用元空间(Metaspace)取而代之, 这时候字符串常量池还在堆, 运行时常量池还在方法区, 只不过方法区的实现从永久代变成了元空间(Metaspace)

• 对于直接做+运算的两个字符串（字面量）常量，并不会放入字符串常量池中，而是直接把运算后的结果放入字符串常量池中
  (String s = “abc”+ “def”, 会直接生成“abcdef"字符串常量 而不把 “abc” "def"放进常量池)
• 对于先声明的字符串字面量常量，会放入字符串常量池，但是若使用字面量的引用进行运算就不会把运算后的结果放入字符串常量池中了
  (String s = new String(“abc”) + new String(“def”),在构造过程中不会生成“abcdef"字符串常量)
• 总结一下就是JVM会对字符串常量的运算进行优化，未声明的，只放结果；已经声明的，只放声明
  常量池中同时存在字符串常量和字符串引用。直接赋值和用字符串调用String构造函数都可能导致常量池中生成字符串常量;而intern()方法会尝试将堆中对象的引用放入常量池
• String str1 = “a”;
  String str2 = “b”;
  String str4 = str1 + str2; //该语句只在堆中生成一个对象(str4)
  
  这句被Java编译器做了优化, 实际上使用StringBuilder实现的(不在堆里生成str1和str2对象)
• String str5 = new String(“ab”);只在堆中生成了一个对象str5, 不在字符换常量池中创建字面量"ab"

2.7 直接内存

由于直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。但是这部分内存也被频繁地使用，而且也可能导致内存溢出异常（OutOfMemoryError）出现，所以也放到这部分进行介绍。

在JDK1.4中新加入了NIO类，引入了一种基于通道与缓冲区的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存中的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。

显然，本机直接内存的分配不会受到Java堆大小的限制。但是肯定还是会受到本机总内存大小以及处理器寻址空间的限制。管理员在配置虚拟机参数时，会根据实际内存设置-Xmx等参数信息，但经常忽略直接内存，使得各个内存区域总和大于物理内存限制（包括物理的和操作系统级的限制），从而导致动态拓展时出现OutOfMemoryError异常。

3. 对象

https://www.cnblogs.com/iceAeterNa/p/4877741.html

https://www.cnblogs.com/hewenwu/p/3662529.html

https://www.cnblogs.com/wxw7blog/p/7349204.html

3.1 对象的创建

在Java程序当中每时每刻都有对象被创建出来。在语言层面上，创建对象通常仅仅是使用一个new关键字而已，而在虚拟机中，对象（仅限于普通Java对象）的创建又是怎样一个过程呢？

虚拟机遇到一条new指令时，首先将去检查这个指令的参数能否在常量池中定位到一个类的符号引用。并且检查这个符号引用代表的类是否已经被加载、解析和初始化过。如果没有，那就先执行类加载的过程。

在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成之后便可完全确定（在对象的内存布局部分会介绍）。

为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来。有两种方式：

• 指针碰撞：假设Java堆中内存是规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那分配内存就是将指针往空间空间挪动一段与对象大小相等的距离，这种分配内存的方式就被称为指针碰撞；
• 空闲列表：如果Java堆中的内存并不是规整的，已经使用的内存和空闲内存相互交错，那就没有办法简单地使用指针碰撞的方法进行内存分配了。虚拟机此时必须维护一个列表用来记录哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间为分配给对象实例，并且更新列表上的记录，这种分配方式就被称为空闲列表。

除了如何划分可用空间之外，还要考虑的一个问题就是对象创建在虚拟机中是非常频繁的行为，即使是仅仅修改一个指针的位置，在并发的情况之下也并不是线程安全的----可能出现正在给对象A分配内存，指针还没来得及修改，对象B同时使用了原来的指针来分配内存的情况。解决方案也有两种：

• 一种是对分配内存空间的动作进行同步处理----实际上虚拟机采用CAS配上失败重试的方式保证更新操作的原子性；
• 另一种是把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程缓冲分配（Thread Local Allocation Buffer，TLAB）。哪个线程需要分派内存，就在哪个线程的TLAB上分配，只有TLAB用完并分配新的TLAB时，才需要同步锁定。虚拟机是否使用TLAB，可以通过-XX:+/-UseTLAB参数来设定。

内存分配完成之后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），如果使用TLAB，则此工作可以提前至TLAB分配时进行。这一步操作保证了对象的实例字段在Java代码中可以不赋初值就可以直接使用，程序能访问到这些字段的数据类型所对应的零值。

接下来，虚拟机要对对象进行一些必要的设置，比如这个对象是哪个类的实例、如何才能找到类的元数据、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头之中，根据虚拟机当前的运行状态的不同，如是是否启用偏向锁等，对象头会有不同的设置方式。

在上面的工作完成之后，从虚拟机的角度来看，一个新的对象已经产生了。但从Java程序的角度来看，对象创建才刚刚开始----方法还没执行，所有的字段都还为零。一般来说（由字节码中是否跟随invokespecial指令所决定），执行new指令之后会接着执行方法，把对象按照程序员的意愿进行初始化，这样一个真正的对象才算创建完成。

3.2 对象的内存布局

在HotSpot虚拟机中，对象在内存中存储的布局可以分为3块区域：对象头、实例数据和对其填充。

HotSpot虚拟机的对象头包括两部分信息，第一部分用于存储对象自身的运行时数据，如哈希吗、GC分代年龄、锁状态标志、线程持有的锁、线程线程ID、偏向时间戳等，这部分数据的长度在32位和64位的虚拟机（未开启压缩指针）中分别为32bit和64bit，官方称它位"Mark Word".对象需要存储的运行时数据很多，其实已经超出了32位、64位Bitamp结构所能记录的限度，但是对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的信息，它会根据对象的状态服用自己的存储空间。例如，在32位的HotSpot虚拟机中，如果对象处于未被锁定的状态下，那么Mark Word的32 bit 空间中的25bit用于存储对象哈希吗，4bit储存对象分代年龄，2bit用于存储锁标志位，1bit固定为0，而在其他状态（轻量级锁定、重量级锁定、GC标记、可偏向）下对象的存储内容。

对象头的另外一部分是类型指针，及对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。并不是所有的虚拟机实现都必须在对象数据上保留类型指针，换句话说，查找对象的元数据信息并不一定要经过对象本身。另外，如果对象是一个Java数组，那在对象头中还必须有一块用于记录数组长度的数据 ，因为虚拟机中可以通过普通Java对象的元数据信息确定Java对象的大小，但是从数据的元数据中却无法确定数组的大小。

实例数据

实例数据部分是对象真正存储的有效信息，也是在程序代码中所定义的各种类型的字段内容。无论是从父类继承下来的，还是在子类中定义的，都需要记录起来。这部分的存储顺序会受到虚拟机分配策略参数和字段在Java源码中定义顺序的影响。

对齐填充

对齐填充并不是必然存在的，也没有特殊的含义，它仅仅起着占位符的作用。由于HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说，就是对象的大小必须是8字节的整数倍。而对象头部分正好是8字节的倍数（一倍或者两倍），因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。

3.3 对象的访问定位

建立对象是为了使用对象，我们的Java程序需要通过栈上的reference数据来操作堆上的具体对象。由于reference类型在Java虚拟机规范中只规定了一个指向对象的引用，并没有定义这个引用应该通过何种方式去定位、访问堆中的对象的具体位置，所以对象访问方式也是取决于虚拟机实现而定的。目前主流的方式有使用句柄和直接指针两种。

• 如果使用句柄的话，那么Java堆中将会划分出一块内存来作为句柄池，reference中存储的就是对象的句柄 地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息
  
• 如果使用直接指针访问，那么Java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，而reference中存储的直接就是对象地址。
  
  这两种对象访问方式各有优势，使用句柄来访问的最大好处就是reference中存储的是稳定的句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）是只会改变举并重的实例数据指针，而reference本身不需要修改。

使用直接指针访问凡是的最大好处就是速度更快，它节省了一次指针定位的时间开销，由于对象的访问在Java中非常频繁，因此这类开销极少成多后也是有一项非常可观的执行成本。我们大多数使用的虚拟机HotSpot而言，它是使用第二种方式进行对象访问的，但从整个软件开发的范围来看，各种语言和框架使用句柄来访句柄的情况也是十分常见。

对象中的内存分配

对象在内存中粗略的布局分为对象头，实例数据，和对齐填充

对象头：包括两部分信息：

• 第一部分 对象自身运行时数据，即实例数据
• 第二部分：类型指针，即对象指向他的类元数据的指针，虚拟机通过这个指针来确定这个对象是那个类的实例

实例数据：对象真正存储的有效信息，也是程序代码定义的各种类型的字段内容

对齐填充不是必然存在的

优缺点：句柄的好处在于：在对象被移动时只会改变句柄中的实例数据指针 ，reference 本身不需要修改

直接指针的好处在于速度够快，他节省了一次指针定位的时间开销，但是由于对象的访问在Java中非常频繁，当开销过多就会形成很大的执行成本

选择哪一种分配方式由Java堆是否规整决定，而Java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。

对象的访问定位：

主流的方式有使用句柄和直接指针两种

• 句柄访问，Java堆将会划分出一块内存referenc来作为句柄池来存储对象的句柄地址
• 指针访问：reference 中存储这对象的地址

3.5 Java堆溢出

Java堆用于存储对象实例，只要不停地创建对象，并且保证GC Roots到对象之间有可达路径类避免垃圾回收机制清除这些对象，那么在对象数量达到最大堆的容量限制后就会产生内存溢出异常。

public class HeapOOM {

    static class OOMObject {

    }
    
    //-XX:+HeapDumpOnOutOfMemoryError
    public static void main(String[] args) {
        List<OOMObject> list = new ArrayList<>();
        while (true) {
            list.add(new OOMObject());
        }
    }
}

3.6 虚拟机栈和本地方法栈溢出

由于在HotSpot虚拟机中并不区分虚拟机栈和本地方法栈，因此，对于HotSpot来说，虽然-Xoss参数设置本地方法栈大小存在，但实际上是无效的，栈容量只有-Xss参数设定。关于虚拟机栈和本地方法栈，在Java虚拟机规范中描述了两种异常：

• 如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常；
• 如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。

这里把异常分为两种情况，看似较为严谨，但却存在着一些互相重叠的地方：当栈空间无法继续分配时，到底是已使用的栈空间太大，还是内存太小，其本质上都只是对同一件事情的两种描述而已。

在笔者的实验中，将实验范围限制于单线程中的操作，尝试了以下两种方法均无法让虚拟机产生OutOfMemoryError异常，尝试的结果都是活的StackOverflowError异常：

• 使用-Xss参数减少栈内存容量，结果跑出StackOverflowError异常，异常出现时输出的堆栈深度相应缩小。

public class JavaVMStackSOF {

    private int stackLength = 1;

    public void stackLeak() {
        stackLength++;
        stackLeak();
    }

    public static void main(String[] args) {
        JavaVMStackSOF oom = new JavaVMStackSOF();
        try {
            oom.stackLeak();
        } catch (Throwable e) {
            System.out.println("stack length:" + oom.stackLength);
            throw e;
        }

    }

}

• 定义了大量的本地变量，增大此方法帧中本地变量表的长度，结果：抛出StackOverflowError异常时输出的堆栈深度相应减小

实验表明：在单个线程下，无论是由于栈帧太大还是虚拟机容量太小，当内存无法分配的时候，虚拟机抛出的异常都是StackOverflowerError异常。

如果测试不限于单线程，通过不断地建立线程的方式倒是可以产生内存溢出异常，如以下代码所示。但是这样产生的内存溢出异常与栈空间是否足够大并不存在任何关联系，或者准确的说，在这种情况下，为每个线程的栈分配的内存越大，反而越容易产生内存溢出异常。

其实原因不难理解，操作系统分配给每个进程的内存是有限制的，比如32位的Windows限制为2GB.虚拟机提供了参数来控制Java堆和方法区的这两部分内存的最大值。剩余的内存为2GB(操作系统限制)减去Xmx(最大堆容量)，在减去MaxPerSize(最大方法区容量)，程序计数器消耗内存很小，可以忽略掉。如果虚拟机进程本身消耗的内存不计算在内，剩下的内存就由虚拟机栈和本地方法栈“瓜分了”。每个线程分配到的栈容量越大，可以建立的线程数量自然越少，建立线程时就越容易把剩下的内存耗尽。

这一点在开发多线程的应用时特别注意，出现StackOverflowError异常时有错误堆栈可以阅读，相对来说，比较容易找到问题所在。而且，如果使用虚拟机默认参数，栈深度在大多数情况下（因为每个方法压入栈的帧大小并不是一样的，所以只能说在大多数情况下）达到1000~2000完全没有问题，对于正常的方法调用（包括递归），这个深度应该完全够用了。但是，如果建立过多线程导致的内存溢出，在不能减少线程数或者更换64位虚拟机的情况下，就只能通过减少最大堆和减少栈容量来换取更多的线程。如果没有这方面的处理经验，这种通过“减少内存”的手段来解决内存溢出的方式会比较难以想到。

public class JavaVMStackOOM {

    private void dontStop() {
        while (true) {

        }
    }

    public void stackLeakByThread() {
        while (true) {
            Thread thread = new Thread(() -> {
                dontStop();
            });
            thread.start();
        }
    }

    /**
     * -Xss2M
     */
    public static void main(String[] args) {
        JavaVMStackOOM oom = new JavaVMStackOOM();
        oom.stackLeakByThread();
    }
}

3.7 方法区和运行时常量池溢出

运行时常量池是方法区的一部分，方法区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。

String.intern()是一个native方法，它的作用是：如果字符串常量池中已经包含了一个等于此String对象的字符串，则返回代表池中这个字符串的String对象；
否则，将此String对象包含的字符串添加到常量池中，并返回此String对象的引用。

在JDK1.6及之前版本中，由于常量池分配在永久代中(即方法区)，我们可以通过-XX:PermSize和-XX:MaxPermSize限制方法区大小，从而间接限制其中常量池的容量，

注意，JDK1.7开始逐步开始“去永久代”。代码如下所示：

/*
 * VM Args: -XX:PermSize=10m -XX:MaxPermSize=10m
 */
public class RuntimeConstantPoolOOM {
    public static void main(String[] args) {
        // 使用List保持着常量池引用，避免Full GC回收常量池行为
        List<String> list = new ArrayList<String>();
        
        int i = 0;
        while (true) {
            list.add(String.valueOf(i++).intern());
        }
    }
}

运行结果：
Exception in thread “main” java.lang.OutOfMemoryError: PermGen space
at java.lang.String.intern(Native Method)
at jvm.RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java:16)

从运行结果中可以看到，运行时常量池溢出，在OutOfMemoryError后面跟随的提示信息是“PermGen space”，说明运行时常量池属于方法区（HotSpot虚拟机中的永久代）的一部分。但是使用JDK1.7运行这段程序不会得到相同的结果，而是出现以下的提示信息，这是因为这两个参数已经不在JDK1.7中使用了。

Java HotSpot™ 64-Bit Server VM warning: ignoring option PermSize=10m; support was removed in 8.0
Java HotSpot™ 64-Bit Server VM warning: ignoring option MaxPermSize=10m; support was removed in 8.0

如果在JDK1.7中运行RuntimeConstantPoolOOM.java程序，while循环将一直运行下去，但是，while循环并不是始终运行下去，直到系统中堆内存用完为止，一般需要过好长时间才会出现，不过笔者并没有在本地测试。因为在JDK1.7中常量池存储的不再是对象，而是对象引用，真正的对象是存储在堆中的。把RuntimeConstantPoolOOM.java运行时的VM参数改为如下所示：

-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError

出现异常提示信息：java.lang.OutOfMemoryError: GC overhead limit exceeded，这里没有提示说堆还是持久代有问题，虚拟机只是告诉你你的程序花在垃圾回收上的时间太多了，却没有什么见效。默认的话，如果你98%的时间都花在GC上并且回收了才不到2%的空间的话，虚拟机才会抛这个异常。这是一个快速失败的安全保障的很好的实践。从运行结果中可以看出， 我们限定了堆的大小后，程序很快就运行异常了，异常信息和之前设想的一样，也就是常量池存储的不再是对象，而是对象引用，真正的对象是存储在堆中的。

关于JDK1.7字符串常量池的实现问题，这里还可以引申一个更有意义的影响，如以下代码所示：

public class StringInternStudyDemo {
    public static void main(String[] args) {
        printJdkVersion();
        testAndPrintResult("计算机", "软件");
        testAndPrintResult("ja", "va");
        testAndPrintResult("ma", "in");
    }

    private static void testAndPrintResult(String prefix, String suffix) {
        String str3 = new StringBuilder(prefix).append(suffix).toString();
        System.out.println(str3.intern() == str3);
    }

    private static void printJdkVersion() {
        String javaVersion = "java.version";
        System.out.println(javaVersion + ":" + System.getProperty(javaVersion));
    }
}

JDK1.8下的执行结果：

java.version:1.8.0_65
true
false
false

JDK1.6下的执行结果：

java.version:1.8.0_65
false
false
false

这段代码在JDK1.6中运行，会得到两个false，而在JDK1.7中运行，会得到一个true和一个false。

产生差异的原因是：

在JDK1.6中，intern()方法会把首次遇到的字符串复制到永久代中，返回的也是永久代中这个字符串的引用，而由StringBuilder创建的字符串实例在Java堆中，所以必然不是同一个引用，将返回false。

而JDK1.7(以及部分其他虚拟机，例如JRockit)的intern()实现不会再复制实例，而是在常量池中记录首次出现的实例引用，因此intern()返回的引用和由StringBuilder创建的那个字符串是同一个。

对str2比较返回false，

是因为"java"字符串在执行StringBuilder()之前就已经出现过，字符串常量池中已经有它的引用了，不符合“首次出现”原则，而“计算机软件”这个字符串则是首次出现的，因此返回true。

如果在Hello.java中添加如下代码的话，返回的结果也是false，证明"main"字符串之前也出现过了。

String str3 = new StringBuilder("ma").append("in").toString();
System.out.println(str3.intern() == str3);