Java堆外内存及调优方式

 更新时间:2026年04月11日 10:07:56   作者:wzz2333  
直接内存并不是Java虚拟机规范中定义的内存区域,但使用广泛,它能显著提高IO性能,避免内存复制,然而,它也需要小心管理,以避免内存泄漏和溢出,通过设置参数和使用NMT特性,可以更好地管理和诊断直接内存

直接内存简介

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

直接内存的分配不受Java堆大小的限制,但是受限于本机总内存大小和处理器寻址空间。一般服务器运维人员会根据实际内存设置-Xmx等参数,但经常忽略直接内存,使得动态扩展时出现 OutOfMemeoryError 异常。

JDK 1.4中加入了NIO类,引入一种基于通道(Channel)与 缓冲区(Buffer)的I/O方式,它可以使用 Native 函数库直接分配堆外内存。这样在一些场景中能显著提高性能,避免在 Java 堆中和 Native 堆中来回复制数据。

为什么DirectByteBuffer可以优化 IO 性能

普通 IO 流读取磁盘中数据时,内核态需要将磁盘中的数据拷贝到系统缓冲区 Page Cache(内核地址空间),再从内核态拷贝到用户空间中,C 程序里操作的就是用户态的内存。

JVM 启动时在用户态申请一块内存,这块内存中包含了 Java 堆,几乎所有创建的对象和数组都分配在堆上,堆上的实例受 GC 管理。除了Java堆,其余内存称为 堆外内存,如果使用JNI直接调用 C 函数申请堆外内存(直接内存),这块堆外内存不会进行垃圾回收(例如:Direct Memory 由 malloc 分配)。

Java 程序中进行文件的读操作:

  1. 首先在内核态,将数据从磁盘中读取到系统缓存区中
  2. 再从系统缓冲区拷贝到用户态的堆外内存(JVM实现)
  3. 然后再从堆外拷贝到 Java 堆内的 byte 数组(用户地址空间)。

读操作示意图如下:

上述传统 Java IO方式,经历了两次内存拷贝,而NIO中使用 DirectByteBuffer,不需要将数据从堆外拷贝到堆内,Java程序可以直接访问堆外的 Direct Memory,减少了一次内存拷贝,也减轻了 GC 压力,降低了Java堆内存占用。

示意图如下:

为什么数据不能直接从系统缓冲区拷贝到 Java 堆

笔者认为原因主要在于 GC 会改变堆内对象的内存地址,例如:Young GC 时Eden 区存活对象会被拷贝到 Survivor 区。而内核态向用户态的数据拷贝是由内核完成的,并不受 Java 程序控制。

因此,需要先拷贝到堆外内存(这个区域不会发生 GC,地址不改变),再从堆外内存拷贝数据到Java堆中。Java 堆内存和堆外内存同属用户地址空间,拷贝可由 Java 虚拟机完成。

Java Direct Buffer用于执行很大数据量的IO密集操作时,存在很大的性能优势。

  • Direct Buffer 是使用malloc进行的堆外分配,生命周期内内存地址都不会再发生更改,进而内核可以安全地对其进行访问,很多 IO 操作会很高效。
  • 减少了堆内对象存储的可能额外维护工作(例如:垃圾回收时位置的移动),所以访问效率可能有所提高。
  • Direct Buffer 的使用能提高网络和文件IO效率,因为省去了从本地堆到Java堆的拷贝,降低 Java 堆的内存占用从而减轻了GC压力。
  • Direct Buffer的创建和销毁比堆内Buffer增加部分开销,通常都建议用于长期使用、数据较大的场景

直接内存的分配

1.通过NIO中的DirectByteBuffer实例引用直接内存

public static void main(String[] args) {
    ByteBuffer buffer = ByteBuffer.allocateDirect(1024);
    // ...
}

allocateDircet 方法返回 DirectByteBuffer 实例:

public static ByteBuffer allocateDirect(int capacity) {
    return new DirectByteBuffer(capacity);
}

2.DirectByteBuffer 类的构造函数中,通过Unsafe#allocateMemory分配直接内存空间,并且创建对应的 Cleaner 实例用于回收直接内存,Cleaner 实例是一个指向 DirectByteBuffer 实例的虚引用。

DirectByteBuffer(int cap) {                   
    super(-1, 0, cap, cap);
    boolean pa = VM.isDirectMemoryPageAligned();
    int ps = Bits.pageSize();
    // 多配分一个内存页, 用于直接内存起始地址对齐
    long size = Math.max(1L, (long)cap + (pa ? ps : 0));
    // 尝试保留size大小的内存, 如果内存不够, 处理pending链表上的引用
    // 内存仍然不足,则显式GC, 将不可达的引用放入pending链表中, 再从pending回收内存
    // 内存不够, 则抛出OOM错误
    Bits.reserveMemory(size, cap);

    long base = 0;
    try {
        // base为直接内存的基址
        base = unsafe.allocateMemory(size);
    } catch (OutOfMemoryError x) {
        Bits.unreserveMemory(size, cap);
        throw x;
    }
    // 将分配到的直接内存每一个Byte设置为0
    unsafe.setMemory(base, size, (byte) 0);
    // 如果需要直接内存对齐, 且基址base不整除pageSize, 则调整起始地址为base+pageSize减去base%pageSize
    if (pa && (base % ps != 0)) {
        // address为ByteBuffer缓冲区可使用部分的起始地址
        address = base + ps - (base & (ps - 1));
    } else {
        address = base;
    }
    // CLeaner 持有 DirectByteBuffer 的幻影(虚)引用
    // Deallocator实现Runnable接口, 执行释放直接内存的操作
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
    att = null;
}

