本文引用自文献：1）《深入理解Java虚拟机》，作者：周志明；
Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据域。这些区域都有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而存在，有些区域则依赖用户线程的启动和结束而建立和销毁。根据《Java虚拟机规范（Java SE 7 版）》的规定，Java虚拟机所管理的内存区域如下图所示。
其中，程序计数器、Java虚拟机栈和本地方法栈是线程私有区域，Java堆和方法区是线程共享区域。
程序计数器
程序计数器（Program Counter Register）是一块较小的内存空间，它可以看做是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里（仅是概念模型，各种虚拟机可能会通过一些更搞笑的方式去实现），字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻,一个处理器(对于多核处理器来说是一个内核)都只会执行一条线程中的指令。因此，每条线程都需要有一个独立的程序计数器来记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。各条线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。
如果线程正在执行的是一个Java方法,这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是Native方法，这个计数器值则为空(Undefined)。此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
Java虚拟机栈
与程序计数器一样,Java虚拟机栈(Java Virtual Machine Stacks)也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。栈帧随着方法调用而创建，随着方法结束而销毁——无论方法是正常完成还是异常完成都算作方法结束。最顶部的栈帧称为当前栈帧，在线程运行时，Java虚拟机仅能对当前栈帧进行操作。
在Java虚拟机规范中，对这个区域规定了两种异常：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机栈可以动态扩展（当前大部分Java虚拟机都可动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈），在扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。
Java堆
Java 堆（Java Heap）是 Java 虚拟机所管理的内存中最大的一块。它是被所有线程共享的一块内存区域，在虚拟机启动时创建。它的作用是用来存放程序运行时创建的对象实例以及数组。
Java堆是垃圾收集器管理的主要区域，因此很多时候也被称做“GC堆”（Garbage Collected Heap）。从内存回收的角度来看，由于现在收集器基本都采用分代收集算法，所以Java堆还可以细分为：新生代（Young Generation）和老年代（Old Generation），其中新生代又分为 Eden 区、 Servivor From 区、 Servivor To 区。新生代一般占据堆的1/3空间，老年代占2/3空间。
另外，从内存分配的角度来看，Java 堆中可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer, TLAB）。不过无论如何划分，都与存放内容无关，无论哪个区域，存储的都仍然是对象实例，进一步划分的目的是为了更好地回收内存，或者更快地分配内存。
堆空间的不连续性和可扩展性
根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，即可以实现成固定大小的，也可以是可拓展的，不过当前主流的虚拟机都是按照可拓展来实现的（通过-Xms设置堆的初始化大小，-Xmx设置堆的最大大小，比如-Xms128m -Xmx512m指定初始堆内存为128M，最大堆内存为512M）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。
方法区
方法区(Method Area)用于存储已被虚拟机加载的类信息、常量、静态变量、JIT时编译器编译后的代码等数据。Java规范把方法区描述为堆的一个逻辑部分，但从物理上来说是不属于堆的，所以它也有一个别名叫做Non-Heap（非堆），目的是与Java堆区分开来。因为方法区是堆的一个逻辑部分，因此和堆一样也是线程共享的。
方法区和永久代的关系
对于习惯在HotSpot虚拟机上开发、部署程序的开发者来说，很多人都更愿意把方法区称为“永久代”（Permanent Generation），这是因为HotSpot虚拟机（JDK1.2~JDK1.7）的设计团队选择把GC分代收集拓展至方法区，或者说使用永久代来实现方法区而已，这样HotSpot的垃圾收集器可以像管理Java堆一样管理这部分内存，能够省去专门为方法区编写内存管理代码的工作。所以说：方法区是虚拟机的规范，永久代只是HotSpot虚拟机的一种实现方式。
虽然方法区常被叫做永久区，但并非数据进入了方法区就“永久”存在了，仍然会存在垃圾收集行为发生。（注意，Java虚拟机规范对方法区的限制是非常宽松的，除了和Java堆一样不需要连续的内存和可以选择固定大小或者可拓展外，虚拟机也可以选择不实现垃圾收集，这里只是说HotSpot虚拟机的实现方式是会进行垃圾收集的。）这区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说，这个区域的回收“成绩”比较难以令人满意。
因为方法区也是可拓展的，同样，我们也可以设置永久代的初始大小和最大大小，比如-XX:PermSize=64M -XX:MaxPermSize=128M设置永久代的初始大小为64M，最大内存为128M。格局Java虚拟机的规范，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。
但JDK1.8开始，永久代被移除了，-XX:PermSize和-XX:MaxPermSize已经失效。
元空间
从JDK1.8开始，HotSpot虚拟机移除了永久代，用元数据区（Meta Space，也叫元空间）取代。前面说过方法区是 Java 虚拟机的规范，元空间只是一种和永久代不一样的实现方式而已。它和永久代有什么不同？
- 元空间并不使用虚拟机内的内存，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过如下参数来指定元空间的大小：
-XX:MetaspaceSize=64M，初始空间大小。-XX:MaxMetaspaceSize=128M，最大空间，默认是没有限制的。
- 在原来的永久代划分中，永久代用来存放类的元数据信息、静态变量以及常量池等。现在类的元信息存储在元空间中，静态变量和常量池等并入堆中，相当于原来的永久代中的数据，被元空间和堆内存给瓜分了。
为什么要废弃永久代，引入元空间？
相比于之前的永久代划分，Oracle为什么要做这样的改进呢？
- 在原来的永久代划分中，永久代需要存放类的元数据、静态变量和常量等。它的大小不容易确定，因为这其中有很多影响因素，比如类的总数，常量池的大小和方法数量等，
-XX:MaxPermSize指定太小很容易造成永久代内存溢出。 - 移除永久代是为融合HotSpot JVM与 JRockit VM而做出的努力，因为JRockit没有永久代，不需要配置永久代。
- 永久代会为GC带来不必要的复杂度，并且回收效率偏低。
运行时常量池
运行时常量池（Runtime Constant Pool）是方法区的一部分。class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。
运行时常量池也具备动态性，Java语言并不要求常量一定只有编译期才能产生，也就是并非预置入class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，常见的场景是 String 类的 intern() 方法，这是一个Native方法，当调用该方法时：如果运行时常量池中已经包含一个等于此String对象内容的字符串，则返回常量池中该字符串的引用；如果没有，则在常量池中创建该字符串再返回其引用。
HotSpot虚拟机中，在JDK 1.2~JDK 1.6中运行时常量池是在永久代里，在JDK 1.7 版本中将运行时常量池移至堆中，JDK 1.8 后则更是废除了永久代，换成了元空间。