JVM运行时数据区

前言

说到JAVA内存区域，可能很多人第一反应是“堆栈”。
首先，堆栈不是一个概念，而是两个概念，堆和栈是两块不同的内存区域，简单理解的话，堆是用来存放对象而栈是用来运行程序的。
其次，堆内存和栈内存的这种划分方式比较粗糙，这种划分方式只能说明大多数程序员最关注的、与对象内存分配关系最密切的内存区域是这两块，Java内存区域划分实际上远比这复杂。
对于Java程序员来说，在虚拟机自动内存管理机制的帮助下，不再需要为每一个new操作去配对deleted/free代码，不容易出现内存泄漏和内存溢出问题。
但是，也正是因为Java把内存控制权交给了虚拟机，一旦出现内存泄漏和内存溢出的问题，就难以排查，因此一个好的Java程序员应该去了解虚拟机的内存区域以及会引起内存泄漏和内存溢出的场景。

运行时数据区域

之所以要划分这么多区域出来是因为这些区域都有自己的用途，以及创建和销毁的时间。有些区域随着虚拟机进程的启动而存在，有的区域则依赖用户线程的启动和结束而销毁和建立。

1.线程独有的内存区域
(1) PROGRAM COUNTER REGISTER,程序计数器
这块内存区域很小，它是当前线程所执行的字节码的行号指示器，字节码解释器通过改变这个计数器的值来选取下一条需要执行的字节码指令。Java方法这个计数器才有值，如果执行的是一个Native方法，那这个计数器是空的。

(2) JAVA STACK,虚拟机栈
生命周期和线程周期相同。每个方法执行的同时都会创建一个栈帧，用于存储局部变量表、操作数栈、动态链接、方法出口等信息，每一个方法从调用至执行完毕的过程，就对应一个栈帧在虚拟机栈中入栈到出栈的过程。栈的大小和具体JVM的实现有关，通常在256K~756Kz之间。

(3) NATIVE METHOD STACK，方法栈
和虚拟机栈起的作用一样，只不过方法栈为虚拟机使用到的Native方法服务。虚拟机规范并没有对这个区域有什么强制规定，因此我们使用的HotSpot虚拟机，就干脆没有这块区域了，它和虚拟机栈是一起的。

2.线程间共享的内存区域

(1) HEAP，堆
大多数应用，堆都是Java虚拟机所管理的内存中最大的一块，它在虚拟机启动时创建，此内存唯一目的就是存放对象实例。由于现在垃圾收集器采用的基本都是分代收集算法，所以堆还可以细分为新生代和老年代，再细致一点还有Eden区、From Survivor区、To Survivor区。

(2) METHOD AREA，方法区
这块区域用于存储虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据，虚拟机规范是把这块区域描述为堆的一个逻辑部分的，但实际它应该是要和堆区分开的。从上面提到的分代收集算法的角度来看，HotSpot中，方法区≈永久代。不过JDK7之后，我们使用的HotSpot应该就没有永久代这个概念了，会采用Native Memory来实现方法区的规划了。

(3) RUNTIME CONSTANT POOL，运行时常量池
它是方法区的一部分。Class文件中除了有类的版本信息、字段、方法、接口等描述信息外，还有一项信息就是常量池，用于存放编译期间生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中，另外翻译出来的直接引用也会存储在这个区域中。

(在JVM中，类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载7个阶段。而解析阶段即是虚拟机将常量池内的符号引用替换为直接引用的过程。

在Java中，一个java类将会编译成一个class文件。在编译时，java类并不知道所引用的类的实际地址，因此只能使用符号引用来代替。而解析阶段即是虚拟机将常量池内的符号引用替换为直接引用的过程，翻译出来的直接引用也是存储在方法区的运行时常量池中。)

3.直接内存
直接内存并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。但是这部分内存也被频繁地使用，而且也可能导致内存溢出的问题。JDK1.4中新增加了NIO，引入了一种基于通道与缓冲区的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。显然本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，肯定还是会受到本机总内存大小及处理器寻址空间的限制。

对象创建

我们来看一下在虚拟机层面上创建对象的步骤：
1.虚拟机遇到一条new指令，首先去检查这个指令的参数能否在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已经被加载、解析和初始化。如果没有，那么必须执行类的初始化过程。

2.类加载检查通过后，虚拟机为新生对象分配内存。对象所需内存大小在类加载完成后便可以完全确定，为对象分配空间无非是从Java堆中划分出一个确定大小的内存而已。这个地方会有两个问题：
(1) 如果内存是规整的，那么虚拟机将采用的是指针碰撞法来为对象分配内存。意思是所有用过的内存在一边，空闲的内存在另一边，中间放着一个指针作为分界点指示器，分配内存就仅仅是把指针向空闲那边挪动一段与对象大小相等的距离罢了。如果垃圾收集器选择的是Serial、ParNew这种基于压缩算法的，虚拟机采用这种分配方式。
(2) 如果内存不是规整的，已使用的内存和未使用的内存相互交错，那么虚拟机将采用的是空闲列表法来为对象分配内存。意思是虚拟机维护了一个列表记录了哪些内存是可用的，再分配的时候从列表中找到一块足够大的空间划分给实例，并更新列表上的内容。如果垃圾收集器选择是CMS这种基于标记-清除(Mark-Sweep)算法的，虚拟机采用这种分配方式。
简言之，
垃圾收集器选择的是Serial、ParNew这种基于Compact(压缩)算法的，虚拟机采用指针碰撞法为对象分配内存；
垃圾收集器选择是CMS这种基于Mark-Sweep(标记-清除)算法的，虚拟机采用空闲列表法为对象分配内存。
另外一个问题即是保证new对象时候的线程安全。因为可能出现虚拟机正在给对象A分配内存，指针还没有来得及修改，对象B又同时使用了原来的指针来分配内存的情况。虚拟机采用了CAS配上失败重试和TLAB两种方式保证更新操作的原子性来解决这个问题。
(每个线程在Java堆中预先分配一小块内存，成为本地线程分配缓冲区——TLAB，线程内部需要分配内存时直接在TLAB上分配就行，避免了线程冲突。只有当缓冲区的内存用光需要重新分配内存的时候才会进行CAS操作分配更大的内存空间。虚拟机是否使用TLAB，可以通过-XX:+/-UseTLAB参数来进行配置，但是JDK5及以后的版本默认是启用TLAB的)

3.内存分配结束，虚拟机讲分配到的内存空间都初始化为零值(不包括对象头)。这一步保证了对象的实例字段在Java代码中可以不用赋初始值就可以直接使用，程序能访问到这些字段的数据类型所对应的零值。

4.对对象进行必要的配置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希吗、对象的GC分代年龄等信息，这些信息存放在对象的对象头中。

5.执行<init>方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。

对象定位方式

建立对象是为了使用对象，我们的Java程序需要通过栈上的reference数据来操作对上的具体对象。
比如，Object obj = new Object();而new Object()之后其实有两部分内容：一部分是类数据(方法区)、一部分是实例数据(堆)。
由于reference类型在Java虚拟机规范里面只规定了是一个指向对象的引用，并没有定义这个引用应该通过什么方式去定位、访问到堆中的对象的具体位置，对象访问方式也是取决于虚拟机实现而定的。主流的访问方式有使用句柄和直接指针两种。

1.使用句柄

在Java堆中将会划分出一块内存来作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例与类型数据的具体各自的地址信息，

2.使用直接指针

使用直接指针访问的话，Java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，reference中存储的直接就是对象地址，