对于JAVA程序员来说，在虚拟机自动内存管理机制的帮助下，不需要为每一个对象去写free/delete代码。因为java程序员把内存控制的权限交给了JAVA虚拟机，所以，一旦出现内存泄漏和内存溢出方面的问题，如果不了解虚拟机是怎样使用内存的，那么我们就不能很好的排查错误（摘自深入理解java虚拟机）
1内存模型
java虚拟机在执行java程序的过程中会把它所管理的内存划分成若干个不同的区域，如下：
1.1程序计数器
程序计数器是一块儿较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。 如果线程正在执行的是一个java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是Native方法，这个计数器值则为空。
此内存区域是惟一一个在java虚拟机规范中没有规定任何OutOfMemoryErrror情况的区域
1.2Java虚拟机栈
与程序计数器一样，Java虚拟机栈也是线程私有的，它的生命周期和线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行的同时会创建一个栈帧（Stack Frame）用于存储局部变量表，操作数栈，动态链接，方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈和出栈的过程。局部变量表存放了编译期预知的各种基本数据类型，对象引用，和returnAddress类型（指向了一条字节码指令的地址）。
long和double数据类型会占两个局部变量空间（Slot），局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，方法运行期间不会改变局部变量表的大小。
在java虚拟机规范里，在这个区域规定了两种异常情况：如果线程请求的栈的深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机栈可以动态扩展（当前大部分虚拟机都可动态扩展，只不过java虚拟机规范中也允许固定长度的java虚拟机栈），但无法申请到足够的内存时，就会抛出OutOfMemoryError异常。
1.3本地方法栈
本地方法栈发挥的作用和java虚拟机栈非常相似。它们的区别是，虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。虚拟机规范中对本地方法栈中方法使用的语言，使用方式和数据结构并没有强制的规定，因此虚拟机可以自由的使用它。有的虚拟机（hotspot）直接就把本地方法栈和虚拟机栈直接合二为一。
本地方法栈也会抛出StackOverflowError和OutOfMemoryError异常
1.4Java堆
对于大多说应用来说，Java堆是虚拟机所管理的内存中的最大一块儿区域。Java堆是被所有线程共享的区域，在虚拟机启动的时候被创建。此内存的唯一目的就是存放对象的实例，几乎所有对象的内存的实例都在想都在这里分配内存。这一点在java虚拟机规范中的描述：所有的对象实例以及数组都要在栈上分配，但是随着JIT编译器的发展与逃逸分析技术逐渐成熟，栈上分配，标量替换优化技术将会导致一些微妙的变化发生，所有的对象都分配在堆上也渐渐变得不是那么绝对了。
java堆是垃圾回收器管理的主要区域，从内存回收的角度来看，由于现在的垃圾回收器都采用的分代回收算法，所以java堆还可以细分为：新生代和老年代；再细致一点还可分为Eden空间，From Survivor空间，To Survivor空间。从内存分配的角度来看，线程共享的java堆中可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer， TLAB）。无论如何划分，都与存储的内容无关，无论哪个区域，存放的都是对象的实例，进一步划分是为了更好的回收内存，或者更快的分配内存。
根据java虚拟机规范的规定，java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可。在实现时，既可以是固定大小的，也可以是可扩展的，当前的虚拟机都是按照可扩展的方式来实现的（通过-Xmx 和 -Xms控制）。
如果在堆内没有内存完成实例分配，并且堆也没变法再扩展时，就会抛出OutOfMemoryError异常
1.5方法区
方法区（Method Area）与java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即使编译器边以后的代码等数据。虽然java虚拟机把方法区描述为堆的一个逻辑部分，但它还有一个别名叫做Non-Heap（非堆），目的应该是与java堆区分开。
垃圾回收器扩展至方法区，hotspot垃圾回收器可以像管理java堆内存一样管理这部分内存，在hotspot虚拟机上开发的人，习惯的把这块儿区域成为永久代。java虚拟机规范对方法区的限制非常宽松，除了和java堆一样不需要连续的内存和可以固定大小或者可扩展外，还可以选择不实现垃圾回收。相对而言，垃圾回收器的行为在这一块儿很少出现，但并发数据一旦进入方法区就如永久代名字一样永久的存在了。这区域的内存回收目标主要是针对常量池的回收和对类型的卸载。一般来说，这个区域的回收难令人满意，尤其是类型的卸载，条件相当苛刻。
根据java虚拟机规范的规定，如果方法区无法满足内存分配时，抛出OutOfMemoryError异常。
1.6运行时常量池
运行时常量池是方法区的一部分。Class文件中除了有类的版本，字段，方法，接口等描述信息外，还有一项信息是常量池。用于存放编译器生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。
java虚拟机对class没一部分（自然也包括常量池）的格式都有严格规定，每一个字节用于存储哪种数据都必须符合规范上的要求才会被虚拟机认可，装载和执行，但对于运行时常量池，java虚拟机规范没有做任何细节的要求，不同的提供商实现的虚拟机可以按照自己的需要来实现这个内存区域。不过，一般来说，除了报春Class文件中描述的符号引用外，还会把翻译出来的直接引用也存储在运行时常量池中。
运行时常量池相对于Class文件常量池和另外一个重要特性是具备动态性，java语言并不要求常量一定只有编译期才能产生，也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可以将新的变量放入池中，这种特性被开发人员利用的较多的就是String类的intern()方法。既然运行时常量池是方法区的一部分，自然收到方法区内存的限制。
当常量池中无法再申请到内存时会抛出OutOfMemoryError异常。
1.7直接内存
直接内存并不是java虚拟机内存数据的一部分，也不是java虚拟机规范中定义的内存区域。服务器管理员在配置虚拟机参数时，会根据实际内存设置-Xms等参数信息，但经常忽略到直接内存，使得各个内存区域综合大于物理内存限制，导致OutOfMemoryError异常。
2 HotSpot虚拟机对象探秘
2.1对象的创建
虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到这个类的引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。
在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定，为对象分配空间的任务等同于把一块儿确定大小的内存从JAVA堆中分配出来。有两种分配方式，一种称为指针碰撞，另一种称为空闲列表。选择哪种分配方式由java堆是否规整决定，而java堆是否规整又由所采用的垃圾回收期是否带有压缩整理功能决定。因此，在使用Serial、parNewd等带Compact过程的回收器时，系统采用的分配算法是指针碰撞，而使用CMS这种基于Mark-Sweep算法的回收器时，通常采用空闲列表。
除了如何划分可用空间外，还有另外一个需要考虑的问题就是对象创建在虚拟机中是非常频繁的行为，即使是仅仅修改一个指针所指向的位置，在并发情况下也并不是线程安全的，可能出现正在给对象A分配内存，指针还没来得及修改，对象B又同时使用了原来的指针来分配内存的情况。解决这个问题有两种方案，一种是对分配内存空间的动作进行同步处理--实际上虚拟机采用CAS配上失败重试的方式保证更新操作的原子性；另一种是把内从分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配已小块儿内存，成为本地线程分配缓存（Thread Local Allocation Buffer，TLAB）。那个线程要分配内存，就在哪个线程的TLAB上分配，只有TLAB用完并分配新的TLAB时，才需要同步锁定。虚拟机是否使用TLAB，可以通过-XX:+/-UseTLAB参数来设定。
内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），如果使用TLAB，这一工作过程也可以提前至TLAB分配时进行。这一步操作保证了对象的实例字段在java代码中可以不赋值就直接使用，程序能访问到这些字段的数据类型所对应的零值。
接下来，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实力，如何才能找到这个类的元数据信息，对象的哈希吗，对象的GC分代年龄等信息。这些信息存放在对象头中。根据虚拟机当前的运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。稍后详细介绍。
在上面的工作完成以后，从虚拟机的角度来说，一个新的对象就已经产生了，但从java程序的视角来看，对象的创建才刚刚开始--<init>方法还没有执行，所有的字段都还为零。所以，一般来说（由字节码中是否跟随invokespecial指令所决定），执行new指令之后会接着执行<init>方法，把对象按照程序员的医院进行初始化，这样一个可用的对象才算完全产生出来
2.2对象的内存布局
在HotSpot虚拟机中，对象在内存中存储的布局可以分为3块儿区域：对象头（Header）、实例数据（Instance Data）和对齐填充(Padding)。
HotSpot虚拟机的对象头包括两部分信息，第一部分用于存储对象自身的运行时数据，如哈希吗，GC分代年龄，锁状态标志，线程持有的锁，偏向线程ID，偏向时间戳。对象头的另外一部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。如果对象是一个java数组，那在对象头中还必须有一块儿用于记录数组长度的数据，因为虚拟机可以通过普通java对象的元数据信息确定java对象的大小，但是从数组的元数据中无法确定数组的大小。
实例数据部分是对象真正存储的有效信息，也是在程序代码中所定义的各种类型的字段内容。无论是从父类集成下来的，还是在子类中定义的，都需要记录起来。
第三部分对齐填充并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。由于HotSpot VM的自动内存管理系统要求对象的起始地址必须是8字节的整数倍。也就是说，对象的大小必须是8字节的正如倍。而对象头部分正好是8字节的倍数，因此，对象实例数据部分没有对其时，就需要通过对齐填充来补全。
2.3对象的访问定位
建立对象是为了使用对象，我们的java程序需要通过栈上的reference数据来操作堆上的具体对象。由于reference类型在java虚拟机规范中只规定了一个指向对象的引用，并没有定义这个这个应用应该通过何种方式去定位，访问堆中的对象的具体位置，所以对象访问方式也取决于虚拟机实现而定的。目前主流的访问方式有使用句柄和直接指针两种。
如果使用句柄访问的话，那么java堆中将会划分出一块儿内存在作为句柄池，reference中储存的就是对象句柄的地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息。如下图
如果使用直接指针访问，那么java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，而reference中存储的直接就是对象地址。
这两种对象访问方式各有优势，使用句柄来访问的最大好处就是reference中存储的是稳定的句柄地址，在对象被移动（垃圾回收时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而reference本身不需要修改。
使用直接指针访问的最大好处就是速度更快，它节省了一次指针定位的时间开销，对于对象的访问在java中非常频繁，因此这类开销积少成多后也是一项非常客观的执行成本。HotSpot是用第二种方式访问对象的。