Java内存区域

关注

原创最新推荐文章于 2025-06-04 02:08:33 发布 308 阅读 AI 写同款· GEO 优化 ›

当知识图谱遇见多模态：突破文本界限的智能认知革命本文探讨了知识图谱与多模态技术的融合，揭示了其在医疗诊断、文化保护等领域的革命性应用。通过图神经网络、对比学习框架和跨模态注意力机制等技术，实现了文本、图像和音频数据的智能关联与认知。文章还分享了在Neo4j等图数据库中的实践案例和优化策略，为构建下一代智能认知系统提供了技术参考。阅读详情

作为Java开发人员，大家都知道内存都是虚拟机自动管理的，我们不需要做任何操作，项目就能正常运行。那么问题来了，我们需要了解Java中内存是如何分配的吗？没错，虚拟机帮助我们管理内存，内存分配以及回收都不用手动操作，但是如果系统出现内存溢出或者是泄漏，我们如何定位是哪一块内存出现的问题呢。因此，了解虚拟机是如何使用内存，是我们前进的必要一步。

运行时数据区域的划分

在java程序运行过程中，java虚拟机会把它管理的内存划分为几个不同的数据区域，各个数据区域有着各自不同的作用。根据《Java虚拟机规范》的规定，主要包含以下几个数据区域：

关于这几部分数据区域，我相信大家听过最多的就是堆区和栈区了吧。在《Java虚拟机规范》中，栈区分为本地方法栈和虚拟机栈，不过大家平常使用的都是Hotspot虚拟机，在Hotspot虚拟机中本地方法栈和虚拟机栈合二为一，统称为栈区。下面我们就来看看这几个数据区域到底有什么作用。

堆

堆（Java Heap）在虚拟机启动时进行创建，用于存放对象实例，是所有线程共享的内存区域，可以说是最大的内存区域。基本上所有的对象实例以及数组都要在堆上分配，正因为如此，Java堆也是垃圾回收管理的主要区域。针对Java堆，从不同的角度，堆还可以进行细致的划分。由于java基本上采用分代垃圾回收，堆还可以划分为：新生代和老年代；新生代还可以再划分为一个Eden区、两个Survivor区（From Survivor区、To Survivor区）等，方便更好的分配内存和回收内存。

Java堆在实现上，既可以是扩展的，也可以是固定大小。在程序启动时，我们可以通过-Xms与-Xmx进行控制，其中-Xms代表堆的初始大小，-Xmx代表堆的最大值。例如：-Xms1024m -Xmx2048m，代表堆的初始值是1G，当1G不能满足程序使用时，可以扩展到2G。当堆内存不足以满足对象分配时，将会抛出OOM异常。

方法区

线程共享，用于存储已被虚拟机加载的类信息、常量、静态变量、编译后的代码等。在《Java虚拟机规范》中，把方法区解释为堆的一个逻辑部分，但又命名为非堆，应该是为了和堆区别开来。通常我们也习惯把方法区叫做“永久代”，这是因为我们使用HotSpot虚拟机的原因，使用永久代的方式实现方法区，方便Java虚拟机像管理java堆一样管理这部分内存，但是永久代的使用受到-XX:MaxPermSize的上限限制，容易出现内存溢出问题，所以在jdk1.8，java使用元空间代替永久代，在JDK7的HotSpot中，就已经把放在永久代的字符串常量池移出。

方法区中还有一部分重要的内容，那就是运行时常量池，用于存放编译器生成的各种字面量和符号引用。另外，常量池里的常量不一定只有编译期才能产生，运行期间的常量也能进入常量池，例如：String的intern()方法。

当方法区无法满足内存分配时，就会抛出OOM异常。

虚拟机栈

线程私有，生命周期与线程相同，描述的是Java方法执行的内存模型：每个方法在运行时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用到执行完成，都对应着一个栈帧在虚拟机栈中入栈到出栈的过程。通常我们说的“栈”，就是对应的该数据区域。

局部变量表，顾名思义存放的是局部变量，若是基本数据类型，则存放的是基本数据类型的值，若是引用类型则存放的是指向对象的引用。局部变量表的内存空间在编译期间进行分配，所以在方法运行期间局部变量表的大小不会改变。

在虚拟机栈中，规定了两种可能出现的异常：1.当请求栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常。例如：在递归时，没有退出条件。2.当虚拟机栈内存不足，会抛出OOM异常。

本地方法栈

线程私有，该数据区域和虚拟机区域非常的相似，它们之间唯一的区别在于虚拟机栈为java方法服务，本地方法栈为Native修饰的方法服务。该区域也可能出现两种异常：StackOverflowError异常和OOM异常。

程序计数器

线程私有，内存较小，它可以看作是当前线程所执行的字节码的行号指示器。程序运行过程中，就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，例如：分支、循环、跳转、异常处理、线程恢复等。

在多线程运行过程中，为了保证线程在切换后能够恢复到正确的执行位置，每条线程都有一个独立的程序计数器，独立存储，互不影响。

如果线程执行的是一个java方法，这个计数器记录的是正在执行的虚拟机字节码指令地址；如果正在执行的是Native方法，这个计数器的值则为空（Undefined）。此内存区域是唯一一个不会出现OOM异常的数据区域。

内存异常

在编程的生涯中，大家应该或多或少都遇见过内存溢出、内存泄漏异常吧，比如常见的内容有：Java heap space，PermGen space（该异常在jdk1.8之前还存在，1.8之后不存在，因为方法区的实现由永久代方式改为Metaspace元空间方式），unable to create new native thread,StackOverFlowError。