直接内存的回收

Cleaner类继承虚引用 PhantomReference,虚引用的referent字段指向 DirectByteBuffer 实例。

虚引用:最弱的引用关系,一个对象是否有虚引用存在不对其生存时间构成影响,也无法通过虚引用获取对象实例,get 方法返回null。 

为一个对象设置虚引用关联的唯一目的是能在这个对象被收集器回收时收到系统通知。

public class Cleaner extends PhantomReference<Object> {
    ...
    // Cleaner.create: var1传入DirectByteBuffer引用, var2传入Deallocator实例
    private Cleaner(Object var1, Runnable var2) {
        super(var1, dummyQueue);// DirectByteBuffer作为虚引用
        this.thunk = var2; // 
    }
    public static Cleaner create(Object var0, Runnable var1) {
        return var1 == null ? null : add(new Cleaner(var0, var1));
    }
}

DirectByteBuffer 实例不存在强引用后,垃圾回收时它的 PhantomReference 实例会被放入 pending 链表,等待 ReferenceHandler 线程将它从 pending 链表中取出,加入到引用队列queue中。 

ReferenceHandler 线程执行逻辑实现于 tryHandlePending 方法:

从 pending 链表中取出头部的 Reference 实例,如果引用实例为 Cleaner 类型,需要调用它的 clean 方法释放直接内存。随后,将 Reference 实例加入到引用队列 queue 中。

public void run() {
    while (true) {
        tryHandlePending(true);
    }
}

static boolean tryHandlePending(boolean waitForNotify) {
    Reference<Object> r;
    Cleaner c;
    try {
        synchronized (lock) {
            if (pending != null) {
                r = pending;
                // Cleaner继承了虚引用, 需要调用clean方法, 因此特判。
                c = r instanceof Cleaner ? (Cleaner) r : null;
                // pending头节点更新为r的下一个节点
                pending = r.discovered;
                r.discovered = null;
            } else {
                // pending链表中元素为空, wait-notify等待唤醒
                if (waitForNotify) {
                    lock.wait();
                }
                // retry if waited
                return waitForNotify;
            }
        }
    }// ...
    // 如果Reference类型为Cleaner, 需要调用clean方法, 直接内存此时会被回收
    if (c != null) {
        c.clean();
        return true;
    }
    // 将Reference实例加入到引用队列中
    ReferenceQueue<? super Object> q = r.queue;
    // 注册了引用队列, 则入队, 入队后修改r.queue = ReferenceQueue.ENQUEUED, next指向队列中的后继
    if (q != ReferenceQueue.NULL) q.enqueue(r);
    return true;
}

从 pending 链表取出时,会调用 Cleaner#clean方法,clean方法会调用运行 Unsafe#freeMemory 释放直接内存。

// Cleaner
public void clean() {
    if (remove(this)) {
        try {
            this.thunk.run(); // thunk为Deallocator实例
        } // catch
    }
}

// private static class Deallocator implements Runnable
public void run() {
    if (address == 0) {
        // Paranoia
        return;
    }
    // 释放直接内存, address为直接内存基址
    unsafe.freeMemory(address);
    address = 0;
    Bits.unreserveMemory(size, capacity);
}

Direct Buffer 性能优化方面的建议:

  • 应用程序中,System.gc() 触发Full GC,将 DirectByteBuffer 回收时调用 Cleaner#clean 方法释放直接内存。
  • 不要开启 -XX:+DisableExplicitGC 禁用显式GC,默认不禁用;
  • 使用 -XX:+ExplicitGCInvokesConcurrent 改变 Full GC 的行为(配合 CMS 使用)。添加该选项后,垃圾收集线程在可达性标记阶段与用户线程并发运行,减少了STW的时间。

另一种思路是,在大量使用Direct Buffer的部分框架中,框架会自己程序中显式地调用Unsafe#freeMemory方法,例如Netty。(使用反射获取 Unsafe 实例,再调用成员方法 freeMemory)

重复利用 Direct Buffer,减少它的创建和销毁。

直接内存跟踪与诊断

