Java内存区域与内存溢出异常之运行时数据区域

Java与C++之间又一堵由内存动态分配和垃圾收集技术所围成的高墙，墙外面的想进去，墙里面的人却想出来。

对于C、C++来说，开发人员在内存管理领域是拥有最高权力，但同时也承担了对所有对象的维护责任；而对于Java程序员来说，在虚拟机自动内存管理制度的帮助下，不容易出现内存泄漏和内存溢出的问题，但是一旦出现了问题后要进行排查错误和修正问题会成为一项艰难的工作。
相对来说Java适合来对进行迭代快的产品的开发如网站、APP的后台。

运行时数据区域

程序计数器

较小的内存空间，可以看作是当前线程所执行字节码的行号指示器。
线程私有，如果线程正在执行的是Native方法，则这个计数器值应为空。
此内存区域是唯一一个在《Java虚拟机规范》中没有规定任何OutOfMemoryError情况的区域。

Java虚拟机栈

线程私有，用来描述Java方法执行的线程内存模型：
每个方法被执行的时候，Java虚拟机都会同步创建一个栈帧用于存储局部变量表、操作数栈、动态连接、方法出口等信息。
局部变量表存放了编译期可知的各种Java虚拟机基本数据类型、对象引用和returnAddress类型。
《Java虚拟机规范》中，对这个内存区域规定了两类异常状况：
当线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError；
如果Java虚拟机栈可以动态扩展，当栈扩展时无法申请到足够的内存会抛出OutOfMemoryError；
值得注意的是HotSpot虚拟机的栈容量是不可以扩展的，只要线程成功申请了栈空间就不会有OOM,但是申请失败的话还是会有OOM。

本地方法栈

类似于虚拟机栈，为虚拟机执行本地方法服务。

Java堆

对于Java应用程序来说，Java堆是虚拟机所管理的内存中最大的一块，Java堆被所有线程共享，用于存放对象实例。

从回收内存的角度

Java堆是垃圾收集器管理的内存区域，从回收内存的角度来看，现代垃圾收集器大部分都是基于分代收集理论设计的，所以Java堆中会出现新生代，老年代，永久代等区域，新生代又会分为Eden，From Survivor，To Survivor
但是今天，垃圾收集器技术在不断进步，出现了不采用分代设计的新垃圾收集器。

从分配内存的角度

所有线程共享的Java堆可以划分出多个线程私有的分配缓冲区（TLAB）

堆的存储空间

Java堆可以处于物理上不连续的内存空间，但逻辑上应该被视为连续的，但是对于大对象如数组，多数虚拟机实现出与简单高效的考虑，很可能会要求连续的内存空间
Java堆可扩展，通过-Xmx和-Xms设定，如果在Java堆中没有内存完成实例分配，并且堆也无法再扩展时，会抛出OutOfMemoryError异常。

方法区

线程共享，用于存储被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据
JDK8以前的HotSpot虚拟机用永久代来实现方法区，但是这么做会导致Java应用更容易遇到内存溢出的问题。
再JDK6开始HotSpot开始计划放弃永久代用本地内存来实现方法区，JDK7的HotSpot已经把字符串常量池、静态变量移出了，JDK8也就完全废弃了永久代，改用在本地内存中实现的元空间来代替。
如果方法区无法满足新的内存分配需求的时候，将抛出OutOfMemoryError异常。

运行时常量池

运行时常量池是方法区的一部分，Class文件中有一项信息为常量池表，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。
运行时常量池是动态的，运行期间也可以将新的常量放入池中，这种特性被利用的比较多的是String类的intern()方法。
申请不到内存时会抛出OutOfMemory异常。

直接内存

直接内存并不是虚拟机运行时数据区的一部分，但是这部分内存被频繁的使用，而且也可能导致OutOfMemoryError的出现。
在JDK1.4中加入的NIO类，引入了基于Channel和Buffer的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过存储在Java堆里的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。
直接内存不会收到Java堆大小的限制但是会受到本机总内存限制，所以会出现OutOfMemoryError。