以常用的HotSpot和常用的Java堆为例，深入探讨HotSpot虚拟机在Java堆中对象分配、布局和访问的全过程
1.对象的创建
①虚拟机遇到一条new指令后，首先将去检查这个指令的参数是否能够在常量池中定位到一个类的符号引用，并检查这个符号引用代表的类是否已经被加载、解析和初始化过，如果没有，那必须先进行相应的类加载过程
②类加载通过后为新生对象分配内存。对象所需的内存在类加载过程中就完全确定下来，为对象分配空间的任务等同于把一块确定大小的内存从java堆中划分出来
这时候会有两个问题，第一个是如何划分可用空间：如果java堆中内存时完全规整的，所有没用过的内存存在一边，用过得内存存在另一边，中间放着一个指针作为分界点的指示器，如果要存一个对象就把指针向空闲空间那边挪动一个对象大小的距离，这叫做“指针碰撞”；如果java堆中内存不是规整的，已经使用的和没有使用的相互交错，虚拟机就必须维护一个列表，记录下哪些内存是可用的，再分配的时候就从列表中找一块可用的一样大小的内存分配给对象，并更新列表上的记录，这种方式叫做“空闲列表” java堆是否规整取决于所采用的垃圾收集器是否带有压缩整理功能。第二个是对象创建在虚拟机中时很频繁的行为，在并发编程中并不是线程安全的，如果线程A刚分配内存，指针还没来得及修改，线程B又同时使用了刚才的指针位置来分配内存，解决这个问题：一种是对分配内存空间的动作进行同步处理-----实际上虚拟机采用CAS配上失败重试的方式保证更新操作的原子性，另一种是把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程再java堆中预先分配一小块内存，称为“本地线程分配缓冲”（TLAB）
③内存空间分配完以后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），如果使用了TLAB，那么这一工作过程可以提前至TLAB分配时进行。
④ 虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码等信息，这些信息存放在对象的对象头中，根据虚拟机当前的运行状态的不同，对象头会有不同的设置方法
⑤从虚拟机的角度看，一个新的对象已经产生了，如果从java程序的视角来看，对象创建才刚刚开始，执行new指令后会接着执行<init>方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才完全产生出来
2、对象的内存布局
在HotSpot虚拟机中，对象在内存中存储的布局可以分为三块区域：对象头、实例数据、对齐填充
对象头包括两部分：一部分用于存储对象自身的运行时数据（如哈希码，GC分代年龄等，这部分数据的长度在32位和64位虚拟机分别为32bit和64bit，官方称为“Mark Word”但对小偷信息是与对象自身定义无关的额外存储成本考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构一边在极小的空间内存储尽量多的信息，他会根据对象的状态复用自己的存储空间），另一部分是类型指针（即对象指向它的类元数据的指针），虚拟机通过这个指针来确定这个对象时哪个类的实例，查找对象的元数据信息不一定要经过对象本身，如果对象时一个数组没那么对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通java对象的元数据确定java对象的大小，但是却无法通过数组的元数据确定数组的大小。
实例数据是对象真正存储的有效信息，也是在程序中所定义的各种类型的字段内容。无论是从父类继承下来的，还是在子类中定义的，都要记录下来。
对齐填充：不是必然存在的，也没有特别的含义，仅仅起着占位符的作用，由于HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍吗换句话说，就是对象的大小必须是8字节的整数倍，而对象头部分正好是8字节的倍数，因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全
3、对象的访问定位
建立对象是为了使用对象，Java程序通过栈上的reference数据来操作堆上的具体对象。但是由于reference类型在Java虚拟机规范中只规定了一个指向对象的引用，并没有定义这个引用应该通过何种方式去定位、访问堆中的对象的具体位置，所以对象访问方式也是取决于虚拟机实现而定的。目前主流的访问方式有两种：
句柄访问
Java堆中将划分出一块内存来作为句柄池，reference存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息
直接指针 reference存储的直接就是对象地址
两者访问方式比较
句柄
由于reference中存储的是稳定的句柄地址，在对象被移动时（如GC过程中的对象移动），只需改变句柄中实例数据指针，而reference本身不用动。
直接指针
速度快，节省了一次指针定位的时间开销。HotSpot采用此方式
4、实战：OutOfMemoryError异常
①java堆溢出
通过将堆的最小值-Xms参数和最小值-Xmx参数设置为一样避免自动扩展，设置为20MB，通过参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存溢出时Dump出当前的内存堆转储快照以便事后进行分析
当出现Java堆内存溢出时，异常堆栈信息后会进一步提示：java heap space
解决这个区域的异常，一般的手段是先通过内存映像分析工具（如Eclipse Memory Analyzer）对Dump出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要分清是出现了内存泄漏还是内存溢出。
② 虚拟机栈和本地方法溢出
在HotSpot虚拟机内，不区分虚拟机栈和本地方法栈，因此-Xoss参数（设置本地方法栈大小）无效，栈容量只有-Xss参数设定。有两种异常，一种是请求的栈深度大于虚拟机允许的最大深度，抛出StackOverflowError异常，一种是扩展栈时无法申请到足够的内存空间，抛出OutOfMEmoryError异常。那么当栈空间无法继续分配时，到底是内存太小，还是已使用的栈空间太大，本质上只是对同一件事情的两种描述而已！
通过实验发现：在单线程下，无论是由于栈帧太大还是虚拟机栈容量太小，当内存无法分配的时候，虚拟机抛出的都是StackOverflowError异常！
多线程情况下，不断建立线程会导致内存溢出异常，在这种情况下，为每个线程的栈分配的内存越大，反而越容易产生内存溢出异常。
③方法区和运行时常量池溢出
在JDK1.6之前，通过-XX：PermSize和-XX：MaxPermSize限制方法区大小，从而间接限制其中常量池的容量
List<String> list=new ArrayList<String>();
int i=0;
while(true)
{
list.add(String.value(i++).intern());
}
当常量池溢出时，在OutOfMemoryError后面跟随的提示信息是“PermGen Space”，说明常量池属于方法区的一部分。
而使用JDK1.7,while循环要一直执行下去，关于常量池的实现问题，还有一个有趣的影响
在JDK1.6中，会得到两个false，而在JDK1.7中运行，回到到一个true和一个false。
这是因为，在JDK1.6中，intern()方法会把首次遇到的字符串实例复制到永久代中，返回的也是永久带中这个字符串实例的引用，而有StringBuilder创建的字符串实例在Java堆上，所以必然不是一个引用，所以返回false，而JDK1.7中的intern（）方法不会在复制实例，只是常量池中记录首次出现的实例引用，因此intern（）返回的引用和由StringBuilder创建的那个字符串实例是一个，对Str2返回false是因为“java”这个字符串在执行StringBuiledr之前已经出现过，不符合首次出现的原则。
④ 本机直接内存溢出
DirectMemory容量可以通过-XX：MaxDirectMemorySize指定，不指定，则默认与java堆最大值一样。当出现这类异常时，一个明显的特征是在Heap Dump文件中不会看见明显的异常。