二、java内存区域与内存溢出异常

2.2运行时数据区：

1、程序计数器

一块较小的内存空间，看做线程所执行的字节码的行号指示器，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支，循环，跳转，异常处理，线程恢复就是依赖程序计数器完成。

● Java虚拟机的多线程就是通过线程轮流分配处理器执行时间的方式来实现的。为了确定线程切换后能够恢复到正确的执行位置，每个线程都需要一个独立的程序计数器，各个线程的计数器之间互不影响。独立存储。称线程私有的内存。
● 如果在执行Java方法，计数器记录字节码指令的地址，如果执行Native方法，计数器为空。

2、java虚拟机栈

描述Java方法执行的内存模型，与计数器一般，java虚拟机栈也是线程私有的，它的生命周期与线程相同，每个方法在执行的同时会创建一个栈帧，用于存储局部变量表，操作数栈，动态链表，方法出口等信息。每个方法从调用到执行完成过程，就对应着一个栈帧在虚拟机中入栈到出栈的过程。
● 局部变量表：存储了编译期可知的各种基本数据类型，对象的引用(reference类型，即指向对象起始地址的引用指针)和returnAddress类型(指向一条字节码指令的地址)。long与double类型数据会占用2个局部变量空间，其余的数据类型会占用一个，局部变量表所需要的内存空间在编译期完成分配，当进入一个方法时，方法在帧中分配的局部变量空间是完全确定的。在方法运行期不会改变局部变量表的大小。
● 在Java虚拟机规范中，如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常。如果虚拟机栈可以动态扩展，但扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。

3、本地方法栈

与虚拟机类似，区别是虚拟机栈为虚拟机执行的Java方法服务，而本地方法栈则是为虚拟机使用到的Native方法服务。也会抛出StackOverflowError异常，OutOfMemoryError异常

4、java堆

      此内存区域的唯一目的就是存放对象实例，Java 世界里“几乎”所有的对象实例都在这里分配内存。在《Java虚拟机规范》中对Java堆的描述是：“所有 的对象实例以及数组都应当在堆上分配”，而这里笔者写的“几乎”是指从实现角度来看，随着Java语 言的发展，现在已经能看到些许迹象表明日后可能出现值类型的支持，即使只考虑现在，由于即时编 译技术的进步，尤其是逃逸分析技术的日渐强大，栈上分配、标量替换优化手段已经导致一些微妙 的变化悄然发生，所以说Java对象实例都分配在堆上也渐渐变得不是那么绝对了。  
   从回收内存的角度看，由于现代垃圾收集器大部分都是基于分 代收集理论设计的，所以Java堆中经常会出现“新生代”“老年代”“永久代”“Eden空间”“From Survivor空 间”“To Survivor空间”等名词，这些概念在本书后续章节中还会反复登场亮相，在这里笔者想先说明的 是这些区域划分仅仅是一部分垃圾收集器的共同特性或者说设计风格而已，而非某个Java虚拟机具体 实现的固有内存布局，更不是《Java虚拟机规范》里对Java堆的进一步细致划分。不少资料上经常写着 类似于“Java虚拟机的堆内存分为新生代、老年代、永久代、Eden、Survivor……”这样的内容。   。在十年 之前（以G1收集器的出现为分界），作为业界绝对主流的HotSpot虚拟机，它内部的垃圾收集器全部 都基于“经典分代” 来设计，需要新生代、老年代收集器搭配才能工作，在这种背景下，上述说法还 算是不会产生太大歧义。但是到了今天，垃圾收集器技术与十年前已不可同日而语，HotSpot里面也出 现了不采用分代设计的新垃圾收集器，再按照上面的提法就有很多需要商榷的地方了。  

不过无论从什么角度，无论如 何划分，都不会改变Java堆中存储内容的共性，无论是哪个区域，存储的都只能是对象的实例，将Java 堆细分的目的只是为了更好地回收内存，或者更快地分配内存。
Java堆可以处于物理上不连续的内存空间中，但在逻辑上它应该 被视为连续的，这点就像我们用磁盘空间去存储文件一样，并不要求每个文件都连续存放。但对于大 对象（典型的如数组对象），多数虚拟机实现出于实现简单、存储高效的考虑，很可能会要求连续的 内存空间。 Java堆既可以被实现成固定大小的，也可以是可扩展的，不过当前主流的Java虚拟机都是按照可扩 展来实现的（通过参数-Xmx和-Xms设定）。如果在Java堆中没有内存完成实例分配，并且堆也无法再 扩展时，Java虚拟机将会抛出OutOfMemoryError异常。

5、方法区