异常本身并不可怕，可怕的是知道出现异常，而不知道如何去解决，导致异常问题一直得不到处理，留下隐患。希望通过本文，大家能够知道如何去寻找异常出现的内存区域，以及如何去解决。

Java heap space

通过名称大家应该就知道了，当出现该异常时，说明堆空间不够用了。出现该异常，表明堆中可达对象太多，并且还在继续创建对象，达到堆的最大内存之后，就会出现该异常。上面我们已经介绍了，通过-Xms 和-Xmx可以决定堆的内存大小，现在我们就简单实现一下：

在这里，我是使用Idea操作的，其它开发工具操作类似。

代码如下：

public class HeapOOM {
    public static void main(String[] args) {
        ArrayList<Object> list = new ArrayList<>();
        while (true){
            list.add(new HeapBean());
        }
    }
}
class HeapBean {
}

我们定义堆的最大值为20m并且不可扩展，-XX:+HeapDumpOnOutOfMemoryError参数会在抛出oom异常时，会Dump出当前的内存快照以供分析。

运行如下：

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid10428.hprof ...
Heap dump file created [28095284 bytes in 0.075 secs]
Disconnected from the target VM, address: '127.0.0.1:61048', transport: 'socket'
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

大家可以发现，抛出OOM异常的同时，生成了java_pid10428.hprof文件，拿到该文件，我们可以通过使用jdk/bin/jvisualvm.exe文件打开，打开步骤：文件->装入->java_pid10428.hprof,之后就会出现一个信息面板，

打开信息面板，我们可以按照这样的顺序查找问题：

1.查看概述面板，在该面板中，我们可以发现出现OOM的线程是哪一个，然后查看下面的线程信息，找到出现OOM的代码位置以及代码细节：

2.若在概述面板中看不出问题所在，我们还可以点击类栏位，其中列表展示的是当前系统类的实例数，以及占据比例、总大小等，按照实例数降序排列。从中我们可以发现HeapBean的实例数占据99%，现在我们就拿到了占据系统堆资源的类。之后我们就可以反查找，查看该类在程序中的使用情况，然后分析代码是否存在问题，继而优化代码。

3.若经过上述分析，没有发现代码存在明显的缺陷，我们还可以分析对象的生命周期是否过长，堆内存大小是否可以适当调大等等。

上述只是一个简单的思路分析，在真实项目中，出现OOM的因素可能错综复杂，就需要大家静下心来，仔细分析，相信一切都难不倒你。

StackOverFlowError

在HotSpot虚拟机中，使用-Xss设置栈大小，上述分析栈的时候，就说过在栈中有一种异常StackOverflowError。当使用栈深度超过虚拟机设定最大栈深度时，将会抛出StackOverflowError异常。大家对这个异常应该非常熟悉吧，当我们在使用递归时，若没有退出条件，让方法无限递归下去，则会导致该异常发生。

示例如下：

/**
 * VM Options:-Xss128k
 */
public class StackError {

    public static void main(String[] args) {
        StackError stackError = new StackError();
        stackError.sum(1);
    }

    public void sum(int i) {
        i++;
        sum(i);
    }
}

上面我们制定栈大小为128k，运行此程序，毫无意外会抛出StackOverflowError，这里我就不展示结果了，比较简单。在写递归函数时，必须要有退出条件。上述我们也说过，在栈内存中，还可能出现OOM异常，这是为什么呢？我们可以这样理解，每个进程的内存是有限的，如果我们定义了堆和方法区的最大容量，除去程序计数器和虚拟机本身消耗掉的内存，那么剩下的内存就是栈的了。假设我们给每个线程分配足够大的栈内存，程序中创建线程的数量就会变小，很容易出现OOM:unable to create new native thread异常。

在实际项目中，抛出StackOverflowError异常，我们可以从堆栈中找到问题，如果是创建过多线程导致的内存溢出，在不能减少线程数量的时候，我们可以减少堆和栈容量来支撑项目运行。

PermGen space

产生该异常，首先我们的第一反映是方法区出现内存溢出。上面已经谈到，方法区主要用于存储Class的相关信息，例如类名、常量池、字段描述、方法描述等。要想在方法区抛出OOM异常，我们可以在运行时产生大量的类去填充方法区。方法区的内存大小，我们可以通过-XX:PermSize和 -XX:MaxPermSize参数指定。

示例如下：

public class MethodSpaceOOM {
    public static void main(String[] args) {
        while (true){
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(MethodSpaceOOM.class);
            enhancer.setUseCache(false);
            enhancer.setCallback((MethodInterceptor) (o, method, objects, methodProxy) -> methodProxy.invokeSuper(o,objects));
            enhancer.create();
        }
    }
}

在这里我们使用CGLib字节码技术，不断的在运行时创建类，在jdk1.8之前，我们运行这段代码会出现PermGen space异常，这是因为生成的类越多，就需要更大的方法区来保证Class可以加载到内存。但是该问题在jdk1.8已经不存在了，这是因为方法区的实现由元空间所代替，永久带的实现方式已经被丢弃。元空间并不在虚拟机中，而是使用本地内存，因此元空间的内存只受本地内存限制，类元数据放到本地内存中，另外，常量池和静态变量放到 Java 堆里。在这种架构下，类元信息就突破了原来 -XX:MaxPermSize 的限制，可以使用更多的本地内存。元空间的内存限制，我们可以通过-XX:MetaspaceSize和 -XX:MaxMetaspaceSize参数来指定，现在，我们修改上述方法的元空间大小-XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m，运行代码，我们可以发现，程序抛出的是java.lang.OutOfMemoryError: Metaspace异常。