一文搞懂堆外内存（模拟内存泄漏） |
您所在的位置：网站首页 › 手动设置内存超频有什么用 › 一文搞懂堆外内存（模拟内存泄漏） |
一文搞懂堆外内存（模拟内存泄漏）
|
一、前言
平时编程时，在 Java 中创建对象，实际上是在堆上划分了一块区域，这个区域叫堆内内存。 使用这 -Xms -Xmx 来指定新生代和老年代空间大小的初始值和最大值，这初始值和最大值也被称为 Java 堆的大小，即 堆内内存大小。 这个堆内内存完全受 JVM 管理，JVM 有垃圾回收机制，所以我们一般不必关系对象的内存如何回收。剖开 JVM 内存模型，来看下其堆划分： 由图可知 Java8 使用元空间替代永久代且元空间放在堆外内存上，这是为啥？ 类的元数据信息常用到，在 GC 时回收效率偏低。 类的元数据信息比较难以确定其大小，指定太小容易出现永久代溢出、指定太大则容易造成老年代溢出。那什么是堆外内存？ 堆外内存与堆内内存相对应，对于整个机器内存而言，除堆内内存以外部分即为堆外内存。 Java 程序一般使用 -XX:MaxDirectMemorySize 来限制最大堆外内存。 还有个问题：堆外内存属于用户空间还是内核空间？ 用户空间。 （1）为什么需要堆外内存？使用堆外内存，有这些好处： 直接使用堆外内存可以减少一次内存拷贝： 当进行网络 I/O 操作、文件读写时，堆内内存都需要转换为堆外内存，然后再与底层设备进行交互。 降低 JVM GC 对应用程序影响：因为堆外内存不受 JVM 管理。 堆外内存可以实现进程之间、JVM 多实例之间的数据共享。那我就有个问题：为什么使用堆外内存可以减少一次内存拷贝呢？ 原因：当进行网络 I/O操作或文件读写时，如果使用堆内内存（HeapByteBuffer），JDK 会先创建一个堆外内存（DirectBuffer），再去执行真正的读写操作。 具体原因是：调用底层系统函数（write、read等），必须要求使用是连续的地址空间。 操作系统并不感知 JVM 的堆内存，而且 JVM 的内存布局与操作系统所分配的是不一样的，操作系统并不会按照 JVM 的行为来读写数据。 同一个对象的内存地址随着 JVM GC 的执行可能会随时发生变化，例如 JVM GC 的过程中会通过压缩来减少内存碎片，这就涉及对象移动的问题了。当然使用堆外内存，有这些弊端： 排查内存泄漏问题相对困难： 因为堆外内存需要手动释放，不熟悉对应框架源码，可能稍有不慎就会造成应用程序内存泄漏。 对开发人员的基础技能要求高。由此可以看出，如果想实现高效的 I/O 操作、缓存常用的对象、降低 JVM GC 压力，堆外内存是一个非常不错的选择。 （2）如何分配堆外内存？Java 中堆外内存的分配方式有两种： NIO类中的ByteBuffer#allocateDirect Unsafe#allocateMemory 首先来看下 Java NIO 包中的 ByteBuffer 类的分配方式，使用方式如下： // 分配 10M 堆外内存 ByteBuffer byteBuffer = ByteBuffer.allocateDirect(10 * 1024 * 1024); // 释放堆外内存 ((DirectBuffer) byteBuffer).cleaner().clean();跟进 ByteBuffer.allocateDirect 源码，发现其中直接调用的 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)); Bits.reserveMemory(size, cap); // 注意这里会调用 System.gc(); long base = 0; try { // 1. 真正分配堆外内存 base = unsafe.allocateMemory(size); } catch (OutOfMemoryError x) { Bits.unreserveMemory(size, cap); throw x; } unsafe.setMemory(base, size, (byte) 0); if (pa && (base % ps != 0)) { // Round up to page boundary address = base + ps - (base & (ps - 1)); } else { address = base; } // 2. 用于回收堆外内存 cleaner = Cleaner.create(this, new Deallocator(base, size, cap)); att = null; }DirectByteBuffer 对象： 存放在堆内存里，仅仅包含堆外内存的地址、大小等属性。同时还会创建对应的 Cleaner 对象，通过 ByteBuffer 分配的堆外内存不需要手动回收，它可以被 JVM 自动回收。 当堆内的 DirectByteBuffer 对象被 GC 回收时，Cleaner 就会用于回收对应的堆外内存。 真正分配堆外内存的逻辑还是通过 unsafe.allocateMemory(size) Unsafe 是一个非常不安全的类，它用于执行内存访问、分配、修改等敏感操作，可以越过 JVM 限制的枷锁。Unsafe 最初并不是为开发者设计的，使用它时虽然可以获取对底层资源的控制权，但也失去了安全性的保证，所以使用 Unsafe 一定要慎重。 在 Java 中是不能直接使用 Unsafe 的，但是可以通过反射获取 Unsafe 实例，使用方式如下所示： private static Unsafe unsafe = null; static { try { Field getUnsafe = Unsafe.class.getDeclaredField("theUnsafe"); getUnsafe.setAccessible(true); unsafe = (Unsafe) getUnsafe.get(null); } catch (NoSuchFieldException | IllegalAccessException e) { e.printStackTrace(); } }获得 Unsafe 实例后，可以通过 allocateMemory 方法分配堆外内存，allocateMemory 方法返回的是内存地址，使用方法如下所示： // 分配 10M 堆外内存 long address = unsafe.allocateMemory(10 * 1024 * 1024); // Unsafe#allocateMemory 所分配的内存必须自己手动释放，否则会造成内存泄漏 // 这也是 Unsafe 不安全的体现。 unsafe.freeMemory(address); （3）如何回收堆外内存？堆外内存回收，有两种方式： Full GC 时以及调用 System.gc()： 通过 JVM 参数 -XX:MaxDirectMemorySize 指定堆外内存的上限大小，当堆外内存的大小超过该阈值时，就会触发一次 Full GC 进行清理回收，如果在 Full GC 之后还是无法满足堆外内存的分配，那么程序将会抛出 OOM 异常。 使用unsafe.freeMemory(address); 来回收： DirectByteBuffer 在初始化时会创建一个 Cleaner 对象，Cleaner 内同时会创建 Deallocator，调用 Deallocator#run() 来回收。 1）System.gc() 触发那就有个问题，什么时候会触发 System.gc() ？ ByteBuffer.allocateDirect 分配的过程中： 如果没有足够的空间分配堆外内存，在 Bits.reserveMemory 方法中也会主动调用 System.gc() ，就会触发 Full GC（并不是马上执行）。 // ByteBuffer.allocateDirect 直接调用 DirectByteBuffer 构造函数 DirectByteBuffer(int cap) { ... Bits.reserveMemory(size, cap); // 注意这里会调用 System.gc(); ... }Tips: 如果环境中设置了 -XX:+DisableExplicitGC，System.gc() 会不起作用的。 所以依赖 System.gc() 并不是一个好办法。 2）Cleaner 对象通过前面堆外内存分配方式的介绍，我们知道 DirectByteBuffer 在初始化时会创建一个 Cleaner 对象，它会负责堆外内存的回收工作，那么 Cleaner 是如何与 GC 关联起来的呢？ 先来看下 Cleaner 的源码： public class Cleaner extends java.lang.ref.PhantomReference { private static final ReferenceQueue dummyQueue = new ReferenceQueue(); // 双向链表 private static sun.misc.Cleaner first; private sun.misc.Cleaner next; private sun.misc.Cleaner prev; private final java.lang.Runnable thunk; public void clean() { if (!remove(this)) // 把自己从链表上移除 return; try { thunk.run(); // thunk 是 Deallocator } catch (final Throwable x) { // ... ... } } }可以看到 Cleaner 属于 PhantomReference 的子类，那 Cleaner#clean() 执行是否跟 JVM GC 或Reference 有关呢？ Tips：Java 对象有四种引用方式， 强引用 StrongReference、软引用 SoftReference、弱引用 WeakReference、虚引用 PhantomReference。 这里先了解下 Reference 核心处理流程： JVM 垃圾收集器扫描到对象 O 可回收。 把对象 O 对应的 Reference 实例 R 添加到 PendingReference 链表中。 通知 ReferenceHandler 线程处理，最后完成清理逻辑。 下面是其源码： // Reference.java， 部分代码省略 public abstract class Reference { static { Thread handler = new ReferenceHandler(tg, "Reference Handler"); handler.setPriority(Thread.MAX_PRIORITY); handler.setDaemon(true); handler.start(); } private static class ReferenceHandler extends Thread { public void run() { while (true) { tryHandlePending(true); } } } static boolean tryHandlePending(boolean waitForNotify) { Reference r; Cleaner c; try { synchronized (lock) { if (pending != null) { r = pending; // 判断是否为 Cleaner c = r instanceof Cleaner ? (Cleaner) r : null; // unlink 'r' from 'pending' chain pending = r.discovered; r.discovered = null; } else { // ... ... } } } catch (OutOfMemoryError x) { // 等待CG后的通知 // ... ... } catch (InterruptedException x) { // ... ... } // 是为 Cleaner， 则调用 Cleaner.clean() 方法 if (c != null) { c.clean(); return true; } ReferenceQueue |
【本文地址】
今日新闻 |
推荐新闻 |