在 Java 中为 JOGL 释放直接缓冲区本机内存

Question

我使用直接缓冲区 (java.nio) 来存储 JOGL 的顶点信息。这些缓冲区很大，并且在应用寿命期间会多次更换。内存没有及时释放，经过几次替换后我的内存耗尽了。

似乎没有好的方法可以使用 java.nio 的缓冲区类来解除分配。我的问题是：

JOGL 中是否有某种方法可以删除直接缓冲区？我正在研究 glDeleteBuffer()，但看起来这只会从显卡内存中删除缓冲区。

谢谢

Answer 1

直接 NIO 缓冲区使用非托管内存。这意味着它们分配在本机堆上，而不是 Java 堆上。因此，只有当 JVM 耗尽 Java 堆上的内存（而不是本机堆上的内存）时，才会释放它们。换句话说，它是非托管的 = 由您来管理它们。不鼓励强制垃圾收集，并且大多数情况下并不能解决此问题。

当您知道直接 NIO 缓冲区对您来说变得无用时，您必须使用其 sun.misc.Cleaner （StaxMan 是对的）来释放其本机内存并调用 clean() （Apache Harmony 除外），调用 free() （使用 Apache Harmony）或使用更好的公共 API 来做到这一点（也许在 Java > 12 中，扩展 AutoCloseable 的 AutoCleaning？）。

这不是 JOGL 的工作，您可以使用纯 Java 代码自己完成。 我的示例 遵循 GPL v2 且 此示例采用更宽松的许可证。

编辑： 我的最新的示例甚至可以使用 Java 1.9，并支持 OpenJDK、Oracle Java、Sun Java、Apache Harmony、GNU Classpath 和 Android。您可能需要删除一些语法糖才能使其与 Java 一起使用1.7（多重捕获、钻石和仿制药）。

参考：http://www.ibm.com/developerworks/library/j -nativememory-linux/

Direct ByteBuffer 对象自动清理其本机缓冲区
但只能将其作为 Java 堆 GC 的一部分 — 所以他们不这样做
自动响应本机堆上的压力。仅发生GC
当 Java 堆变得如此满时，它无法为堆分配提供服务
请求或者 Java 应用程序明确请求它（不是
推荐，因为它会导致性能问题）。

参考：http://docs.oracle。 com/javase/7/docs/api/java/nio/ByteBuffer.html#direct

直接缓冲区的内容可能驻留在正常垃圾收集堆之外

此解决方案集成在Java 14：

try (MemorySegment segment = MemorySegment.allocateNative(100)) {
   ...
}

您可以通过调用 MemorySegment.ofByteBuffer(ByteBuffer)，获取其内存地址并释放它（这是一个受限制的方法） Java 16：

CLinker.getInstance().freeMemoryRestricted(MemorySegment.ofByteBuffer(myByteBuffer).address());

请注意，在许多重要情况下，您仍然需要使用反射来找到可以释放的缓冲区，通常是当您的直接 NIO 缓冲区不是 ByteBuffer 时。

注意：sun.misc.Cleaner 已移动到 jdk.internal.ref.Cleaner 位于“java.base”模块中，后者实现了 java.lang. lang.Runnable （感谢 Alan Bateman 提醒我这种差异）很短一段时间，但 现在不再是这样了。你必须调用sun.misc.Unsafe.invokeCleaner()，它是 在 JogAmp 的 Gluegen 中完成。我更喜欢使用 Cleaner 作为 Runnable，因为它避免依赖 sun.misc.Unsafe，但它现在不起作用。

我的最后一个建议适用于 Java 9、10、11 和 12。

我的最新示例 需要使用孵化功能（需要 Java >= 14），但非常非常简单。

注意：自 Java 18 起，不再可能使用内存段来释放预先存在的直接 NIO 缓冲区。相反，请通过调用 MemorySegment.allocateNative() 创建本机内存段，调用 asByteBuffer() 并关闭当您不再需要它时，它的内存会话。它更具侵入性，但这一变化背后可能有出色的 API 设计决策。也许 Java >= 21 中的 MemorySegment.ofBuffer() 有帮助，但我担心它使用了一个您无法安全关闭的全局竞技场。

有 Lucene 中的一个很好的例子，具有更宽松的许可证。

Answer 2

直接缓冲区很棘手，并且没有通常的垃圾收集保证 - 有关更多详细信息，请参阅：http://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html#direct

如果您遇到问题，我建议分配一次并重新使用缓冲区，而不是重复分配和取消分配。

Answer 3

释放的方式很糟糕——软引用基本上被插入到 Cleaner 对象中，然后当拥有的 ByteBuffer 被垃圾收集时，它就会释放。但这并不能真正保证及时调用。

Answer 4

释放直接缓冲区是垃圾收集器在标记 ByteBuffer 对象一段时间后完成的工作。

您可以尝试在删除对缓冲区的最后一个引用后立即调用 gc。至少内存的释放速度有可能更快一些。

Answer 5

使用 gouessej 的回答中的信息，我能够将这个实用程序类放在一起，以释放给定 ByteBuffer 的直接内存分配。当然，这只能作为最后的手段，而不应该真正在生产代码中使用。

在 Java SE 版本 10.0.2 中测试并运行。

public final class BufferUtil {

    //various buffer creation utility functions etc. etc.

    protected static final sun.misc.Unsafe unsafe = AccessController.doPrivileged(new PrivilegedAction<sun.misc.Unsafe>() {
        @Override
        public Unsafe run() {
            try {
                Field f = Unsafe.class.getDeclaredField("theUnsafe");
                f.setAccessible(true);
                return (Unsafe) f.get(null);
            } catch(NoSuchFieldException | SecurityException | IllegalArgumentException | IllegalAccessException ex) {
                throw new RuntimeException(ex);
            }
        }
    });

    /** Frees the specified buffer's direct memory allocation.<br>
     * The buffer should not be used after calling this method; you should
     * instead allow it to be garbage-collected by removing all references of it
     * from your program.
     * 
     * @param directBuffer The direct buffer whose memory allocation will be
     *            freed
     * @return Whether or not the memory allocation was freed */
    public static final boolean freeDirectBufferMemory(ByteBuffer directBuffer) {
        if(!directBuffer.isDirect()) {
            return false;
        }
        try {
            unsafe.invokeCleaner(directBuffer);
            return true;
        } catch(IllegalArgumentException ex) {
            ex.printStackTrace();
            return false;
        }
    }

}

Answer 6

您可以完全在受支持的公共 API 内简单地完成此操作，而不是滥用非公共 api 的反射。

编写一些用 NewDirectByteBuffer 包装 malloc 的 JNI（记住设置顺序），以及一个类似的函数来释放它。