第25讲 谈谈JVM内存区域的划分，哪些区域可能发生OutOfMemoryError？
今天，我将从内存管理的角度，进一步探索Java虚拟机（JVM）。垃圾收集机制为我们打理了很多繁琐的工作，大大提高了开发的效率，但是，垃圾收集也不是万能的，懂得JVM内部的内存结构、工作机制，是设计高扩展性应用和诊断运行时问题的基础，也是Java工程师进阶的必备能力。
今天我要问你的问题是，谈谈JVM内存区域的划分，哪些区域可能发生OutOfMemoryError？
典型回答
通常可以把JVM内存区域分为下面几个方面，其中，有的区域是以线程为单位，而有的区域则是整个JVM进程唯一的。
首先，程序计数器（PC，Program Counter Register）。在JVM规范中，每个线程都有它自己的程序计数器，并且任何时间一个线程都只有一个方法在执行，也就是所谓的当前方法。程序计数器会存储当前线程正在执行的Java方法的JVM指令地址；或者，如果是在执行本地方法，则是未指定值（undefined）。
第二，Java虚拟机栈（Java Virtual Machine Stack），早期也叫Java栈。每个线程在创建时都会创建一个虚拟机栈，其内部保存一个个的栈帧（Stack Frame），对应着一次次的Java方法调用。
前面谈程序计数器时，提到了当前方法；同理，在一个时间点，对应的只会有一个活动的栈帧，通常叫作当前帧，方法所在的类叫作当前类。如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，成为新的当前帧，一直到它返回结果或者执行结束。JVM直接对Java栈的操作只有两个，就是对栈帧的压栈和出栈。
栈帧中存储着局部变量表、操作数（operand）栈、动态链接、方法正常退出或者异常退出的定义等。
第三，堆（Heap），它是Java内存管理的核心区域，用来放置Java对象实例，几乎所有创建的Java对象实例都是被直接分配在堆上。堆被所有的线程共享，在虚拟机启动时，我们指定的“Xmx”之类参数就是用来指定最大堆空间等指标。
理所当然，堆也是垃圾收集器重点照顾的区域，所以堆内空间还会被不同的垃圾收集器进行进一步的细分，最有名的就是新生代、老年代的划分。
第四，方法区（Method Area）。这也是所有线程共享的一块内存区域，用于存储所谓的元（Meta）数据，例如类结构信息，以及对应的运行时常量池、字段、方法代码等。
由于早期的Hotspot JVM实现，很多人习惯于将方法区称为永久代（Permanent Generation）。Oracle JDK 8中将永久代移除，同时增加了元数据区（Metaspace）。
第五，运行时常量池（Run-Time Constant Pool），这是方法区的一部分。如果仔细分析过反编译的类文件结构，你能看到版本号、字段、方法、超类、接口等各种信息，还有一项信息就是常量池。Java的常量池可以存放各种常量信息，不管是编译期生成的各种字面量，还是需要在运行时决定的符号引用，所以它比一般语言的符号表存储的信息更加宽泛。
第六，本地方法栈（Native Method Stack）。它和Java虚拟机栈是非常相似的，支持对本地方法的调用，也是每个线程都会创建一个。在Oracle Hotspot JVM中，本地方法栈和Java虚拟机栈是在同一块儿区域，这完全取决于技术实现的决定，并未在规范中强制。
考点分析
这是个JVM领域的基础题目，我给出的答案依据的是JVM规范中运行时数据区定义，这也和大多数书籍和资料解读的角度类似。
JVM内部的概念庞杂，对于初学者比较晦涩，我的建议是在工作之余，还是要去阅读经典书籍，比如我推荐过多次的《深入理解Java虚拟机》。
今天这一讲作为Java虚拟机内存管理的开篇，我会侧重于：
- 分析广义上的JVM内存结构或者说Java进程内存结构。
- 谈到Java内存模型，不可避免的要涉及OutOfMemory（OOM）问题，那么在Java里面存在哪些种OOM的可能性，分别对应哪个内存区域的异常状况呢？
注意，具体JVM的内存结构，其实取决于其实现，不同厂商的JVM，或者同一厂商发布的不同版本，都有可能存在一定差异。我在下面的分析中，还会介绍Oracle Hotspot JVM的部分设计变化。
知识扩展
首先，为了让你有个更加直观、清晰的印象，我画了一个简单的内存结构图，里面展示了我前面提到的堆、线程栈等区域，并从数量上说明了什么是线程私有，例如，程序计数器、Java栈等，以及什么是Java进程唯一。另外，还额外划分出了直接内存等区域。
这张图反映了实际中Java进程内存占用，与规范中定义的JVM运行时数据区之间的差别，它可以看作是运行时数据区的一个超集。毕竟理论上的视角和现实中的视角是有区别的，规范侧重的是通用的、无差别的部分，而对于应用开发者来说，只要是Java进程在运行时会占用，都会影响到我们的工程实践。
我这里简要介绍两点区别：
- 直接内存（Direct Memory）区域，它就是我在专栏第12讲中谈到的Direct Buffer所直接分配的内存，也是个容易出现问题的地方。尽管，在JVM工程师的眼中，并不认为它是JVM内部内存的一部分，也并未体现JVM内存模型中。
- JVM本身是个本地程序，还需要其他的内存去完成各种基本任务，比如，JIT Compiler在运行时对热点方法进行编译，就会将编译后的方法储存在Code Cache里面；GC等功能需要运行在本地线程之中，类似部分都需要占用内存空间。这些是实现JVM JIT等功能的需要，但规范中并不涉及。
如果深入到JVM的实现细节，你会发现一些结论似乎有些模棱两可，比如：
- Java对象是不是都创建在堆上的呢？
我注意到有一些观点，认为通过逃逸分析，JVM会在栈上分配那些不会逃逸的对象，这在理论上是可行的，但是取决于JVM设计者的选择。据我所知，Oracle Hotspot JVM中并未这么做，这一点在逃逸分析相关的文档里已经说明，所以可以明确所有的对象实例都是创建在堆上。
- 目前很多书籍还是基于JDK 7以前的版本，JDK已经发生了很大变化，Intern字符串的缓存和静态变量曾经都被分配在永久代上，而永久代已经被元数据区取代。但是，Intern字符串缓存和静态变量并不是被转移到元数据区，而是直接在堆上分配，所以这一点同样符合前面一点的结论：对象实例都是分配在堆上。
接下来，我们来看看什么是OOM问题，它可能在哪些内存区域发生？
首先，OOM如果通俗点儿说，就是JVM内存不够用了，javadoc中对OutOfMemoryError的解释是，没有空闲内存，并且垃圾收集器也无法提供更多内存。
这里面隐含着一层意思是，在抛出OutOfMemoryError之前，通常垃圾收集器会被触发，尽其所能去清理出空间，例如：
- 我在专栏第4讲的引用机制分析中，已经提到了JVM会去尝试回收软引用指向的对象等。
- 在java.nio.BIts.reserveMemory() 方法中，我们能清楚的看到，System.gc()会被调用，以清理空间，这也是为什么在大量使用NIO的Direct Buffer之类时，通常建议不要加下面的参数，毕竟是个最后的尝试，有可能避免一定的内存不足问题。
当然，也不是在任何情况下垃圾收集器都会被触发的，比如，我们去分配一个超大对象，类似一个超大数组超过堆的最大值，JVM可以判断出垃圾收集并不能解决这个问题，所以直接抛出OutOfMemoryError。
从我前面分析的数据区的角度，除了程序计数器，其他区域都有可能会因为可能的空间不足发生OutOfMemoryError，简单总结如下：
- 堆内存不足是最常见的OOM原因之一，抛出的错误信息是“java.lang.OutOfMemoryError:Java heap space”，原因可能千奇百怪，例如，可能存在内存泄漏问题；也很有可能就是堆的大小不合理，比如我们要处理比较可观的数据量，但是没有显式指定JVM堆大小或者指定数值偏小；或者出现JVM处理引用不及时，导致堆积起来，内存无法释放等。
- 而对于Java虚拟机栈和本地方法栈，这里要稍微复杂一点。如果我们写一段程序不断的进行递归调用，而且没有退出条件，就会导致不断地进行压栈。类似这种情况，JVM实际会抛出StackOverFlowError；当然，如果JVM试图去扩展栈空间的的时候失败，则会抛出OutOfMemoryError。
- 对于老版本的Oracle JDK，因为永久代的大小是有限的，并且JVM对永久代垃圾回收（如，常量池回收、卸载不再需要的类型）非常不积极，所以当我们不断添加新类型的时候，永久代出现OutOfMemoryError也非常多见，尤其是在运行时存在大量动态类型生成的场合；类似Intern字符串缓存占用太多空间，也会导致OOM问题。对应的异常信息，会标记出来和永久代相关：“java.lang.OutOfMemoryError: PermGen space”。
- 随着元数据区的引入，方法区内存已经不再那么窘迫，所以相应的OOM有所改观，出现OOM，异常信息则变成了：“java.lang.OutOfMemoryError: Metaspace”。
- 直接内存不足，也会导致OOM，这个已经专栏第11讲介绍过。
今天是JVM内存部分的第一讲，算是我们先进行了热身准备，我介绍了主要的内存区域，以及在不同版本Hotspot JVM内部的变化，并且分析了各区域是否可能产生OutOfMemoryError，以及OOME发生的典型情况。
一课一练
关于今天我们讨论的题目你做到心中有数了吗？今天的思考题是，我在试图分配一个100M bytes大数组的时候发生了OOME，但是GC日志显示，明明堆上还有远不止100M的空间，你觉得可能问题的原因是什么？想要弄清楚这个问题，还需要什么信息呢？
请你在留言区写写你对这个问题的思考，我会选出经过认真思考的留言，送给你一份学习奖励礼券，欢迎你与我一起讨论。
你的朋友是不是也在准备面试呢？你可以“请朋友读”，把今天的题目分享给好友，或许你能帮到他。
- I am a psycho 👍（310） 💬（3）
如果仅从jvm的角度来看，要看下新生代和老年代的垃圾回收机制是什么。如果新生代是serial，会默认使用copying算法，利用两块eden和survivor来进行处理。但是默认当遇到超大对象时，会直接将超大对象放置到老年代中，而不用走正常对象的存活次数记录。因为要放置的是一个byte数组，那么必然需要申请连续的空间，当空间不足时，会进行gc操作。这里又需要看老年代的gc机制是哪一种。如果是serial old，那么会采用mark compat，会进行整理，从而整理出连续空间，如果还不够，说明是老年代的空间不够，所谓的堆内存大于100m是新+老共同的结果。如果采用的是cms(concurrent mark sweep)，那么只会标记清理，并不会压缩，所以内存会碎片化，同时可能出现浮游垃圾。如果是cms的话，即使老年代的空间大于100m，也会出现没有连续的空间供该对象使用。
2018-07-03 - Len 👍（44） 💬（1）
从不同的垃圾收集器角度来看： 首先，数组的分配是需要连续的内存空间的（据说，有个别非主流JVM支持大数组用不连续的内存空间分配🤔）。所以： 1）对于使用年轻代和老年代来管理内存的垃圾收集器，堆大于 100M，表示的是新生代和老年代加起来总和大于100M，而新生代和老年代各自并没有大于 100M 的连续内存空间。 进一步，又由于大数组一般直接进入老年代（会跳过对对象的年龄的判断），所以，是否可以认为老年代中没有连续大于 100M 的空间呢。 2）对于 G1 这种按 region 来管理内存的垃圾收集器，可能的情况是没有多个连续的 region，它们的内存总和大于 100M。 当然，不管是哪种垃圾收集器以及收集算法，当内存空间不足时，都会触发 GC，只不过，可能 GC 之后，还是没有连续大于 100M 的内存空间，于是 OOM了。
2018-07-03 - 夏洛克的救赎 👍（20） 💬（1）
Tomcat运行中突然出现java.lang.OutOfMemoryError: PermGen space有什么工具可以排查原因吗？
2019-01-14 - 任鹏斌 👍（19） 💬（1）
老师既然元数据区也存在溢出，那么为什么要用元数据区替换永久代呢，有什么好处吗？
2018-08-06 - markin 👍（17） 💬（1）
老师，能否跟我们介绍一下您平时获取资料的渠道。比如apache的一些开源项目，官网上就有很丰富的文档。但是我们获取jvm相关文档的渠道少之又少，无非就是博客或者书籍，这些都比较繁杂，并且可能参杂着很多难以识别的错误观点。授人以鱼不如授人以渔，先谢谢老师了。
2018-07-08 - 爱吃芒果的董先森 👍（12） 💬（1）
因为给数组分配的是连续地址，而显示的是总的地址，不管是不是连续的。
2018-07-03 - tyson 👍（10） 💬（1）
堆内存100M 包含了新生代(eden+s0+1)和老年代，大对象一般分配在老年代，那么最有可能在分配过程中老年代的空间不足。
2018-07-03 - 鹅米豆发 👍（9） 💬（1）
可能一，新生代没有足够的连续空间，且不能直接在老年代分配。比如E+S0+S1>100MB，但E<100MB，S0<100MB。 可能二，大对象直接进入老年代，但老年代也没有足够的连续空间。参数+XX:PretenureSizeThreshold。 可能三，线程数量太多，导致物理内存不足。 可能四，直接内存使用太多，导致物理内存不足。
2018-07-03 - 李二木 👍（4） 💬（1）
老师，关于这篇文章留的问题你可以给个你的答案吗？
2018-07-05 - 代码狂徒 👍（3） 💬（1）
老师，您是说方法区就是有永久代？那也就是说方法区在jdk8中已经不存在了？元数据区跟方法区有什么区别呢？那您的图是jdk7的图，有8得图吗？求解
2018-07-10 - 一个坏人 👍（2） 💬（1）
老师好，请教一个问题。JMM 模型中 各种内存分区 是逻辑分区的。JVM会根据参数计算每一块分区的起始地址、结束地址？如果会，什么时候执行这一操作呢？每一块区域有规定的顺序么？
2018-07-18 - boom 👍（2） 💬（1）
小白请教一个不相关的问题～java 内存模型跟 jvm内存模型的区别与联系是啥呢～
2018-07-03 - 未完的歌 👍（2） 💬（1）
有可能是内存碎片化问题，或者是大对象的内存分配策略问题。 需要了解一下积极垃圾收集算法，例如Mark Sweep就会造成内存碎片化问题，另外内存分配策略也是一个关注点。
2018-07-03 - Geek_6m7v5y 👍（1） 💬（1）
老师，你好。看了文章后查一些资料。都有这段话：元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。 这里说的本地内存是不是和你文中说的直接内存是一个概念？
2018-11-15 - 三口先生 👍（1） 💬（1）
堆内存比例设置不合理
2018-07-03