直接内存的容量大小可通过 -XX:MaxDirectMemorySize 参数指定,默认与 Java堆最大值一致。使用反射越过 DirectByteBuffer 类,直接通过反射获取 Unsafe 实例(theUnsafe静态属性),进行内存分配。

Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
theUnsafe.setAccessible(true);
// theUnsafe为static final字段
Unsafe unsafe = (Unsafe) theUnsafe.get(null);
// 分配直接内存
long address = unsafe.allocateMemory(1024);
unsafe.freeMemory(address);

由直接内存导致的内存溢出,在Heap Dump文件中不会看见明显的异常情况。

如果发现内存溢出后,产生的Dump文件很小,而程序中直接或间接使用了Direct Memory(NIO),就可以考虑检查直接内存溢出。

通常的垃圾收集日志等记录,并不包含 Direct Buffer 等信息。从JDK 1.8开始,可以使用 Native Memory Tracking(NMT) 特性来进行诊断,可以在程序启动时加上下面参数:

-XX:NativeMemoryTracking={summary|detail}

运行时,采用如下命令交互式对比:

// 打印NMT信息
jcmd <pid> VM.native_memory detail

// 进行baseline,以对比分配内存变化
jcmd <pid> VM.native_memory baseline

// 对比baseline, 显示出各个部分内存的变化
jcmd <pid> VM.native_memory detail.diff

下面案例中,先使用 VM.native_memory 的 baseline 命令,作为对比的参照;当打印出 Begin allocate 后,执行detail.diff,进行对比。

public class DirectMemory {
    public static void main(String[] args) {
        try {
            Thread.sleep(40000);// 进行baseline, 作为比对的参照
            System.out.println("Begin allocate: ...");
            ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024 * 3);    
            Thread.sleep(40000);    
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

结果如下图所示,Internal部分的内存增加了3078KB,3MB = 3072KB

总结

以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。

相关文章

  • springcloud项目占用内存好几个G导致服务器崩溃的问题

    springcloud项目占用内存好几个G导致服务器崩溃的问题

    这篇文章主要介绍了springcloud项目占用内存好几个G导致服务器崩溃的问题,本文给大家分享解决方案供大家参考,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
    2020-10-10
  • Java Semaphore信号量使用分析讲解

    Java Semaphore信号量使用分析讲解

    Semaphore实际上是一种共享锁,因为它允许多个线程并发获取共享的资源,在Semaphore对象创建时必须设置可用令牌的初始数量permits,用于控制并发时同时获取资源权限的线程数量,这篇文章主要介绍了Java中的Semaphore如何使用,需要的朋友可以参考下
    2022-12-12
  • Maven deploy配置方法详解

    Maven deploy配置方法详解

    这篇文章主要介绍了Maven deploy配置方法详解,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2020-07-07
  • eclipse实现Schnorr数字签名

    eclipse实现Schnorr数字签名

    这篇文章主要为大家详细介绍了eclipse实现Schnorr数字签名,文中示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2020-06-06
  • SpringCloud Eureka实现服务注册与发现

    SpringCloud Eureka实现服务注册与发现

    Eureka是一种基于REST(具像状态传输)的服务,主要用于AWS云中定位服务,以实现中间层服务器的负载平衡和故障转移。本文记录一个简单的服务注册与发现实例。感兴趣的小伙伴们可以参考一下
    2019-01-01
  • SpringBoot+Shiro学习之密码加密和登录失败次数限制示例

    SpringBoot+Shiro学习之密码加密和登录失败次数限制示例

    本篇文章主要介绍了SpringBoot+Shiro学习之密码加密和登录失败次数限制示例,可以限制登陆次数,有兴趣的同学可以了解一下。
    2017-03-03
  • gateway网关与前端请求跨域问题的解决方案

    gateway网关与前端请求跨域问题的解决方案

    这篇文章主要介绍了gateway网关与前端请求跨域问题的解决方案,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2021-07-07
  • Java BeanUtils 类作用、语法与示例详解

    Java BeanUtils 类作用、语法与示例详解

    BeanUtils是Apache Commons和Spring Framework提供的工具类,主要用于简化JavaBean的操作,接下来通过本文给大家介绍Java BeanUtils 类作用、语法与示例详解,感兴趣的朋友跟随小编一起看看吧
    2025-08-08
  • 告别无尽等待:Java中的轮询终止技巧

    告别无尽等待:Java中的轮询终止技巧

    在Java中,轮询是一种常见的处理方式,用于检查某个条件是否满足,直到满足条件或达到一定的时间限制,本文将介绍Java中常用的轮询结束方式,包括使用循环、定时器和线程池等方法,需要的朋友可以参考下
    2023-10-10
  • Java(SpringBoot)项目打包(构建)成Docker镜像的几种常见方式

    Java(SpringBoot)项目打包(构建)成Docker镜像的几种常见方式

    在对Spring Boot应用程序进行Docker化时,为应用程序选择正确的基础镜像非常重要,下面这篇文章主要给大家介绍了关于Java(SpringBoot)项目打包(构建)成Docker镜像的几种常见方式,需要的朋友可以参考下
    2023-12-12

最新评论