Java内存区域与内存溢出异常
1.运行时数据区域
1.概述
-
Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干
个不同的数据区域。 -
这些区域有各自的用途,以及创建和销毁的时间,
-
有的区域随着虚拟机进程的启动而一直存在,有些区域则是依赖用户线程的启动和结束而建立和销毁。
2.程序计数器
-
程序计数器(Program Counter Register)是一块较小的内存空间,它可以看作是当前线程所执行的
字节码的行号指示器。 -
字节码解释器工作时就是通过改变这个计数器
的值来选取下一条需要执行的字节码指令,它是程序控制流的指示器,分支、循环、跳转、异常处
理、线程恢复等基础功能都需要依赖这个计数器来完成。 -
'线程私有:由于Java虚拟机的多线程是通过线程轮流切换、分配处理器执行时间的方式来实现的,在任何一个确定的时刻,一个处理器(对于多核处理器来说是一个内核)都只会执行一条线程中的指令。因此,为了线程切换后能恢复到正确的执行位置,每条线程都需要有一个独立的程序计数器,各条线程之间计数器互不影响,独立存储,我们称这类内存区域为“线程私
有”的内存。 -
如果线程正在执行的是一个Java方法,这个计数器记录的是正在执行的虚拟机字节码指令的地
址;如果正在执行的是本地(Native)方法,这个计数器值则应为空(Undefined)
3.Java虚拟机栈
1.定义
与程序计数器一样,Java虚拟机栈(Java Virtual M achine Stack)也是线程私有的,它的生命周期与线程相同
2.Java方法执行的线程内存模型
- 每个方法被执行的时候,Java虚拟机都会同步创建一个栈帧[1](Stack Frame)用于存储局部变量表、操作数栈、动态连接、方法出口等信息。
- 每一个方法被调用直至执行完毕的过程,就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
3.局部变量表
- 局部变量表存放了编译期可知的各种Java 虚拟机基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference类型,它并不等同于对象本身,可能是一个指向对象起始地址的引用指针,也可能是指向一个代表对象的句柄或者其他与此对象相关的位置)和returnAddress类型(指向了一条字节码指令的地址)。
- 这些数据类型在局部变量表中的存储空间以局部变量槽(Slot)来表示,其中64位长度的long和
double类型的数据会占用两个变量槽,其余的数据类型只占用一个。 - 局部变量表所需的内存空间在编译期间完成分配,当进入一个方法时,这个方法需要在栈帧中分配多
大的局部变量空间是完全确定的,在方法运行期间不会改变局部变量表的大小。这里说的“大小”是指变量槽的数量,虚拟机真正使用多大的内存空间(譬如按照1个变量槽占用32个比特、64个比特,或者更多)来实现一个变量槽,这是完全由具体的虚拟机实现自行决定的事情。
4.两类异常
- 如果线程请求的栈深度大于虚拟机所允许的深度,将抛出StackOverflowError异常
- 如果Java虚拟机栈容量可以动态扩展,当栈扩
展时无法申请到足够的内存会抛出OutOfMemoryError异常。
4.本地方法栈
- 本地方法栈(Native M ethod Stacks)与虚拟机栈所发挥的作用是非常相似的,其区别只是虚拟机
栈为虚拟机执行Java方法(也就是字节码)服务,而本地方法栈则是为虚拟机使用到的本地(Native) - 与虚拟机栈一样,本地方法栈也会在栈深度溢出或者栈扩展失败时分别抛出StackOverflowError和OutOfMemoryError异常。
5. Java堆
-
Java堆(Java Heap)是虚拟机所管理的内存
中最大的一块。 -
Java堆是被所有线程共享的一块内存区域,在虚拟机启动时创建。
-
此内存区域的唯一目的就是存放对象实例,Java
世界里“几乎”所有的对象实例都在这里分配内存。 -
Java堆是垃圾收集器管理的内存区域
-
回收内存角度
由于现代垃圾收集器大部分都是基于分
代收集理论设计的,所以Java堆中经常会出现“新生代”“老年代”“永久代”“Eden空间”“From Survivor空
间”“To Survivor空间”等名词, -
分配内存角度:
所有线程共享的Java堆中可以划分出多个
线程私有的分配缓冲区(Thread Local Allocation Buffer,TLAB),以提升对象分配时的
效率。
-
-
无论从什么角度,无论如何划分,都不会改变Java堆中存储内容的共性,无论是哪个区域,存储的都只能是对象的实例,将Java堆细分的目的只是为了更好地回收内存,或者更快地分配内存。
6.方法区
1.定义
方法区是各个线程共享的内存区域,它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。
2.抛出异常
如果方法区无法满足新的内存分配需求时,将抛出OutOfM emoryError异常。
7.运行时常量池
- 运行时常量池(Runtime Constant Pool)是方法区的一部分。
- 常量池表(Constant Pool Table),用于存放编译期生成的各种字面量与符号引用,这部分内容将在类加载后存放到方法区的运行时常量池中。
- 运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性,Java语言并不要求常量
一定只有编译期才能产生,也就是说,并非预置入Class文件中常量池的内容才能进入方法区运行时常
量池,运行期间也可以将新的常量放入池中,这种特性被开发人员利用得比较多的便是String类的
intern()方法。 - 当常量池无法再申请到内存时会抛出OutOfM emoryError异常
8.直接内存
- 直接内存(Direct M emory)并不是虚拟机运行时数据区的一部分,也不是《Java虚拟机规范》中
定义的内存区域。 - 这部分内存也被频繁地使用,而且也可能导致
OutOfM emoryError异常出现 - 在JDK 1.4中新加入了NIO(New Input/Output)类,引入了一种基于通道(Channel)与缓冲区
(Buffer)的I/O方式,它可以使用Native函数库直接分配堆外内存,然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。
2. HotSpot虚拟机对象探秘
1. 对象的创建
1.语言层面
在语言层面上,创建对象通常(例外:复制、反序列化)仅仅是一个new关键字而已
2.虚拟机层面
1. 创建步骤
- 当Java虚拟机遇到一条字节码new指令时,首先将去检查这个指令的参数是否能在常量池中定位到
一个类的符号引用,并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有,那
必须先执行相应的类加载过程 - 在类加载检查通过后,接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成
后便可完全确定(如何确定将在2.3.2节中介绍),为对象分配空间的任务实际上便等同于把一块确定
大小的内存块从Java堆中划分出来。 - 内存分配完成之后,虚拟机必须将分配到的内存空间(但不包括对象头)都初始化为零值,如果使用了TLAB的话,这一项工作也可以提前至TLAB分配时顺便进行。
- 至此,从虚拟机的视角来看,一个新的对象已经产生了。但是从Java程序的视角看来,对象创建才刚刚开始——构造函数,即Class文件中的
()方法还没有执行,所有的字段都为默认的零值,对象需要的其他资源和状态信息也还没有按照预定的意图构造好。一般来说(由字节码流中new指令后面是否跟随invokespecial指令所决定,Java编译器会在遇到new关键字的地方同时生成这两条字节码指令,但如果直接通过其他方式产生的则不一定如此),new指令之后会接着执行 ()方法,按照程序员的意愿对对象进行初始化,这样一个真正可用的对象才算完全被构造出来。
2. 分配方式
1. 指针碰撞
假设Java堆中内存是绝对规整的,所有被使用过的内存都被放在一边,空闲的内存被放在另一边,中间放着一个指针作为分界点的指示器,那所分配内存就仅仅是把那个指针向空闲空间方向挪动一段与对象大小相等的距离,这种分配方式称为“指针碰撞”
2. 空闲列表
如果Java堆中的内存并不是规整的,已被使用的内存和空闲的内存相互交错在一起,那
就没有办法简单地进行指针碰撞了,虚拟机就必须维护一个列表,记
录上哪些内存块是可用的,在分配的时候从列表中找到一块足够大的空间划分给对象实例,并更新列表上的记录,这种分配方式称为“空闲列表”
3. 使用条件
- 选择哪种分配方式由Java堆是否规整决定
- Java堆是否规整由所采用的垃圾收集器是否带有空间压缩整理(Compact)的能力决定。
- 当使用Serial、ParNew等带压缩整理过程的收集器时,系统采用的分配算法是指针碰撞,既简单又高效;
- 当使用CMS这种基于清除(Sweep)算法的收集器时,理论上[1]就只能采用较为复杂的空闲列表来分配内存
4. 考虑问题
- 问题:对象创建在虚拟机中是非常频繁的行为,即使仅仅修改一个指针所指向的位置,在并发情况下也并不是线程安全的,可能出现正在给对象A分配内存,指针还没来得及修改,对象B又同时使用了原来的指针来分配内存的情况。
- 解决方案:
- 对分配内存空间的动作进行同步处理——实际上虚拟机是采用CAS配上失败重试的方式保证更新操作的原子性;
- 另外一种是把内存分配的动作按照线程划分在不同的空间之中进行,即每个线程在Java堆中预先分配一小块内存,称为本地线程分配缓冲(Thread Local AllocationBuffer,TLAB),哪个线程要分配内存,就在哪个线程的本地缓冲区中分配,只有本地缓冲区用完了,分配新的缓存区时才需要同步锁定
3.HotSpot解释器代码片段
// 确保常量池中存放的是已解释的类 if (!constants->tag_at(index).is_unresolved_klass()) { // 断言确保是klassOop和instanceKlassOop(这部分下一节介绍) oop entry = (klassOop) *constants->obj_at_addr(index); assert(entry->is_klass(), "Should be resolved klass"); klassOop k_entry = (klassOop) entry; assert(k_entry->klass_part()->oop_is_instance(), "Should be instanceKlass"); instanceKlass* ik = (instanceKlass*) k_entry->klass_part(); // 确保对象所属类型已经经过初始化阶段 if ( ik->is_initialized() && ik->can_be_fastpath_allocated() ) { // 取对象长度 size_t obj_size = ik->size_helper(); oop result = NULL; // 记录是否需要将对象所有字段置零值 bool need_zero = !ZeroTLAB; // 是否在TLAB中分配对象 if (UseTLAB) { result = (oop) THREAD->tlab().allocate(obj_size); } if (result == NULL) { need_zero = true; // 直接在eden中分配对象 retry: HeapWord* compare_to = *Universe::heap()->top_addr(); HeapWord* new_top = compare_to + obj_size; // cmpxchg是x86中的CAS指令,这里是一个C++方法,通过CAS方式分 配空间,并发失败的 话,转到retry中重试直至成功分配为止 if (new_top <= *Universe::heap()->end_addr()) { if (Atomic::cmpxchg_ptr(new_top, Universe::heap()- >top_addr(), compare_to) != compare_to) { goto retry; } result = (oop) compare_to; } } if (result != NULL) { // 如果需要,为对象初始化零值 if (need_zero ) { HeapWord* to_zero = (HeapWord*) result + sizeof(oopDesc) / oopSize; obj_size -= sizeof(oopDesc) / oopSize; if (obj_size > 0 ) { memset(to_zero, 0, obj_size * HeapWordSize); } } // 根据是否启用偏向锁,设置对象头信息 if (UseBiasedLocking) { result->set_mark(ik->prototype_header()); } else { result->set_mark(markOopDesc::prototype()); } result->set_klass_gap(0); result->set_klass(k_entry); // 将对象引用入栈,继续执行下一条指令 SET_STACK_OBJECT(result, 0); UPDATE_PC_AND_TOS_AND_CONTINUE(3, 1); } } }
2.对象的内存布局
1.分类
- 对象头(Header)
- 实例数据(Instance Data)
- 对齐填充(Padding)。‘
2.对象头
- 第一类:用于存储对象自身的运行时数据,如哈希码(HashCode)、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等,这部分数据的长度在32位和64位的虚拟机(未开启压缩指针)中分别为32个比特和64个比特,官方称它为“Mark Word”
- 对象头的另外一部分是类型指针,即对象指向它的类型元数据的指针,Java虚拟机通过这个指针
来确定该对象是哪个类的实例。并不是所有的虚拟机实现都必须在对象数据上保留类型指针,换句话
说,查找对象的元数据信息并不一定要经过对象本身
3. 实例数据
对象真正存储的有效信息
4. 对象填充
仅仅起着占位符的作用。由于HotSpot虚拟机的自动内存管理系统要求对象起始地址必须是8字节的整数倍,换句话说就是任何对象的大小都必须是8字节的整数倍。对象头部分已经被精心设计成正好是8字节的倍数(1倍或者2倍),因此,如果对象实例数据部分没有对齐的话,就需要通过对齐填充来补全。
5. 32位虚拟机Mark Word的存储布局:
// Bit-format of an object header (most significant first, big endian layout below): // // 32 bits: // -------- // hash:25 ------------>| age:4 biased_lock:1 lock:2 (normal object) // JavaThread*:23 epoch:2 age:4 biased_lock:1 lock:2 (biased object) // size:32 ------------------------------------------>| (CMS free block) // PromotedObject*:29 ---------->| promo_bits:3 ----->| (CMS promoted object)
3.访问定位
1. 访问方法
Java程序会通过栈上的reference数据来操作堆上的具体对象。
2. 主流访问方式
1. 句柄访问
如果使用句柄访问的话,Java堆中将可能会划分出一块内存来作为句柄池,reference中存储的就是对象的句柄地址,而句柄中包含了对象实例数据与类型数据各自具体的地址信息
2. 直接访问
如果使用直接指针访问的话,Java堆中对象的内存布局就必须考虑如何放置访问类型数据的相关信息,reference中存储的直接就是对象地址,如果只是访问对象本身的话,就不需要多一次间接访问
3. 优缺点
- 使用句柄来访问的最大好处就是reference中存储的是稳定句柄地址,在对象被移动(垃圾收集时移动对象是非常普遍的行为)时只会改变句柄中的实例数据指针,而reference本身不需要被修改。
- 使用直接指针来访问最大的好处就是速度更快,它节省了一次指针定位的时间开销,由于对象访问在Java中非常频繁,因此这类开销积少成多也是一项极为可观的执行成本
3.OutOfMemoryError异常
1. 堆溢出
定义
随着对象数量的增加,总容量触及最大堆的容量限制后就会产生内存溢出异常
测试代码
通过参数-XX :+HeapDumpOnOutOf-MemoryError可以让虚拟机在出现内存溢出异常的时候Dump出当前的内存堆转储快照以便进行事后分析
/** * VM Args:-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError * @author zzm */ public class HeapOOM { static class OOMObject { } public static void main(String[] args) { List<OOMObject> list = new ArrayList<OOMObject>(); while (true) { list.add(new OOMObject()); } } } //运行结果: java.lang.OutOfMemoryError: Java heap space Dumping heap to java_pid3404.hprof ... Heap dump file created [22045981 bytes in 0.663 secs]
处理方式
通过内存映像分析工具(如Eclipse Memory Analyzer)对Dump出来的堆转储快照进行分析。
- 确认内存中导致OOM 的对象是否是必要的,也就是要先分清楚到底是出现了内存泄漏(M emory Leak)还是内存溢出(Memory Overflow)。
-
- 如果是内存泄漏,可进一步通过工具查看泄漏对象到GC Roots的引用链,找到泄漏对象是通过怎样的引用路径、与哪些GC Roots相关联,才导致垃圾收集器无法回收它们,根据泄漏对象的类型信息以及它到GC Roots引用链的信息,一般可以比较准确地定位到这些对象创建的位置,进而找出产生内存泄漏的代码的具体位置。
- 如果不是内存泄漏,换句话说就是内存中的对象确实都是必须存活的,那就应当检查Java虚拟机的堆参数(-Xmx与-Xms)设置,与机器的内存对比,看看是否还有向上调整的空间。再从代码上检查是否存在某些对象生命周期过长、持有状态时间过长、存储结构设计不合理等情况,尽量减少程序运行期的内存消耗。
2.虚拟机栈和本地方法栈溢出
设置
由于HotSpot虚拟机中并不区分虚拟机栈和本地方法栈,因此对于HotSpot来说,-Xoss参数(设置
本地方法栈大小)虽然存在,但实际上是没有任何效果的,栈容量只能由-Xss参数来设定
抛出异常
- 如果线程请求的栈深度大于虚拟机所允许的最大深度,将抛出StackOverflowError异常。
- 如果虚拟机的栈内存允许动态扩展,当扩展栈容量无法申请到足够的内存时,将抛出
OutOfMemoryError异常。
测试代码
/** VM Args:-Xss128k */public class JavaVMStackSOF { private int stackLength = 1; public void stackLeak(){ stackLength++; stackLeak(); } public static void main(String[] args) { JavaVMStackSOF oom = new JavaVMStackSOF(); try{ oom.stackLeak(); }catch(Throwable e){ e.printStackTrace(); System.out.println("stack length:" + oom.stackLength); } } } //运行结果: java.lang.StackOverflowError at aaa.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:9) stack length:9430
3.方法区和运行时常量溢出
设置
-
运行时常量溢出 : 通过-XX:PermSize和-XX:M axPermSize限制永久代的大小,即可间接限制其中常量池的容量
-
方法区溢出 : 方法区的主要职责是用于存
放类型的相关信息,如类名、访问修饰符、常量池、字段描述、方法描述等。对于这部分区域的测试,基本的思路是运行时产生大量的类去填满方法区,直到溢出为止。
测试代码
/** * VM Args:-XX:PermSize=6M -XX:MaxPermSize=6M * @author zzm */ public class RuntimeConstantPoolOOM { public static void main(String[] args) { // 使用Set保持着常量池引用,避免Full GC回收常量池行为 Set<String> set = new HashSet<String>(); // 在short范围内足以让6MB的PermSize产生OOM了 short i = 0; while (true) { set.add(String.valueOf(i++).intern()); } } } //运行结果: Exception in thread "main" java.lang.OutOfMemoryError: PermGen space at java.lang.String.intern(Native Method) at org.fenixsoft.oom.RuntimeConstantPoolOOM.main(RuntimeConstant PoolOOM.java: 18)
防御措施
·-XX:M axM etaspaceSize:设置元空间最大值,默认是-1,即不限 制,或者说只受限于本地内存 大小。 ·-XX:M etaspaceSize:指定元空间的初始空间大小,以字节为单 位,达到该值就会触发垃圾收集 进行类型卸载,同时收集器会对该值进行调整:如果释放了大量的空 间,就适当降低该值;如果释放 了很少的空间,那么在不超过-XX:M axM etaspaceSize(如果设置了 的话)的情况下,适当提高该 值。 ·-XX:M inM etaspaceFreeRatio:作用是在垃圾收集之后控制最小 的元空间剩余容量的百分比,可 减少因为元空间不足导致的垃圾收集的频率。类似的还有-XX:M ax-M etaspaceFreeRatio,用于控制最 大的元空间剩余容量的百分比。
4.本机直接内存溢出
设置
直接内存(Direct M emory)的容量大小可通过-XX:M axDirectMemorySize参数来指定,如果不去指定,则默认与Java堆最大值(由-Xmx指定)
测试代码
/** * VM Args:-Xmx20M -XX:MaxDirectMemorySize=10M * @author zzm */ 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 org.fenixsoft.oom.DMOOM.main(DMOOM.java:20)
明显特征
- 在Heap Dump文件中不会看见有什么明显的异常
情况 - 如果发现内存溢出之后产生的Dump文件很小,而程序中又直接或间接使用了DirectM emory(典型的间接使用就是NIO),那就可以考虑重点检查一下直接内存方面的原因了。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步