11

首先让我说我对 JNA 和 Java 如何直接分配本机内存的理解充其量是发自内心的,所以我试图描述我对正在发生的事情的理解。除了响应之外的任何更正都会很棒......

我正在运行一个使用 JNA 混合 Java 和 C 本机代码的应用程序,并且正在运行 Java 垃圾收集器无法释放对直接本机内存分配的引用,从而导致 C 堆内存不足的可重现问题。

我很肯定我的 C 应用程序不是分配问题的根源,因为我将 a 传递java.nio.ByteBuffer到我的 C 代码中,修改缓冲区,然后在我的 Java 函数中访问结果。我在每个函数调用期间都有一个malloc和一个对应free的,但是在 Java 中反复运行代码后,malloc 最终会失败。

这是一组显示该问题的有点琐碎的代码——实际上,我试图在函数调用期间在 C 堆上分配大约 16-32MB

我的 Java 代码执行以下操作:

public class MyClass{
    public void myfunction(){
        ByteBuffer foo = ByteBuffer.allocateDirect(1000000);
        MyDirectAccessLib.someOp(foo, 1000000);
        System.out.println(foo.get(0));
    }
}

public MyDirectAccessLib{
    static {
        Native.register("libsomelibrary");
    }
    public static native void someOp(ByteBuffer buf, int size);
}

那么我的 C 代码可能是这样的:

#include <stdio.h>
#include <stdlib.h>
void someOp(unsigned char* buf, int size){
    unsigned char *foo;
    foo = malloc(1000000);
    if(!foo){
        fprintf(stderr, "Failed to malloc 1000000 bytes of memory\n");
        return;
    }
    free(foo);

    buf[0] = 100;
}

问题是在反复调用这个函数后,Java 堆有点稳定(增长缓慢),但 C 函数最终无法分配更多内存。在高层次上,我认为这是因为 Java 正在为 C 堆分配内存,但没有清理指向该内存的 ByteBuffer,因为 Java ByteBuffer 对象相对较小。

到目前为止,我发现在我的函数中手动运行 GC 将提供所需的清理,但这似乎既是一个糟糕的主意,也是一个糟糕的解决方案。

我怎样才能更好地管理这个问题,以便适当地释放 ByteBuffer 空间并控制我的 C 堆空间?

我对问题的理解是否不正确(我是否运行不正确)?

编辑:调整缓冲区大小以更能反映我的实际应用程序,我正在分配大约 3000x2000 的图像...

4

5 回答 5

9

您实际上正面临Java VM 中的一个已知错误。错误报告中列出的最佳解决方法是:

  • “-XX:MaxDirectMemorySize= 选项可用于限制使用的直接内存量。尝试分配直接内存会导致超出此限制会导致完整的 GC,从而引发引用处理和未引用缓冲区的释放。 "

其他可能的解决方法包括:

  • 偶尔插入显式 System.gc() 调用以确保回收直接缓冲区。
  • 减少年轻代的大小以强制更频繁的 GC。
  • 在应用程序级别显式池化直接缓冲区。

如果您真的想依赖直接字节缓冲区,那么我建议在应用程序级别进行池化。根据应用程序的复杂性,您甚至可以简单地缓存和重用相同的缓冲区(注意多个线程)。

于 2009-11-21T13:50:49.737 回答
4

我认为您已经正确诊断:您永远不会用完 Java 堆,因此 JVM 不会进行垃圾收集,也不会释放映射的缓冲区。手动运行 GC 时没有问题的事实似乎证实了这一点。您还可以打开详细收集日志记录作为辅助确认。

所以,你可以做什么?嗯,我要尝试的第一件事是使用 -Xms 命令行参数来保持初始 JVM 堆大小较小。如果您的程序不断在 Java 堆上分配少量内存,这可能会导致问题,因为它会更频繁地运行 GC。

