垃圾收集和JNI调用

Question

我遇到了一个JNI程序随机内存不足的问题。

这是一个32位java程序，它读取文件，进行一些图像处理，通常使用250MB到1GB。然后丢弃所有这些对象，然后程序对通常需要100-250MB的JNI程序进行一系列调用。

当交互运行时，我从未见过问题。但是，当对许多文件连续运行批处理操作时，JNI程序将随机运行内存溢出。它可能对一个或两个文件有内存问题，然后对下一个10个文件运行正常，然后再次出现故障。

在JNI调用之前，我已经转储了大量的可用内存，这些内存到处都是，有时是100MB，有时是800MB。我的解释是，Java垃圾收集有时在图像处理之后立即运行，有时不运行。如果不是，那么JNI程序可能没有足够的内存。

我已经阅读了所有关于GC是非确定性的、不应该调用它、不会产生任何影响等等的内容。但是在开始JNI调用之前强制GC似乎可以改善这种情况。

但是有没有办法真正确保在继续之前有一定量的空闲内存呢？

为了回答关于另一家公司提供的JNI程序的问题，我对它如何分配内存没有真正的了解。我只知道它是用c语言编写的，它没有垃圾收集功能。有人告诉我它需要100-250MB的内存，我看到的数字可以证实这一点。

也许我应该把这个问题改写为：如果我要进行一个JNI调用，我知道它需要250MB的内存，我如何保证它会有那么多的可用存储器？

当然，一个可能的解决方案是进行64位构建。然而，这个批处理操作是32位构建的QA的一部分，所以我想测试真实的东西。

Answer 1

FWIW（我意识到这是一种异端邪说）增加了对

System.gc();

在对每个文件进行第一次JNI调用之前，对这种情况进行了重大改进。20%的文件没有出现内存错误，现在的内存错误率不到5%。更好的是，这些错误不再是随机的，而是可以从一次运行到另一次运行重复出现，因此可以推测它们可以被跟踪。

Answer 2

以下假设您正在使用hotspot jvm。

32位进程不仅受提交内存的约束，更重要的是，它们受虚拟内存（即保留地址空间）的约束。在64位系统上只能使用4GB的地址，而在32位系统上只能使用2-3GB的地址。

JVM将预先为托管堆保留一个固定的、可能很大的地址空间，然后在该空间的基础上动态分配一些内部结构，然后可能为DirectByteBuffers或内存映射文件分配更多的地址空间。这会给本机代码留下很少的运行空间。

使用本机内存跟踪来确定JVM的各个部分使用了多少和pmap

或者，您可以生成一个新进程并在那里进行图像处理。

Answer 3

我自己解决这个问题的方法就是调用系统。gc（），但从本机代码内部：

#include <jni.h>
// ...
int my_native_function(JNIEnv* env, jobject obj) {
    jclass    systemClass    = nullptr;
    jmethodID systemGCMethod = nullptr;
    // ...
    // Take out the trash.
    systemClass    = env->FindClass("java/lang/System");
    systemGCMethod = env->GetStaticMethodID(systemClass, "gc", "()V");
    env->CallStaticVoidMethod(systemClass, systemGCMethod);
}

我希望这对你也有用。