使用Invocation API进行JNI内存管理

当我使用JNI方法构建java对象时,为了将其作为参数传递给我正在使用JNI调用API调用的java方法,我该如何管理它的内存？

这是我正在使用的:

我有一个C对象,它有一个更复杂的析构函数方法free().这个C对象与Java对象相关联,一旦应用程序完成Java对象,我就不再需要C对象了.

我正在创建这样的Java对象(为了清楚起见,错误检查已被省略):

c_object = c_object_create ();
class = (*env)->FindClass (env, "my.class.name");
constructor = (*env)->GetMethodID (env, class, "", "(J)V");
instance = (*env)->NewObject (env, class, constructor, (jlong) c_object);

method = (*env)->GetMethodID (env, other_class, "doSomeWork", "(Lmy.class.name)V");
(*env)->CallVoidMethod (env, other_class, method, instance);

那么,既然我已经完成了instance,我该怎么办呢？理想情况下,我想将垃圾收集器留给VM; 当它完成时instance它会很棒,如果它也调用c_object_destroy()我提供给它的指针.这可能吗？

一个单独但相关的问题与我在这样的方法中创建的Java实体的范围有关; 我必须手动释放,也就是说,class,constructor,或method以上？关于适当的内存管理问题,JNI文档令我感到沮丧(在我看来).

JNI的规范涵盖的谁"拥有"的JNI方法创建Java对象的问题在这里.您需要区分本地和全局引用.

当JVM对本机代码进行JNI调用时,它会设置一个注册表来跟踪调用期间创建的所有对象.在本机调用期间创建的任何对象(即从JNI接口函数返回)都会添加到此注册表中.对这些对象的引用称为本地引用.当本机方法返回到JVM时,将破坏在本机方法调用期间创建的所有本地引用.如果在本机方法调用期间调用JVM,则当控制返回本机方法时,本地引用仍将处于活动状态.如果从本机代码调用的JVM再次调用本机代码,则会创建一个新的本地引用注册表,并应用相同的规则.

(实际上,您可以使用JNI接口实现自己的JVM可执行文件(即java.exe),创建JVM(从而接收JNIEnv*指针),查找命令行中给出的类,并调用main()方法就可以了.)

从JNI接口方法返回的所有引用都是本地的.这意味着在正常情况下,您不需要手动释放JNI方法返回的引用,因为它们在返回JVM时会被销毁.有时您仍然希望"过早地"销毁它们,例如,当您在返回JVM之前要删除许多本地引用时.

使用NewGlobalRef()创建全局引用(从本地引用).它们被添加到特殊注册表中,必须手动释放.全局引用仅用于Java对象,本机代码需要跨多个JNI调用来引用该对象,例如,如果您有本机代码触发应该传播回Java的事件.在这种情况下,JNI代码需要存储对要接收事件的Java对象的引用.

希望这能澄清一下内存管理问题.

回收本机资源(对象,文件描述符等)有两种策略

在finalize()期间调用JNI方法释放资源.有些人建议不要实现finalize,基本上你不能确定你的本机资源是否被释放.对于内存等资源,这可能不是问题,但如果你有一个文件,例如需要在可预测的时间刷新,则finalize()可能不是一个好主意.

手动调用清理方法.如果您有一个知道必须清理资源的时间点,这将非常有用.当我在JNI代码中卸载DLL之前有一个必须被释放的资源时,我使用了这个方法.为了以后允许重新加载DLL,我必须确保在尝试卸载DLL之前该对象确实已被释放.只使用finalize(),我不会得到这个保证.这可以与(1)组合以允许在finalize()期间或在手动调用的清理方法中分配资源.(您可能需要WeakReferences的规范映射来跟踪哪些对象需要调用其清理方法.)

据说PhantomReference也可用于解决这个问题,但我不确定这样的解决方案究竟是如何工作的.

实际上,我不得不在JNI文档上与你意见不一致.我发现JNI规范在大多数重要问题上都格外清晰,即使有关管理本地和全局参考的部分可以更加详细.