[toc]
运行时数据区域
JVM在执行java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途，已经创建和销毁的时间，有的区域随着虚拟机进程的启动而存在，有些区域则是依赖用户线程的启动和结束而建立和销毁，。具体如下图所示：
image
程序计数器(Programe Counter Register)
程序计数器(Programe Counter Register)是一块较小的内存空间，可以看做是当前线程所执行的字节码的行号指示器。在虚拟机概念模型中，字节码解释器工作时就是通过改变程序计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程回复等基础功能都需要依赖这个计数器来完成。
程序计数器是一块线程私有的内存，如上文图所示，每个线程都有一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储，这样设计使得在多线程下，线程切换后能恢复到正确的执行位置。
如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；若执行的Native方法，则计数器为空(Undefined)因为Native方法而言，他的方法体并不是有Java字节码构成的，自然无法应用上述的“字节码指令的地址概念”。程序计数器也是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的内存区域。
Java虚拟机栈(Java Virtual Machine Stacks)
Java虚拟机栈(Java Virtual Machine Stacks)描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧(Stack Frame)，栈帧中存储着局部变量表、操作数栈、动态链接、方法出口等信息，每一个方法从调用直至执行完成的过程，会对应一个栈帧，在虚拟机栈中入栈到出栈的过程，与程序计数器一样，Java虚拟机栈也是线程私有的。
函数的调用有完美的嵌套关系---调用者的生命周期总是长于被调用者的生命周期，并且后者在前者之内，这样，被调用者的局部信息所占空间的分配总是后于调用者调用者(后入)，而其释放则总是先于调用者(先出)，所以正好满足栈的LIFO(先进后出)顺序，选用栈这种数据结构来实现调用栈是一种很自然的选择。
局部变量表
局部变量表中存放了编译器可知的各种：
基本数据类型(boolen、byte、char、short、int、float、long、double)
对象引用(reference类型，他不等于对象本身，可能是一个指向对象起始地址的指针，有可能是指向一个代表对象的句柄或其他与此对象相关的位置)
returnAddress类型(指向了一条字节码指令地址)
其中64位长度的long和double类型的数据会占用2个局部变量空间(Slot)，其余数据类型只占用1个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定，在方法运行期间不会改变局部变量表的大小。
异常状况
java虚拟机规范中对这个区域规定了两个异常状况：
StackOverflowError：线程请求的栈深度大于虚拟机所允许的深度，就会抛出异常
OutOfMemoryError：可动态扩展虚拟机栈在扩展时无法申请足够的内存，就会抛出该异常。
本地方法栈(Native Method Stack)
本地方法栈(Native Method Stack) 与java虚拟机栈的作用很相似，他们区别在于虚拟机栈执行Java方法(即字节码)服务，而本地方法栈则为虚拟接使用到Native方法服务。
在虚拟机规范中对本地方法栈中使用的语言、方式和数据结构并无强制规定，因此具体的虚拟机可实现他，甚至有的虚拟机(Sun HotSpot虚拟机)直接把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，属于线程私有的，本地方法栈会抛出StackOverflowError和OutOfMemortError异常。
Java堆(Heap)
对于大多数应用而言Java堆是java虚拟机所管理的内存中的最大一块，被所有线程共享，在虚拟机启动时创建。此内存区域唯一的目的是存放对象的实例，几乎所有的对象的实例都在这里分配内存，且每次分配的空间是不定长的，在Heap中分配一定的内存来保存对象实例，实际上只是保存对象实例的属性值，属性的类型和对象本身的类型标记等，并不保存对象的方法(方法是指令，保存在Stack中)，在Heap中分配一定的内存保存对象实例和对象的序列化比较类似。对象实例在Heap中分配号以后，需要在Stack中保存一个4字节的Heap内存地址，用来定位该对象实例在Heap中的位置，便于找到该对象实例。
java虚拟机规范中描述道：所有对象的实例以及数组都要在堆上分配，但是随着JIT编译的发展和逃逸分析技术的逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化发生，所有的额对象都在堆上分配也并不绝对了。
Java堆是垃圾收集管理的主要区域，因此也被称为GC堆(Garbage Collected Heap)。从内存回收的角度看内存空间如下划分：
image
新生代(Young)：新生成的对象优先存放在新生代中，新生代对象朝生夕死，存活率很低。在新生代中，常规应用进行一次垃圾收集一般可以回收70%~95%的空间，回收效率很高。新生代又可以细分为Eden空间、From Survivor空间、To Survivor空间，默认比例为8:1:1。他们的具体作用下一篇讲解。
老年代(Tenured/Old)：在新生代经历了多次(具体看虚拟机配置的阈值)GC后仍然存活下来的对象会进入老年代中，老年代中的对象生命周期较长，存活率比较高，在老年代中进行GC频率相对而言比较低，二区回收的速度也比较慢。
永久代(Perm)：永久代存储类信息、常量、静态变量、即时编译器编译后的代码等数据，对这一区域而言，Java虚拟机规范支出可以不进行垃圾收集，一般而言不会进行垃圾回收。
其中新生代和老年代组成了Java对的全部内存区域，而永久代不属于堆内存，在JDK1.8以前被Sun HotSpot虚拟机用方法区的实现。
方法区(Method Area)
方法区(Method Area) 与java对一样，是各个线程共享的内存区域。Object Class Date(类定义数据)是存储在方法区中，此外，常量、静态变量、JIT编译后的代码也存储在方法区。正因为方法区所存储的数据与堆有一种类比的关系，所以还被称为Non-Heap。
JDK1.8以前的永久代(PermGen)
Java虚拟机规范对方法区的限制非常宽松，除了和Java对一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集，也就是说，Java虚拟机规范只是规定了方法区的概念和他的作用，并没用规定如何取实现他，对于JDK1.8之前的版本，HotSpot虚拟机设计团队选择吧GC分代收集扩展到方法区，及用永久代来实现方法区，这样HotSpot的垃圾收集器可以像管理Java堆一样管理这部分内存，能够神弄过去专门为方法区编写内存管理代码的工作。对于其他虚拟机(如Oracl JRockit、IBM J9等)来说是不存在永久代的概念的。
如果运行时有大量的类产生，可能会导致方法区被填满，直至溢出，常见的应用场景如下：
Spring和ORM框架使用CGLib操纵字节码对类进行增强，增强的类越多，就需要越大的方法区来保证动态生成的Class可以加载入内存。
大量JSP或动态产生JSP文件的应用(JSP第一次运行时需要编译为Java类)。
基于OSGi的应用(即使是同一个类文件，被不同的类加载器加载也会视为不同的类)
这些都会导致方法区溢出，报出java.lang.OutOfMemoryError:PermGen spance。
JDK1.8的元空间(Metaspace)
在JDK1.8中，HotSpot虚拟机设计团队为了促进HotSpot和JRockit融合，修改了方法区的实现，移除了永久代，选择使用本地化的内存空间(而不是JVM的内存空间)存放类的元数据，这个空间叫做元空间(Metaspance)
作了这个改动以后，java.lang.OutOfMemoryError:PeremGen space的空间文件问题将不存在，并且不再需要调整和监控这个内存空间，区虚拟机需要为方法区设计额外的HC策略：如果类元数据的空间占用达到参数MaxMetaspaceSize设置的值，将会触发对死亡对象和类加载器的垃圾回收，为了限制垃圾回收的频率和延迟，适当的监控和调优元空间是非常有必要的，元空间过多的垃圾收集可能表示类、类加载器内存泄漏或对你的应用程序来说空间太小了。
元空间的内存管理由元空间虚拟机来完成。先前，对于类的元数据我们需要不同的垃圾收集器进行处理，现在只需要执行元空间虚拟机的C++代码即可完成。在元空间中，类和其元数据的生命周期和其对应的类加载器是相同的。换句话说，只要类加载存活，其加载的类的元数据也是存活的，因而不会被回收掉。准确的来说，每一个类加载器的存储区域都称作一个元空间，所有的元空间合在一起就是我们一直说的元空间。当一个类加载被垃圾回收标记为不在存活，其对应的元空间也会被回收。在元空间的回收过程中，没有重定位你和压缩等操作。但是元空间内的元数据会进行扫描来确定Java引用。
元空间虚拟机负责元空间的分配，其采用的形式为组块分配。组块的大小因类加载器的类型而异，在元空间虚拟机中存在一个全局的空闲组块列表。当一个类加载器徐亚奥组块时，他就会从这个全局的组块列表中获取并为之一个自己的组块列表。当一个类加载器不在存活，那么器持有的组块将会被释放，并返回给全军组块列表。类加载器从持有的组块又会被分为多个块，每一个块存储一个单元的原信息。组块中的块是线性分配(直接碰撞分配形式)。组块分配子内存映射区域，这些全军的寻你就内存映射区域以链表形式连接，一旦某个虚拟机内存映射区域清空，这部分内存就会返回给操作系统。
image
上图展示的是虚拟机内存映射区域如何进行元组块的分配。类加载器1和3表明使用了反射或者匿名类加载，他们使用了特定大小组块，而类加载器2和4根据内部条目数量使用小型或者中型的组块。
运行时常量池(Runtime Constant Pool)
运行常量池(Runtime Constant Pool)是方法区的一部分，Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池(Constant Pool Table)，用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池存放。
Java虚拟机对Class文件每一部分(自然包括常量池)的格式有严格的规定，每一个字节用于存储那种数据都必须符合规范上的要求才会被虚拟机认可、装载和运行。但对于运行常量池，Java虚拟机规范没有做任何细节的要求，不同的提供商实现的虚拟机可以按照自己的需求来实现此内存区域，不过一般而言，除了保存Class文件中的描述符号引用外，还会把翻译出的直接引用也存储在运行时常量池中。
运行时常量池相对于Class文件常量池的另一个重要特征是具备了动态性，Java语言并不要求常量一定只有编译器才能产生，也就是并非置入Class文件中的常量池的内容才能进入方法区运行常量池，运行期间也可能将新的常量放入池中，此特性被开发人员用的比较多的便是String的inrern()方法。
直接内存
直接内存(Direct Memory)并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。但这部分内存也被频繁运用，而却可能导致OutOfMemoryError异常出现，所以这里放到一起。
以NIO(New Input/Out)类为例，NIO引入了一种基于通道(Channel)与缓冲区(Buffer)的I/O方式，他可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆的DirectByteBuffer对象作为这块内存的引用进行操作。这样能避免在Java堆和Native堆中来回复制数据，在一些场景里显著提高性能。
本机直接内存的分配不会受到Java堆大小的限制，但是既然是内存，还是会受到本机总内存(包括RAM已经SWAP区或分页文件)大小已经处理器寻址空间的限制。服务器管理员在配置虚拟机参数时，会根据实际内存设置-Xmx等参数信息，但经常忽略直接内存，使得各个内存区域总和大于物理内存限制(包括物理的和操作系统的限制)，从而导致扩展时出现OutOfMemoryError异常。