用于存储已被虚拟机加载 的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。
说到方法区，不得不提一下“永久代”这个概念，尤其是在JDK 8以前，许多Java程序员都习惯在 HotSpot虚拟机上开发、部署程序，很多人都更愿意把方法区称呼为“永久代”（Permanent Generation），或将两者混为一谈。本质上这两者并不是等价的，因为仅仅是当时的HotSpot虚拟机设 计团队选择把收集器的分代设计扩展至方法区，或者说使用永久代来实现方法区而已，这样使得 HotSpot的垃圾收集器能够像管理Java堆一样管理这部分内存，省去专门为方法区编写内存管理代码的 工作。但是对于其他虚拟机实现，譬如BEA JRockit、IBM J9等来说，是不存在永久代的概念的。原则 上如何实现方法区属于虚拟机实现细节，不受《Java虚拟机规范》管束，并不要求统一。但现在回头 来看，当年使用永久代来实现方法区的决定并不是一个好主意，这种设计导致了Java应用更容易遇到 内存溢出的问题（永久代有-XX：MaxPermSize的上限，即使不设置也有默认大小，而J9和JRockit只要 没有触碰到进程可用内存的上限，例如32位系统中的4GB限制，就不会出问题），而且有极少数方法 （例如String::intern()）会因永久代的原因而导致不同虚拟机下有不同的表现。当Oracle收购BEA获得了 JRockit的所有权后，准备把JRockit中的优秀功能，譬如Java Mission Control管理工具，移植到HotSpot 虚拟机时，但因为两者对方法区实现的差异而面临诸多困难。考虑到HotSpot未来的发展，在JDK 6的 时候HotSpot开发团队就有放弃永久代，逐步改为采用本地内存（Native Memory）来实现方法区的计 划了[1]，到了JDK 7的HotSpot，已经把原本放在永久代的字符串常量池、静态变量等移出，而到了 JDK 8，终于完全废弃了永久代的概念，改用与JRockit、J9一样在本地内存中实现的元空间（Metaspace）来代替，把JDK 7中永久代还剩余的内容（主要是类型信息）全部移到元空间中。 《Java虚拟机规范》对方法区的约束是非常宽松的，除了和Java堆一样不需要连续的内存和可以选 择固定大小或者可扩展外，甚至还可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域的 确是比较少出现的，但并非数据进入了方法区就如永久代的名字一样“永久”存在了。这区域的内存回 收目标主要是针对常量池的回收和对类型的卸载，一般来说这个区域的回收效果比较难令人满意，尤 其是类型的卸载，条件相当苛刻，但是这部分区域的回收有时又确实是必要的。以前Sun公司的Bug列 表中，曾出现过的若干个严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存 泄漏。

6、运行时常量池

运行时常量池（Runtime Constant Pool）是方法区的一部分。Class文件中除了有类的版本、字 段、方法、接口等描述信息外，还有一项信息是常量池表（Constant Pool Table），用于存放编译期生 成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。
Java虚拟机对于Class文件每一部分（自然也包括常量池）的格式都有严格规定，如每一个字节用 于存储哪种数据都必须符合规范上的要求才会被虚拟机认可、加载和执行，但对于运行时常量池， 《Java虚拟机规范》并没有做任何细节的要求，不同提供商实现的虚拟机可以按照自己的需要来实现 这个内存区域，不过一般来说，除了保存Class文件中描述的符号引用外，还会把由符号引用翻译出来 的直接引用也存储在运行时常量池中。 运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量 一定只有编译期才能产生，也就是说，并非预置入Class文件中常量池的内容才能进入方法区运行时常 量池，运行期间也可以将新的常量放入池中，这种特性被开发人员利用得比较多的便是String类的 intern()方法。
既然运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常量池无法再申请到内存 时会抛出OutOfMemoryError异常。

7、直接内存

直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是《Java虚拟机规范》中 定义的内存区域。但是这部分内存也被频繁地使用，而且也可能导致OutOfMemoryError异常出现，所 以我们放到这里一起讲解。 在JDK 1.4中新加入了NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区 （Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的 DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了 在Java堆和Native堆中来回复制数据。

2.3HotSpot虚拟机对象探秘

1）对象的创建：

● 虚拟机遇到一条new指令后，首先检查指令的参数是否在常量池中定位到一个类的符号引用，并检查符号引用代表的类是否已被加载，解析和初始化。如果没有，纳摩必须先执行相应的类加载过程。类加载检查之后虚拟机会分配内存，即把一块确定大小的内存从Java堆中划分出来，当堆为绝对规整，使用指针碰撞的方式，当堆不是规整的，需要维护一个列表记录内存，称为空闲列表。Java堆是否规整由垃圾收集器是否有压缩整理决定。
● 在创建对象的并发考虑上，一种是分配内存空间动作的同时进行同步处理，采用CAS配上失败重试的方法保证更新操作的原子性。另一种是把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲（TLAB）
● 内存分配完之后，会初始化内存空间为零值，如果使用TLAB，会在TLAB中完成，这一操作保证了对象实例字段在Java中不赋初值就可以使用，
● 之后要对对象进行必要的设置，即是哪个类的实例，元信息，对象的哈希码等信息。这些信息存放在对象头中。
● 执行初始化方法

2）对象的内存布局：

在HotSpot虚拟机中，对象在内存中的存储分为三部分：对象头Mark Word，实例数据，对齐填充。
● 对象头包括两部分，其一为存储对象自身的运行时数据，哈希码，GC分代年龄，锁状态标志，线程持有的锁，偏向线程ID，偏向时间戳等。其二为类型指针，即对象指向他的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例，如果对象是一个数组，在对象头中会有一块记录数组长度的数据。
● 实例数据部分是对象真正存储的有效信息，也是在程序代码中所定义的各种类型的字段内容，存储顺序会受到虚拟机分配策略参数和字段在Java源码中的定义顺序决定。即相同宽度的字段总是会被分配到一起，父类字段在子类前。
● 对齐填充并不是必然的，也没有特别的含义，仅仅起着占位符的作用。

3）对象的访问定位：

Java程序通过栈上的reference数据来操作堆上的具体对象，访问方式有使用句柄和直接指针两种。
● 句柄方式，会划分一块内存作为句柄池，引用中存储对象的句柄地址，
● 使用直接指针方式访问，那么Java堆对象的布局考虑如何放置类型数据。使用指针速度更快，