欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

Java虚拟机内存模型与内存溢出异常

程序员文章站 2022-07-15 14:38:09
...

JVM 内存模型

Java虚拟机在在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。

Java虚拟机内存模型与内存溢出异常

线程私有区域

线程私有数据区域生命周期与线程相同, 依赖用户线程的启动/结束而创建/销毁(在Hotspot VM内, 每个线程都与操作系统的本地线程直接映射, 因此这部分内存区域的存/否跟随本地线程的生/死).

Program Counter Register(程序计数器)

程序计数器是一块较小的内存空间,它可以看做是当前线程所执行的字节码的行号指示器,字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令,分支、循环、跳转、异常处理、线程恢复的基础功能都需要依赖这个计数器来完成。为了线程切换后能恢复到正确的执行位置,每条线程都有一个独立的程序计数器,各条线程之间计数器互不影响,独立存储,我们称这类内存区域为“线程私有”的内存。
如果线程正在执行的是一个Java方法,计数器记录的是正在执行的虚拟机字节码指令的地址,如果执行的时Native方法,计数器则为空(Undefied),此内存区域是唯一一个在Java虚拟机规范中没有OutOfMemeoryError的区域。

Java Virtual Machine Stacks(Java 虚拟机栈)

Java虚拟机栈描述的是Java方法执行的内存模型:每个方法在执行的同时都会创建一个栈帧(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出口、返回地址等信息。每个方法从调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中入栈到出栈的过程(VM提供了-Xss来指定线程的最大栈空间, 该参数也直接决定了函数调用的最大深度)。
局部变量表(对应我们常说的‘堆栈’中的‘栈’,实际划分更复杂)存放了编译期可知的各种基本数据类型(如boolean、byte、char、short、int、float、long、double等) 、对象引用(reference 类型, 它不等同于对象本身, 可能是一个指向对象起始地址的指针, 也可能指向一个代表对象的句柄或其他与此对象相关的位置)和returnAddress类型(指向了一条字节码指令的地址)。其中64位长度的long和double类型的数据会占用2个局部变量空间(Slot),其余的数据类型只占用1个。局部变量表的内存空间会在编译期间在栈帧中完成分配。
异常情况:如果线程请求的栈深度大于虚拟机所允许的深度,将抛出Stack Overflow异常,如果虚拟机栈可以动态扩展,扩展时无法申请到足够的内存,会抛出OutOfMemoryError异常。

Native Method Stack(本地方法栈)

与Java 虚拟机栈作用相似, 区别是Java 虚拟机栈为虚拟机执行Java方法(字节码)服务, 而本地方法栈则为虚拟机使用到的Native方法服务, 虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构没有强制规定,如果一个VM实现使用C-linkage模型来支持Native调用, 那么该栈将会是一个C栈, 但HotSpot VM直接就把本地方法栈和虚拟机栈合二为一。
异常情况:与Java 虚拟机栈一样,本地方法栈也会抛出Stack Overflow和OutOfMemoryError异常。

线程共享区域

Java Heap(Java 堆)

Java堆是被所有线程共享的一块内存区域,在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例,几乎所有对象实例和数组都要在堆上分配(栈上分配、标量替换除外), 因此是VM管理的最大一块内存, 也是垃圾收集器的主要活动区域。由于现代VM采用分代收集算法, 因此Java堆从GC的角度还可以细分为: 新生代(Eden区、From Survivor区和To Survivor区)和老年代; 而从内存分配的角度来看, 线程共享的Java堆还还可以划分出多个线程私有的分配缓冲区(TLAB),而进一步划分的目的是为了更好地回收内存和更快地分配内存。Java堆可以是物理上不连续的内存空间,当前主流的虚拟机都是按照可扩展来实现的(通过-Xmx和-Xms控制)。
异常情况:异常可能会抛出OutOfMemoryError异常。

Method Area(方法区)

方法区与Java堆一样,是各个线程共享的内存区域,用于存储已被虚拟机加载的类信息、常量、静态常量、即时编译器编译后的代码等数据。Java虚拟机规范把方法区描述为堆的一个逻辑部分,但它却有一个别名叫做Non-Heap(非堆),目的应该是与Java堆区分开来。

HotSpot开发者把方法区称为”永久代”(Permanent Genneration): HotSpot VM把GC分代收集扩展至方法区, 即使用Java堆的永久代来实现方法区, 这样HotSpot的垃圾收集器就可以像管理Java堆一样管理这部分内存, 而不必为方法区开发专门的内存管理器(永久代的内存回收的主要目标是针对常量池的回收和类型的卸载, 因此收益一般很小)。但因为这样更容易出现OutOfMemoryError(永久代有-XX:MaxPermSize的上限)。
在1.7的HotSpot已经将原本放在永久代的字符串常量池移出。
在1.8中, 永久代已经被彻底移除, 取而代之的是元数据区Metaspace(这一点在查看GC日志和使用jstat -gcutil查看GC情况时可以观察到),与永久代不同, 如果不指定Metaspace大小, 如果方法区持续增长, VM会默认耗尽所有系统内存。
异常情况:当方法区无法满足内存分配需求时,将抛出OutOfMemoryError异常。

Runtime Constant Pool(运行时常量池)

方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外,还有一项常量池(Constant Pool Table)用于存放编译期生成的各种字面量和符号引用, 这部分内容会存放到方法区的运行时常量池中。运行时常量池相对于Class文件常量池的另一个重要特征是具备动态性,Java语言并不要求常量一定只能在编译期产生, 即并非预置入Class文件中常量池的内容才能进入方法区运行时常量池, 运行期间也可能将新的常量放入池中, 如String的intern()方法。
异常情况:由于是方法区的一部分,自然受内存的限制,可能抛出OutOfMemoryError异常。

Direct Memroy(直接内存)

直接内存并不是虚拟机运行时数据区的一部分,也不是Java虚拟机规范中定义的内存区域,但这部分内存也被频繁地使用,而且也可能导致OutOfMemoryError异常。
JDK 1.4中新加入了NIO(New Input/Output)类,引入了一种基于通道(Channel)与缓存区(Buffer)的I/O 方式,它可以使用Native函数库直接分配堆外内存,然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样能显著提高性能,避免了在Java堆和Native堆中来回复制数据。
异常情况:直接内存的分配不会受到Java堆大小的限制,但肯定受到本机内存(RAM、SWAP及分页文件)及处理器寻址空间的限制,配置虚拟机参数时经常会忽略直接内存,导致内存区域之和大于物理内存限制(物理和操作系统级限制)而导致动态扩展出现OutOfMemoryError。

HotSpot虚拟机对象

在介绍完Java的运行时数据区后,我们进一步去了解HotSpot虚拟机在Java堆中对象分配、布局和访问的全过程。

对象的创建

(限于普通Java对象,不包括数组和Class对象)
虚拟机遇到一条new指令时,首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用,并检查这个符号引用代表的类是否已被加载、解析和初始化。如果没有,那必须先执行相应的类加载过程。
在类加载检查通过后,对象所需内存的大小便可以完全确定,虚拟机将为新生对象分配内存,为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来。内存的分配方式由Java堆是否规整决定,Java堆是否规整由所采用的垃圾收集器是否带有压缩整理功能决定(Serial、ParNew等带Compact过程的收集器,采用的分配算法是指针碰撞;CMS基于Mark-Sweep算法的收集器,采用空闲列表)。

  • Java堆中内存是绝对规整:所有用过的内存都放在一边,空闲的内存存放另一边,中间放着一个指针作为分界点的指示器,当分配内存时把指针向空闲空间那边挪动一段与对象大小相等的距离,这种分配方式为“指针碰撞”(Bump the Pointer)。
  • Java堆中内存不规整:已使用的内存和空闲的内存相互交错,虚拟机维护着一个列表,记录上那些内存块是可用的,在分配的时候从列表中找到一块足够大的空间划分给对象实例,并更新列表上的记录,这种分配方式为“空闲列表”(Free List)。

对象的创建频繁,分配地址可能会出现并发情况,解决这个问题有两种方案:

  • 对分配内存空间的动作进行同步处理:虚拟机采用CAS配上失败重试的方式保证更新操作的原子性。
  • 把内存分配的动作按照线程划分在不同的空间之中,即每个线程在Java堆中预先分配一块内存,称为本地线程分配缓冲(Thread Local Allocation Buffer,TLAB),哪个线程要分配内存就在哪个线程的TLAB上分配,只有TLAB用完并分配新的TLAB时,才需要同步锁定。虚拟机是否使用TLAB通过-XX:+/-UseTLAB参数设定。

内存分配完成后,虚拟机会将分配到的内存空间初始化为零值(不包括对象头),这就是为什么对象的实例字段可以不赋初始化值就可以直接使用,程序能访问到这些字段的数据类型所对应的零值。接下来,虚拟机会对对象进行必要的设置(对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息),这些信息存放在对象的对象头(Object Header)之中。

对象的内存布局

在HotSpot虚拟机中,对象在内存中存储的布局可以分为3块区域:对象头(Header)、实例数据(Instance Data)和对齐填充(Padding)。

对象头

对象头分为两部分,存储对象自身的运行时数据(哈希码、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等),这部分数据的长度在32位和64位虚拟机中分别为32bit和64bit,官方称为“Mark Word”,实际情况下,Mark Word会根据对象的状态复用自己的存储空间;另一部分是类型指针,即对象指向它的类元数据的指针,虚拟机通过这个指针来确定这个对象是哪个类的实例,并不是所有的虚拟机实现都必须在对象数据上保留类型指针,比如后面介绍的句柄。另外,如果对象是一个java数组,那么在对象头中还必须要有一块用于记录数组长度的数据,因为虚拟机可以通过普通java对象的元数据确定java对象的大小,但是从数组的元数据中却无法确定数组的大小。

实例数据

对象真正存储的有效数据,程序代码中多定义的各种类型字段内容(包括父类继承下来的)存储顺序会受到虚拟机分配策略参数和字段定义顺序的影响。HotSpot虚拟机默认的分配策略为longs/doubles、ints、shorts/chars、bytes/booleans、oops(Ordinary Object Pointers)。从分配策略可以看出,相同宽度的字段总是被分配到一起,在满足这个前提条件下,父类中定义的变量会出现在子类之前。

对齐填充

并不是必须存在的,也没有特别的含义,它仅仅起着占位符的作用。HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍,即对象的大小必须是8字节的整数倍,而对象头部分正好是8字节的倍数(1倍或2倍),对象实例数据部分没有对齐时,就需要通过对齐填充来补全。

对象的访问定位

建立对象是为了使用对象,java程序需要通过栈上的reference数据来操作堆上的具体对象。Java虚拟机规范中只规定了一个指向对象的引用reference类型,并没有定义这个引用应该通过何种方式去定位、访问堆中的对象的具体位置,所有对象访问方式也是取决于虚拟机实现而定。目前主流的访问方式有使用句柄和直接指针两种。

通过句柄访问对象:Java堆中将会划分出一块内存来作为句柄池,reference中存储的是对象的句柄地址,句柄中包含了对象实例数据与类型数据各自的具体地址信息。

Java虚拟机内存模型与内存溢出异常

通过直接指针访问对象:在Java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息,而reference中存储的直接就是对象地址。

Java虚拟机内存模型与内存溢出异常

使用句柄访问的好处是reference中存储的是稳定的句柄地址,在对象被移动时自会改变句柄中的实例数据指针,而reference本身不需要修改。使用直接指针访问方式的最大好处是速度快,它节省了一次指针定位的时间开销。HotSpot使用的是直接指针访问对象。

OutOfMemoryError 异常

Java 堆溢出

Java堆用于存储对象实例,只要不断地创建对象,并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制来清除这些对象,当对象数量到达最大堆的容量限制后就会产生内存溢出异常。VM Args后面的是run时虚拟机参数
Java虚拟机内存模型与内存溢出异常

当出现Java堆内存溢出时,异常堆栈信息“java.lang.OutOfMemoryError”会跟着进一步提示“Java heap space”。

Java虚拟机内存模型与内存溢出异常

解决Heap内存异常,一般通过内存映像分析工具(如Eclipse Memory Analyzer)对Dump出来的堆转储快照进行分析,重点是确认内存中的对象是否是必要的,也就是要先分清楚到底是出现了内存泄漏(Memory Leak)还是内存溢出(Memory OverFlow)。
内存泄漏:通过工具查看泄漏对象到GC Roots的引用链,找到泄漏对象的类型信息及GC Roots引用链的信息,定位出泄漏代码位置。
内存溢出:检查虚拟机的堆参数(-Xmx与-Xms),是否可以调大堆内存,从代码上检查是否存在对象生命周期过长、持有状态过长,减少程序运行期内存消耗。

Eclipse Memory Analyzer工具安装

Java虚拟机内存模型与内存溢出异常

虚拟机栈和本地方法栈溢出

在HotSpot虚拟机中不区分虚拟机栈和本地方法栈,Java虚拟机规范中描述了两种异常:

  • 如果线程请求的栈深度大于虚拟机所允许的最大深度,将抛出*Error异常。
  • 如果虚拟机在扩展栈时无法申请到足够的内存空间,则抛出OutOfMemoryError异常。

单线程下,无论时由于栈帧太大还是虚拟机栈容量太小,当内存无法分配时,虚拟机抛出的都是*Error异常。通过不断地建立线程的方式可以产生内存溢出异常。

/**Error异常
 * VM Args:-Xss128k
 */
public class StackOF{
    private int stackLength = 1;

    public void stackLeak(){
        stackLength++;
        stackLeak();
    }
    public static void main(String[] args) {
        StackOF oom = new StackOF();
        oom.stackLeak();
    }
}

使用以下代码进行测试,记住要保存当前的工作,由于在Windows平台的虚拟机中,Java的线程是映射到操作系统的内核线程上,可能会导致操作系统假死。(本人测试操作系统假死了)

/*
 * OutOfMemoryError
 * VM Args: -Xss2M
 */
public class StackOOM {

    private void dontStop(){
        while(true){
        }
    }

    public void stackLeakByThread(){
        while(true){
            Thread thread = new Thread(new Runnable(){
                @Override
                public void run() {
                    dontStop();
                }

            });
            thread.start();
        }
    }

    public static void main(String[] args) {
        StackOOM oom = new StackOOM();
        oom.stackLeakByThread();
    }
}

多线程栈内存溢出
32位的windows操作系统分配给每个进程的内存限制为2G,虚拟机提供了参数来控制Java堆和方法区的这两部分内存的最大值,进程的内存2G(操作系统限制)减去Xms(最大堆容量),再减去MaxPermSize(最大方法区容量),程序计数器消耗内存很小(可忽略),最后减去虚拟机进程本身消耗的内存,剩余的内存便由虚拟机栈和本地方法栈瓜分。每个线程分配到的栈容量越大,可以建立的线程数量就越少。如果是建立过多线程导致的内存溢出,在不能减少线程数或更换64位虚拟机的情况下,就只能通过减少最大堆和减少每个线程的栈容量来换取更多的线程。

方法区和运行时常量池溢出

由于运行时常量池是方法区的一部分,因此放一起进行。String.intern()是一个Native方法,它的作用是:如果字符串常量池中已经包含了一个该String对象的字符串,则返回池中该字符串的对象,否则,将该String对象包含的字符串添加到常量池中,并返回此对象的引用。在JDK 1.6及以前版本常量池分配在永久代,可以通过-XX:PermSize和-XX:MaxPermSize限制方法区的大小,从而间接限制常量池的大小。

/**
 * VM Args: -XX:PermSize=10M -XX:MaxPermSize=10M
 * @author yt
 *
 */
public class MethodOOM {
    public static void main(String[] args) {
        //使用List保持常量池引用,避免Full GC回收常量池
        List<String> list = new ArrayList<>();
        int i = 0;
        while(true){
            list.add(String.valueOf(i++).intern());
        }
    }
}

使用的JDK 1.6会出现Exception in thread “main”java.lang.OutOfMemoryError:permGen space
,说明运行时常量池属于方法区(HotSpot虚拟机永久代)的一部分,而JDK 1.7将运行时常量池移出了永久代,while会无限循环。
JDK 1.6与JDK 1.7中String.intern()区别:
JDK1.6中,intern()方法会把首次遇到的字符串对象复制到永久代中,返回的也是永久代中这个字符串实例的引用,而JDK1.7中,intern()实现不会复制实例,只是在常量池中记录首次出现的实例的引用。


声明:
本文内容参考于周志明的《深入理解Java虚拟机 JVM高级特性与最佳实践》