我还将使用pmap工具(或 Windows 上的任何等效工具)来检查虚拟内存映射。通过分配可变大小的缓冲区,您可能正在对 C 堆进行分段。如果是这样的话,那么你会看到一个更大的虚拟地图,“anon”块之间有间隙。解决方案是分配比您需要的更大的固定大小的块。

于 2009-11-16T20:21:52.673 回答
1

我怀疑您的问题是由于使用了直接字节缓冲区。它们可以分配在 Java 堆之外。

如果您经常调用该方法,并且每次都分配小缓冲区,那么您的使用模式可能不适合直接缓冲区。

为了隔离问题,我将切换到(Java)堆分配的缓冲区(只需使用该allocate方法代替allocateDirect。如果这使您的内存问题消失了,那么您就找到了罪魁祸首。下一个问题是直接字节缓冲区在性能方面是否有任何优势。如果没有(我猜它没有),那么您无需担心如何正确清理它。

于 2009-11-16T20:19:05.987 回答
1

如果堆内存用完,会自动触发 GC。但是,如果直接内存用完,则不会触发 GC(至少在 Sun 的 JVM 上),即使 GC 会释放足够的内存,您也会收到 OutOfMemoryError。我发现在这种情况下你必须手动触发 GC。

更好的解决方案可能是重用相同的 ByteBuffer,这样您就不需要重新分配 ByteBuffer。

于 2009-11-21T14:38:42.963 回答
1

要释放 directBuffer[ 1 ]内存,您可以使用JNI

JNI 6 API中的函数GetDirectBufferAddress(JNIEnv* env, jobject buf)[ 3 ]可用于获取指向内存的指针,然后对指针执行标准命令以释放内存。Bufferfree(void *ptr)

您可以使用JNA[ 6 ],而不是编写诸如 C 之类的代码来从 Java 调用所述函数Native.getDirectBufferPointer(Buffer)

之后唯一剩下的就是放弃对该Buffer对象的所有引用。然后,Java 的垃圾收集将释放该Buffer实例,就像它处理任何其他非引用对象一样。

请注意,直接Buffer不一定将 1:1 映射到分配的内存区域。例如 JNI API 有NewDirectByteBuffer(JNIEnv* env, void* address, jlong capacity)[ 7 ]。因此,您应该只释放Buffer's 的内存,您知道其内存分配区域与本机内存是一对一的。

我也不知道您是否可以出于与上述完全相同的原因释放Buffer由 Java ByteBuffer.allocateDirect(int)[ 8 ]创建的直接。在分发新的 direct 时,它们是否使用池或进行 1:1 的内存分配可能是 JVM 或 Java 平台实现的具体细节Buffer

下面是我的库中关于直接ByteBuffer[ 9 ]处理的稍微修改的片段(使用 JNA Native[ 10 ]Pointer[ 11 ]类):

/**
 * Allocate native memory and associate direct {@link ByteBuffer} with it.
 * 
 * @param bytes - How many bytes of memory to allocate for the buffer
 * @return The created {@link ByteBuffer}.
 */
public static ByteBuffer allocateByteBuffer(int bytes) {
        long lPtr = Native.malloc(bytes);
        if (lPtr == 0) throw new Error(
            "Failed to allocate direct byte buffer memory");
        return Native.getDirectByteBuffer(lPtr, bytes);
}

/**
 * Free native memory inside {@link Buffer}.
 * <p>
 * Use only buffers whose memory region you know to match one to one
 * with that of the underlying allocated memory region.
 * 
 * @param buffer - Buffer whose native memory is to be freed.
 * The class instance will remain. Don't use it anymore.
 */
public static void freeNativeBufferMemory(Buffer buffer) {
        buffer.clear();
        Pointer javaPointer = Native.getDirectBufferPointer(buffer);
        long lPtr = Pointer.nativeValue(javaPointer);
        Native.free(lPtr);
}
于 2012-07-03T22:00:17.403 回答