Java内存区域

1、Java虚拟机运行时数据区

线程共享的数据区：方法区、堆、执行引擎、本地库接口。
线程隔离的数据区：程序计数器、虚拟机栈、本地方法栈。

2、程序计数器

程序计数器（ProgramCounterRegister）是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里（仅是概念模型，各种虚拟机可能会通过一些更高效的方式去实现），字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器完成。

由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器（cpu的内核）都只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的位置，每条线程都需要有一个独立的程序计数器（即线程私有），各线程之间计数器互不影响，独立存储。

1、如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址。
2、如果正在执行的是Native方法，这个计数器值为空（Undefined）。
2、此内存区域是唯一一个在Java虚拟机规范中没有规定任何outOfMemoryError情况的区域。

3、Java虚拟机栈

此处可以联系《JVM相关知识》1.2.4节内容。

Java虚拟机栈（Java Virtual Machine Stacks），线程私有，他的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型；每个方法在执行的同时都会创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用到执行完成的过程，就对应着一个栈帧在虚拟机栈中push到pop的过程。下图是栈帧的概念结构。

局部变量表存放了编译期可知的各种信息:

• 各种基本数据类型：boolean、byte、char、short、int、float、long、double，64位的long和doble类型的数据占用两个局部变量空间（Slot），其余的数据类型只占用1个；
• 对象引用：reference类型，它不等同于对象本身，可能是一个指向对象起始地址 的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置；
• returnAddress类型

局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。

在Java虚拟机规范中，对这个区域规定了两种异常状况：

1. 如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；
2. 如果虚拟机栈可以动态扩展，且扩展时无法申请到足够的内存，就会抛出OutOfMemeoryError异常；

4、本地方法栈

本地方法栈（Native Method Stack），线程私有，与虚拟机栈所发挥的作用是非常相似的，他们的区别是：

• 虚拟机栈为虚拟机执行Java方法（也就是字节码）服务；
• 本地方法栈为虚拟机使用到的Native方法服务。

有的虚拟机（如HotSpot虚拟机）直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemeoryError异常。

5、Java堆

此处可以联系文章《GC的算法和种类》和《GC参数》。

关于Java堆：

• Java虚拟机所管理的内存中最大的一块;
• 线程共享;
• 在虚拟机启动时创建;
• 唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存：之所以说几乎，是因为虽然Java虚拟机规范中描述是：所有的对象实例及数组都要在堆上分配。但是随着JIT编译器的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术使得“所有对象都分配在堆上”渐渐变得不那么绝对。
• 垃圾收集管理的主要区域，从内存回收的角度，可以细分为：
  
  • 新生代
    
    • Eden空间
    • From Survivor空间
    • To Survivor空间
  • 老年代
• 从内存分配的角度，线程共享的Java堆中可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB）。无论如何划分，都与存放内容无关，无论哪个区域，存储的都仍然是对象实例，进一步划分的目的是为了更好地回收内存，或者更快地分配内存。

Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可。当前主流的JVM都是按照可扩展来实现的（通过-Xms和-Xms来控制）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。

6、方法区

方法区（Method Area），它存储了每一个类的结构信息，例如运行时常量池（ Runtime Constant Pool）、字段和方法数据、构造函数和普通方法的字节码内容、还包括一些在类、实例、接口初始化时用到的特殊方法。

• 线程共享
• 是堆的一个逻辑部分，但他有个别名叫Non-Heap（非堆）；
• 存储->已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据；
• 不需要连续的内存，可以选择固定大小，可扩展；
• 可以选择不实现垃圾收集（这区域的内存回收目标主要是针对常量池的回收和对类型的卸载）；
• 当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。

关于永久代与方法区？

• 《Java虚拟机规范》只是规定了有方法区这么个概念和它的作用，并没有规定如何去实现它。那么，在不同的 JVM 上方法区的实现肯定是不同的了。 虽然可以牵强（牵强是指仅仅是在HotSpot虚拟机上才能勉强成立，其他的虚拟机如JRockit、J9等并没有永久代这一说法。）的解释这种将方法区和永久代等同对待观点，但最终方法区和永久带还是不同的。一个是标准一个是实现。这就相当于你将java中的接口和接口的实现等同对待了一样。
• Sun公司的HotSpot把GC分代收集扩展至方法区，或者说使用永久代来实现方法区，这样HotSpot的GC就可以像管理Java堆一样管理这部分内存，也能够不必专门为方法区编写一套内存管理的代码。
• 目前来看，用永久代实现方法区并不合适，因为这样更容易遇到内存溢出问题（永久代有-XX:MaxPermSize的上线，J9和JRockit只要没有触碰到进程可用内存的上限，如32位系统中的4GB，就不会出现问题），而且有极少数方法（如String.intern()）会因为这个原因导致不同虚拟机下有不同的表现。
• jdk1.7之前可使用如下参数调节方法区的大小
  
  • -XX:PermSize ——方法区初始大小
  • -XX:MaxPermSize ——方法区最大大小，超过这个值将会抛出OutOfMemoryError异常:java.lang.OutOfMemoryError: PermGen
• 在jdk1.7之后，已经把原本放在永久代的字符串常量池移出了。

7、运行时常量池

• 运行时常量池（Runtime Constant Pool）是方法区的一部分；
• 运行时常量池除了保存Class文件中描述的符号引用外，还会保存翻译出来的直接引用（详解见下）；
• 受到方法区内存的限制，当常量池无法再申请到内存时，会抛出OutOfMemoryError异常。
  

1、Class文件中存放的信息：除类的版本、字段、方法、接口外，还有一项就是常量池（Constant Pool Table），该常量池不同于运行时常量池，它用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池存放。

2、运行时常量池是把Class文件常量池加载进来，每个类有一个独立的。刚开始运行时常量池里的链接都是符号引用，跟在Class文件里一样；边运行边就会把用到的常量转换成直接引用，例如说要Class A调用Foo.bar()方法，A.class文件里就会有对该方法的Methodref常量，是个符号引用（只有名字没有实体），加载到运行时常量池也还是一样是符号引用，等真的要调用该方法的时候该常量就会被resolve为一个直接引用（直接指向要调用的方法的实体）。

3、运行时常量池相对于Class文件常量池还有一个特征是具备动态性，Java语言并不要求常量一定只有编译器才能产生，也就是并非只有在Class文件中常量池的内容才能进入方法区的运行时常量池，运行期间也可能将新的常量放入池中（用的较多的就是String类的intern()方法）。

附：直接内存

直接内存（Direct Memory）并不是虚拟即运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。但是这部分内存也被频繁使用，而且也可能导致OutOfMemoryError异常。

NIO类中，引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后同一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。

本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，肯定还是会受到本机总内存（包括RAM以及SWAP区或者分页文件）大小以及处理器寻址空间的限制。