JVM入门:Java内存区域与内存溢出异常(根据《深入理解JVM虚拟机》整理)
1.运行时数据区域
Java虚拟机在执行java程序时会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途,以及创建和销毁的时间,有的区域随着虚拟机进程启动而存在,有些区域则是依赖用户线程的启动和结束而建立和销毁。Java虚拟机所管理的内存包括以下几个运行时数据区域。
1.1程序计数器
概念:
程序计数器是一块较小的内存空间,它的作用可以看作当前线程执行的字节码的行号指示器。
作用:
在虚拟机概念模型里,字节码解释器工作就是通过改变这个计数器的值来选取下一条需要执行的字节码指令(例如分支、循环、跳转等都依赖此计数器完成)。
每条线程都有一个独立的程序计数器,各条线程之间的计数器互不影响,独立存储,我们称这类内存区域为“线程私有”内存。
1.2Java虚拟机栈
概念:
虚拟机栈描述的是Java方法执行的内存模型:每个方法被执行的时候都会同时创建一个栈帧用于存储局部变量表、操作栈、动态链接、方法出口等信息。每一个方法被调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
关于局部变量表
**概念:**局部变量表存放了编译器可知的各种基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference类型)和returnAddresss类型。
reference类型:有两种可能
1.是一个指向对象的起始地址的引用指针。
2.是一个指向一个代表对象的句柄或着其他与此对象相关的位置(之后会解释指向句柄和直接指向对象的区别)
returnAddress类型:指向一条字节码的指令地址
局部变量表内存分配:long和double类型的数据会占2个局部变量空间(Slot,之后会提到),其余数据类型只会占1个。局部变量表所需空间在编译期间完成分配。当进入一个方法时,这个方法需要在帧中分配多大的局部变量空间是完全确定的,在方法运行期间不会改变局部变量表的大小。
1.3本地方法栈
本地方法栈为了虚拟机使用到的Native服务(java中Native修饰的方法,也就是用其他语言编写的方法)。
1.4Java堆
概念及作用:Java堆是被所有线程共享的一块内存区域,在虚拟机启动时创建。此内存唯一目的就是存放对象实例,几乎所有的对象都在此分配内存。
Java堆是垃圾收集器的主要区域,因此很多时候也被称作“GC堆”。
从垃圾回收的角度看:由于现在收集器基本都是采用的分代收集算法,所以java堆中还可以细分为新生代和老年代(再细致一点还可以分为更多的区);
从内存分配的角度看:线程共享的额Java堆中可能划分出多个线程私有的分配缓冲区。
java堆可以处于物理上不连续的内存空间中,只要逻辑上连续的即可。实现时,可以实现成固定大小的,也可以实现成可扩展的的(通过VM参数-Xms和-Xmx控制),如果在堆中没有完成实例分配,并且堆再也无法扩展时,会抛出OutOfMemoryError异常
1.5方法区
**概念:**方法区也是各个线程共享的内存区域,它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器后的代码数据。
方法区除了和堆一样不需要连续的内存和选择固定大小和扩展外,还可以实现不选择垃圾收集(例如类型的卸载,不过回收次数较少)。
当方法区无法满足内存分配时,将抛出OutOfMemoryError异常。
1.6运行时常量池
运行时常量池是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述外,还有一项信息就是常量池,用于存放编译期生成的各种字面量和符号引用,这部分内容将在类加载后存放到方法区的运行时常量池中。
运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性。编译期产生、预置如Class文件中常量池的内容、运行期间产生的新的常量都可以放入运行时常量池。
1.7直接内存
直接内存(Direct Memory)并不是虚拟机运行时数据区的一部分,也不是Java虚拟机规范中定义的内存区域,但是这部分内存也被频繁地使用,而且也可能导致outOfMemoryError 异常出现。在JDK 1.4中新加入了NIO (New Input/Output〉类,引入了一种基于通道(Channel)与缓冲区( Buffer)的I/O方式,它可以使用Native函数库直接分配堆外内存,然后通过一个存储在Java堆里面的 DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能,因为避免了在Java堆和Native堆中来回复制数据。
2.对象访问
对象访问是如何进行的?
Object obj=new Object();
假设这句代码出现在方法体中,那“Object obj”这部分的语义将会反映到Java栈的本地变量表中,作为一个reference类型数据出现。而“new Object()”这部分的语义将会反映到Java堆中,形成一块存储了Object类型所有实例数据值(Instance Data,对象中各个实例字段的数据〉的结构化内存,根据具体类型以及虚拟机实现的对象内存布局(Object Memory Layout)的不同,这块内存的长度是不固定的。另外,在Java堆中还必须包含能查找到此对象类型数据(如对象类型、父类、实现的接口、方法等)的地址信息,这些类型数据则存储在方法区中。
reference类型引用访问对象的方式
- 句柄访问:如果使用句柄访问方式,Java堆中将会划分出一块内存来作为句柄池,reference中存储的就是对象的句柄地址,而句柄中包含了对象实例数据和类型数据各自的具体地址信息,如下图所示。
- 直接指针访问:如果使用直接指针访问方式,Java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息,reference 中直接存储的就是对象地址,如下图所示。
两种方式优势:
使用句柄访问方式的最大好处就是reference中存储的是稳定的句柄地址,在对象被移动(垃圾收集时移动对象是非常普遍的行为)时只会改变句柄中的实例数据指针,而reference本身不需要被修改。
使用直接指针访问方式的最大好处就是速度更快,它节省了一次指针定位的时间开销,由于对象的访问在Java中非常频繁,因此这类开销积少成多后也是一项非常可观的执行成本。
3.OutOfMemoryError(内存溢出异常)
3.1Java堆溢出
Java堆用于储存对象实例,我们只要不断地创建对象,并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象,就会在对象数量到达最大堆的容量限制后产生内存溢出异常。
3.2虚拟机栈与本地方法栈溢出
如果线程请求的栈深度大于虚拟机所允许的最大深度,将抛出StackOverflowError异常。
例如:
public class TEST {
int i=0;
public void test(){
i++;
test();//无限递归
}
public static void main(String[] args) throws Exception {
TEST t=new TEST();
t.test();
}
}
如果虚拟机在扩展栈时无法申请到足够的内存空间,则抛出OutOfMemoryError异常。
3.3运行时常量池溢出
举例:常量池里存在过多运行时创建的字符串对象
3.4方法区溢出
方法区用于存放Class的相关信息,如类名、访问修饰符、常量池、字段描述、方法描述等。对于这个区域的测试,基本的思路是运行时产生大量的类去填满方法区,直到溢出。
方法区溢出也是一种常见的内存溢出异常,一个类如果要被垃圾收集器回收掉,判定条件是非常苛刻的。在经常动态生成大量Class的应用中,需要特别注意类的回收状况。这类场景常见的有:大量JSP或动态产生JSP文件的应用(JSP第一次运行时需要编译为Java类)、基于OSGi的应用(即使是同一个类文件,被不同的加载器加载也会视为不同的类)等。
3.5本机直接内存溢出
DirectMemory容量可通过-XX:MaxDirectMemorySize指定,如果不指定,则默认与Java堆的最大值(-Xmx指定)一样。代码清单2-6越过了DirectByteBuffer类,直接通过反射获取Unsafe实例并进行内存分配(Unsafe类的getUnsafe()方法限制了只有引导类加载器才会返回实例,也就是设计者希望只有rt.jar中的类才能使用Unsafe的功能)。因为,虽然使用DirectByteBuffer分配内存也会抛出内存溢出异常,但它抛出异常时并没有真正向操作系统申请分配内存,而是通过计算得知内存无法分配,于是手动抛出异常,真正申请分配内存的方法是unsafe.allocateMemory().
例子:
public class DirectMemoryOOM {
private static final int _1MB=1024*1024;
public static void main(String[] args) throws Exception {
Field unsafeField= Unsafe.class.getDeclaredFields()[0];
unsafeField.setAccessible(true);
Unsafe unsafe=(Unsafe) unsafeField.get(null);
while (true){
unsafe.allocateMemory(_1MB);
}
}
}
异常:
Exception in thread "main" java.lang.OutOfMemoryError
at sun.misc.Unsafe.allocateMemory(Native Method)
at com.cyq.Server.DirectMemoryOOM.main(DirectMemoryOOM.java:18)
n thread “main” java.lang.OutOfMemoryError
at sun.misc.Unsafe.allocateMemory(Native Method)
at com.cyq.Server.DirectMemoryOOM.main(DirectMemoryOOM.java:18)