Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的“高墙”，墙外面的人想进去，墙里面的人却想出来。
概述
对于从事C/C++程序开发的开发人员来说，在内存管理领域，他们既是拥有最高权力的“皇帝”又是从事最基础工作的“劳动人民”——既拥有每一个对象的“所有权”，又担负着每一个对象生命开始到终结的维护责任。
对于Java程序员来说，在虚拟机自动内存管理机制的帮助下，不再需要为每一个new操作去写配对的delete/free代码，不容易出现内存泄漏和内存溢出问题，由虚拟机管理内存这一切看起来都很美好。不过，也正是因为Java程序员把内存控制的权力交给了Java虚拟机，一旦出现内存泄漏和溢出方面的问题，如果不了解虚拟机是怎样使用内存的，那么排查错误将会成为一项异常艰难的工作。
运行时数据区域(JVM内存模型)
Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而存在，有些区域则依赖用户线程的启动和结束而建立和销毁。
Java 虚拟机（Java Virtual Machine=JVM）的内存空间主要分为五个部分，分别是：
1、程序计数器
2、Java 虚拟机栈
3、本地方法栈
4、堆
5、方法区（JDK1.7及以前由永久代实现，JDK1.8及以后由元空间实现）
如下图所示：
程序计数器（线程私有）
什么是程序计数器？
程序计数器(Program Counter Register)是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。也就是说，程序计数器里面记录的是当前线程正在执行的虚拟机字节码指令的地址。
程序计数器的作用
程序计数器有两个作用：
1、在虚拟机的概念模型里(仅是概念模型，各种虚拟机可能会通过一些更高效的方式去实现)，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
2、由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻,一个处理器(对于多核处理器来说是一个内核)都只会执行一条线程中的指令。因此，每条线程都需要有一个独立的程序计数器来记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。各条线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。
注意
如果线程正在执行的是一个Java方法,这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是本地方法，这个计数器值则为空(Undefined)。此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
Java虚拟机栈（线程私有）
什么是Java虚拟机栈？
与程序计数器一样,Java虚拟机栈(Java Virtual Machine Stacks)也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
堆和栈浅谈
经常有人把Java内存区分为堆内存(Heap)和栈内存(Stack)，这种分法比较粗糙，Java内存区域的划分实际上远比这复杂。这种划分方式的流行只能说明大多数程序员最关注的、与对象内存分配关系最密切的内存区域是这两块。这里的“堆”可以这么理解，但这里的“栈”只代表了Java虚拟机栈中的局部变量表部分。
局部变量表存放了编译期可知的各种基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference类型，它不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置)和returnAddress类型(指向了一条字节码指令的地址)。
其中64位长度的long和double类型的数据会占用2个局部变量空间(Slot)，其余的数据类型只占用1个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
可能出现的异常
Java 虚拟机栈会出现两种异常：StackOverFlowError 和 OutOfMemoryError。
StackOverFlowError： 若Java虚拟机栈的内存大小不允许动态扩展，那么当线程请求栈的深度超过当前Java虚拟机栈的最大深度的时候，就抛出StackOverFlowError异常。
OutOfMemoryError： 若Java虚拟机栈的内存大小允许动态扩展，且当线程请求栈时内存用完了，无法再动态扩展了，此时抛出OutOfMemoryError异常。
StackOverFlowError和OutOfMemoryError的异同：StackOverFlowError表示当前线程申请的栈超过了事先定好的栈的最大深度，但内存空间可能还有很多。而OutOfMemoryError是指当线程申请栈时发现栈已经满了，而且内存也全都用光了。
可以通过 -Xss 这个虚拟机参数来指定每个线程的 Java 虚拟机栈内存大小：
java -Xss512M HackTheJava
本地方法栈（线程私有）
本地方法栈(Native Method Stack)与虚拟机栈所发挥的作用是非常相似的,它们之间的区别不过是虚拟机栈为虚拟机执行Java方法(也就是字节码)服务，而本地方法栈则为虚拟机使用到的Native方法服务。本地方法一般是用其它语言（C、C++ 或汇编语言等）编写的，并且被编译为基于本机硬件和操作系统的程序，对待这些方法需要特别处理。
在虚拟机规范中对本地方法栈中方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机(譬如Sun HotSpot虚拟机)直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。
堆（线程共享）
什么是堆？
堆是用来存放对象的内存空间。所有对象都在这里分配内存，是垃圾收集的主要区域（"GC 堆"）。
堆的特点
1、线程共享
对于大多数应用来说,Java堆(Java Heap)是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，所有的对象实例都在这里分配内存。
2、内存回收和内存分配的主要场所
Java堆是垃圾收集器管理的主要区域，因此很多时候也被称做“GC堆”(Garbage
Collected Heap)。
从内存回收的角度来看，由于现代的垃圾收集器基本都采用分代收集算法（因为对象的生命周期不一样），主要思想是针对不同的对象采取不同的垃圾回收算法，所以Java堆中分为：新生代（Young Generation）和老年代（Old Generation），默认比例为新生代占1 / 3的堆空间，老年代占2 / 3的堆空间，可以通过-XX:NewRatio参数来设置，如参数值为4表示 新生代 : 老年代 = 1 : 4 ；由于新生代存放着大量的生命周期很短的对象，因此新生代垃圾回收的频率最高。为了更高效地进行垃圾回收，继续将新生代细分为Eden空间、From Survivor空间、To Survivor空间，默认比例为8:1:1，可以通过-XX:SurvivorRatio参数设置，如参数值为8表示 两个Survivor空间 : Eden空间 = 2 : 8。
从内存分配的角度来看，线程共享的Java堆中可能划分出多个线程私有的分配缓冲区(Thread Local Allocation Buffer，TLAB)。不过无论如何划分，都与存放内容无关，无论哪个区域，存储的都仍然是对象实例，进一步划分的目的是为了更好地回收内存，或者更快地分配内存。
3、内存空间的不连续性和可扩展性
根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。并且可以动态增加其内存。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。
可以通过 -Xms 和 -Xmx 两个虚拟机参数来指定一个程序的堆内存大小，-Xms是 -XX:InitialHeapSize的简写 表示的是初始化堆的大小，-Xmx 是 -XX:MaxHeapSize的简写 表示的是设置堆的最大大小：
java -Xms1M -Xmx2M HackTheJava
可以用 -Xmn 来设置堆内新生代的大小。通过这个值我们也可以得到老年代的大小：-Xmx 减去-Xmn
方法区（线程共享）
什么是方法区？
方法区(Method Area)与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器 (JIT) 编译后的代码等数据。方法区和堆一样不需要连续的内存，并且可以动态扩展，当无法满足内存分配需求时，将抛出OutOfMemoryError异常。
方法区的特点
1、线程共享
方法区是堆的一个逻辑部分，因此和堆一样，都是线程共享的。整个虚拟机中只有一个方法区。
2、内存回收效率低
相对而言，垃圾收集行为在这个区域是比较少出现的。这区域的内存回收目标主要是：针对常量池的回收和对类的卸载。一般来说，这个区域的回收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是必要的。
3、Java虚拟机规范对方法区的要求比较宽松
Java虚拟机规范对方法区的限制非常宽松，除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。
方法区和永久代（Permanent Generation）的关系
涉及到内存模型时，往往会提到永久代，那么它和方法区又是什么关系呢？Java虚拟机规范只是规定了有方法区的概念和作用，并没有规定如何去实现它。所以在不同的 JVM 上方法区的实现也不同。 大多数使用的JVM都是Sun公司的HotSpot。在HotSpot上把GC分代收集扩展至方法区，或者说使用永久代来实现方法区。因此，我们得到了结论：方法区是Java虚拟机规范中的定义，是一种规范；而永久代是HotSpot的概念，是一种实现。其他的虚拟机实现并没有永久代这一说法。在JDK1.7之前在(JDK1.2 ~ JDK1.6)的实现中，HotSpot 使用永久代实现方法区，HotSpot 使用 GC分代来实现方法区内存回收，可以使用如下参数来调节方法区的大小：
-XX:PermSize
方法区初始大小
-XX:MaxPermSize
方法区最大大小
超过这个值将会抛出OutOfMemoryError异常:java.lang.OutOfMemoryError: PermGen space
但JDK1.8开始，永久代被移除了，-XX:PermSize 和 -XX:MaxPermSize已经失效。
元空间（metaspace）
在JDK1.7之前，HotSpot 虚拟机把方法区当成永久代来进行垃圾回收。而从 JDK 1.8 开始，移除永久代，并把方法区移至元空间，它位于本地内存中，而不是虚拟机内存中。
HotSpots取消了永久代，那么是不是也就没有方法区了呢？当然不是，方法区是一个规范，规范没变，它就一直在，只不过取代永久代的是元空间（Metaspace）而已。它和永久代有什么不同的？
存储位置不同：永久代在物理上是堆的一部分，和新生代、老年代的地址是连续的，而元空间属于本地内存。
存储内容不同：在原来的永久代划分中，永久代用来存放类的元数据信息、静态变量以及常量池等。现在类的元信息存储在元空间中，静态变量和常量池等并入堆中，相当于原来的永久代中的数据，被元空间和堆内存给瓜分了。
为什么要废弃永久代，引入元空间？
相比于之前的永久代划分，Oracle为什么要做这样的改进呢？
- 在原来的永久代划分中，永久代需要存放类的元数据、静态变量和常量等。它的大小不容易确定，因为这其中有很多影响因素，比如类的总数，常量池的大小和方法数量等，-XX:MaxPermSize 指定太小很容易造成永久代内存溢出。
- 移除永久代是为融合HotSpot JVM与 JRockit VM而做出的努力，因为JRockit没有永久代，不需要配置永久代
- 永久代会为GC带来不必要的复杂度，并且回收效率偏低。
废除永久代的好处
- 由于类的元数据分配在本地内存中，元空间的最大可分配空间就是系统可用内存空间。不容易遇到永久代存在时的内存溢出错误。
- 将运行时常量池从PermGen分离出来，与类的元数据分开，提升类元数据的独立性。
- 将元数据从PermGen剥离出来到Metaspace，可以提升对元数据的管理同时提升GC效率。
- 为后续将HotSpot与JRockit合二为一做准备。PermGen是HotSpot的实现特有的，JRockit并没有PermGen一说。
Metaspace相关参数
- -XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。
- -XX:MaxMetaspaceSize，最大空间，默认是没有限制的。如果没有使用该参数来设置类的元数据的大小，其最大可利用空间是整个系统内存的可用空间。JVM也可以增加本地内存空间来满足类元数据信息的存储。
但是如果没有设置最大值，则可能存在bug导致Metaspace的空间在不停的扩展，会导致机器的内存不足；进而可能出现swap内存被耗尽；最终导致进程直接被系统直接kill掉。
如果设置了该参数，当Metaspace剩余空间不足，会抛出：java.lang.OutOfMemoryError: Metaspace space - -XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集
- -XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集
运行时常量池
运行时常量池在JDK1.6及之前版本的JVM中是永久代的一部分，而在JDK1.7版本中JVM已经将运行时常量池移入堆中，在JDK1.8之后更是废除了永久代，引入了元空间。
Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池(Constant Pool Table)，用于存放编译期生成的各种字面量和符号引用。
Class 文件中的常量池（编译器生成的各种字面量和符号引用）会在类加载后被放入运行时常量池。当运行时常量池中的某些常量没有被对象引用，同时也没有被变量引用，那么就需要垃圾收集器回收。
运行时常量池和Class文件常量池的区别
1、Java虚拟机对Class文件每一部分(自然也包括常量池)的格式都有严格规定，每一个字节用于存储哪种数据都必须符合规范上的要求才会被虚拟机认可、装载和执行，但对于运行时常量池，Java虚拟机规范没有做任何细节的要求，不同的提供商实现的虚拟机可以按照自己的需要来实现这个内存区域。不过，一般来说，除了保存Class文件中描述的符号引用外，还会把翻译出来的直接引用也存储在运行时常量池中。
2、运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量一定只有编译期才能产生，也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的便是String类的intern()方法。String.intern()是一个Native方法，它的作用是：如果运行时常量池中已经包含一个等于此String对象内容的字符串，则返回常量池中该字符串的引用；如果没有，则在常量池中创建与此String内容相同的字符串，并返回常量池中创建的字符串的引用。
直接内存
直接内存(Direct Memory)并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。但是这部分内存也被频繁地使用，而且也可能导致OutOfMemoryError异常出现。
在JDK 1.4中新加入了NIO(New Input/Output)类，引入了一种基于通道(Channel)与缓冲区(Buffer)的I/O方式，它可以使用Native函数库直接分配堆外内存（Native堆），然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在 Java 堆和 Native 堆中来回复制数据，从而提升了数据操作的效率。显然，本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，肯定还是会受到本机总内存(包括RAM以及SWAP区或者分页文件)大小以及处理器寻址空间的限制。当内存不足就会抛出OutOfMemoryError异常。
下面使用简单的代码分配堆外内存：
Buffer buffer = ByteBuffer.allocateDirect(1024);
各内存区域的总结
1、Java虚拟机的内存模型中一共有两个“栈”，分别是：Java虚拟机栈和本地方法栈。两个“栈”的功能类似，都是方法运行过程的内存模型。并且两个“栈”内部构造相同，都是线程私有。 只不过Java虚拟机栈描述的是Java方法运行过程的内存模型，而本地方法栈是描述Java本地方法运行过程的内存模型。
2、Java虚拟机的内存模型中一共有两个“堆”，一个是原本的堆，一个是方法区。方法区本质上是属于堆的一个逻辑部分。堆中存放对象，方法区中存放类信息、常量、静态变量、即时编译器编译的代码。
3、堆是Java虚拟机中最大的一块内存区域，也是垃圾收集器主要的工作区域。
4、程序计数器、Java虚拟机栈、本地方法栈是线程私有的，即每个线程都拥有各自的程序计数器、Java虚拟机栈、本地方法栈。并且他们的生命周期和所属的线程一样。 而堆、方法区是线程共享的，在Java虚拟机中只有一个堆、一个方法区。并在JVM启动的时候就创建，JVM停止才销毁。
JVM内存管理参数
参考：JVM 参数使用总结
对象的创建
Java是一门面向对象的编程语言，在Java程序运行过程中无时无刻都有对象被创建出来。在语言层面上，创建对象(例如克隆、反序列化)通常仅仅是一个new关键字而已，而在虚拟机中，对象(文中讨论的对象限于普通Java对象，不包括数组和Class对象等)的创建又是怎样一个过程呢?
当虚拟机遇到一条含有new的指令时，会进行一系列对象创建的操作：
1）检查常量池中是否有即将要创建的这个对象所属的类的符号引用
- 若常量池中没有这个类的符号引用，说明这个类还没有被定义，抛出ClassNotFoundException
- 若常量池中有这个类的符号引用，则进行下一步工作
2）进而检查这个符号引用所代表的类是否已经被JVM加载（包括加载、验证、准备、解析、初始化）
- 若该类还没有被加载，就找该类的class文件，并加载进方法区
- 若该类已经被JVM加载，则准备为对象分配内存
3）根据方法区中该类的信息确定该类所需的内存大小
一个对象所需的内存大小是在这个对象所属类被定义完就能确定的，且一个类所生产的所有对象的内存大小是一样的。JVM在一个类被加载进方法区的时候就知道该类生产的每一个对象所需要的内存大小，为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来。
4）从堆中划分一块对应大小的内存空间给新的对象
分配堆中内存有两种方式：
- 指针碰撞：如果JVM的垃圾收集器采用复制算法或标记-整理算法，那么堆中空闲内存是完整的区域，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离，这种分配方式称为“指针碰撞”(Bump the Pointer)。
- 空闲列表：如果JVM的垃圾收集器采用标记-清除算法，那么堆中空闲区域和已使用区域交错，就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记录哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录，这种分配方式称为“空闲列表”(Free List)。
综上所述：JVM选择哪种分配方式由Java堆是否规整决定，而Java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。因此，在使用Serial、ParNew等带Compact过程的收集器时,系统采用的分配算法是指针碰撞，而使用CMS这种基于Mark-Sweep算法的收集器时，通常采用空闲列表。
5）为对象中的成员变量赋上初始值(默认初始化)
6）为对象中的成员变量显式赋值(显式初始化)
7）设置对象头中的信息
8）调用对象的构造函数进行初始化
注意：如果对象不是匿名对象，即要赋值给引用变量，则还需要在Java虚拟机栈中为引用变量分配空间。
此时，整个对象的创建过程就完成了。
对象的内存布局
一个对象从逻辑角度看，它由成员变量和成员函数构成，从物理角度来看，对象是存储在堆中的一串二进制数，这串二进制数的组织结构如下。
对象在内存中分为三个部分：
1、对象头
2、实例数据
3、对齐补充
对象头
HotSpot虚拟机的对象头包括两部分信息，第一部分用于存储对象自身的运行时数据，如哈希码(HashCode)、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等。
对象头的另外一部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。
另外，如果对象是一个数组，那在对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通Java对象的元数据信息确定Java对象的大小，但是从数组的元数据中却无法确定数组的大小。
实例数据
实例数据就是成员变量的值，其中包含父类的成员变量和本类的成员变量。这部分的存储顺序会受到虚拟机分配策略参数(FieldsAllocationStyle)和字段在Java源码中定义顺序的影响。HotSpot虚拟机默认的分配策略为longs/doubles、ints、shorts/chars、bytes/booleans、oops(Ordinary Object Pointers)，从分配策略中可以看出，相同宽度的字段总是被分配到一起。在满足这个前提条件的情况下，在父类中定义的变量会出现在子类之前。如果CompactFields参数值为true(默认为true)，那么子类之中较窄的变量也可能会插入到父类变量的空隙之中。
对齐补充
并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。由于HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说，就是对象的大小必须是8字节的整数倍。而对象头部分正好是8字节的倍数(1倍或者2倍)，因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。
访问对象的过程
我们知道，引用类型的变量中存放的是一个地址，那么根据地址类型的不同，对象有不同的访问方式：
1、句柄访问方式：堆中分配出一块叫做“句柄池”的内存空间，用于存放对象实例数据与类型数据各自的具体地址信息。引用类型的变量存放的是该对象在句柄池中的地址。访问对象时，首先需要通过引用类型的变量找到该对象的句柄，然后根据句柄中对象的地址再访问对象。
2、直接指针访问方式：引用类型的变量直接存放对象的地址，从而不需要句柄池，通过引用能够直接访问对象。但对象所在的内存空间中需要额外的策略存储对象所属的类信息的地址。
这两种对象访问方式各有优势，使用句柄来访问的最大好处就是reference中存储的是稳定的句柄地址，在对象被移动(垃圾收集时移动对象是非常普遍的行为)时只会改变句柄中的实例数据指针，而reference本身不需要修改。
使用直接指针访问方式的最大好处就是速度更快，它节省了一次指针定位的时间开销，由于对象的访问在Java中非常频繁，因此这类开销积少成多后也是一项非常可观的执行成本。
HotSpot采用直接指针方式访问对象，因为它只需一次寻址操作，从而性能比句柄访问方式快一倍。但它需要额外的策略存储对象在方法区中类信息的地址。
