JVM（一）-内存区域与内存溢出
参考：《深入理解JVM——高级特性与最佳实践》
一、运行时的数据区域
数据区的线程隔离和线程共享
程序计数器
当前线程所执行的字节码的行号指示器，保证线程切换之后能回到正确的执行位置，是唯一一个在java虚拟机规范中没有规定OOM情况的区域。
虚拟机栈
生命周期与线程相同，描述的是java方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame）用于存局部变量表、操作栈、动态链接、方法出口等。每一个方法被调用至执行完的过程，就对应着一个栈帧在虚拟机中从入栈到出栈的过程。
局部变量表存放了编译期间可知的各种基本数据类型，所需要的内存在编译期间完成分配，在运行期间不会改变局部变量表的大小。
两种异常：
StackOverflowError线程请求的栈深度大于虚拟机所允许的深度;
OutOfMemoryError虚拟机动态扩展时（使运行中的程序去调用在源代码中未曾提及的，而是在程序运行中决定的类型）无法申请到足够的内存时。
本地方法栈
虚拟机栈为执行java服务，本地栈为使用到的Native方法服务。
两种异常：
StackOverflowError
OutOfMemoryError
java堆
在虚拟机启动的时候创建，目的是存放对象实例，是垃圾收集器管理的主要区域，也被成为GC堆。
java堆可以处于物理上不连续的内存空间中，堆内存可扩展（-Xmx -Xms）。
OutOfMemory：在堆中没有内存完成实例分配，且堆无法扩展。
方法区
存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码，物理上不连续的内存空间。垃圾回收行为在这个区域比较少见，主要针对常量池的回收和对类型的卸载。
运行时常量池是方法区的一部分，存放编译期生成的各种字面量、符号引用和翻译出来的直接引用（chapter-6）。
OutOfMemory：方法区无法满足内存分配需求时（常量池无法再申请到内存时）。
直接内存
并不是虚拟机运行时数据区的一部分，也不是虚拟机规范定义的内存区域。NIO（new I/O）类，引入了基于通道（channel）与缓冲区（Buffer）的I/O方式，使用Native函数直接分配堆外内存，然后通过java堆里的DirectByteBuffer对象操作这块内存，避免了在java堆和Native堆中来回复制数据。
OufOfMemoryError：各内存区域的总和大于物理内存限制。
二、对象创建
- 类的加载：先去常量池中查是否能定位到一个类的符号引用（chapter-7），检查这个符号引用所代表的类是否已经被加载。
- 为新生对象分配内存：指针碰撞法、空闲列表。为了保证线程安全，采用TLAB（-XX：+UseTLAB）或CAS+失败重试的方法分配内存。
- 将内存空间初始化为0.
- 设置对象。对象在存储中的布局分为对象头（运行时数据<如哈希码、GC分代表、锁状态、县线程锁等>和类型指针<即对象指向它的类元数据的指针，来确定是哪个类的实例>）、实例数据、对齐填充。
- 调用init方法。
三、对象访问
object obj = new Object();
object obj反应到java栈的本地变量表中，作为一个reference类型数据出现；new Object()反应到java堆中，形成一块存储了Object类型所有实例数据值的结构化内存，还必须包含能找到此对象类型数据（对象类型、父类、实现接口、方法等）的地址，这些类型数据则存在方法区中。
reference类型在java虚拟机规范里只规定了一个指向对象的引用，并没有定义这个应用通过哪种方法定位，以及访问到java堆中的对象的具体位置。两种方法：
- 使用句柄：reference存的是对象句柄地址，好处是稳定
- 直接指针：存的是对象地址，好处是速度更快
四、OOM异常
- java堆溢出
不断的床架对象，并保证CG Roots到对象有可达路径来避免GC清除这些对象
配置-XX:+HeapDumpOnOutOfMemoryError内存异常时转储快照 - 虚拟机栈和本地方法栈溢出
单线程时，栈帧太大或虚拟机栈容量太小，内存无法分配时都抛出StackOverflowError
多线程时，不断建立线程产生OOM
-Xoss设置本地方法栈大小
-Xss设置栈容量
如果是建立线程过多造成的OOM，解决方案：减少线程数、更换64位虚拟机、减少最大堆内存（Xmx）、减少栈容量（Xss）、减少最大方法区容量（MaxPermSize）。 - 常量池溢出，向运行时常量池添加内容，使用
String.intern()。 - 方法区溢出，运行时产生大量的类。
- 本机直接内存溢出，通过
-XX:MaxDirectMemorySize指定，若不指定，和Xmx一样。
