java对象本身由gc自动回收，但其关联的jni本地内存（如c/c++中malloc分配的内存）不受jvm管理，必须由开发者显式释放；否则将导致内存泄漏。关键在于区分java堆对象生命周期与本地资源生命周期。
java对象本身由gc自动回收，但其关联的jni本地内存（如c/c++中malloc分配的内存）不受jvm管理，必须由开发者显式释放；否则将导致内存泄漏。关键在于区分java堆对象生命周期与本地资源生命周期。
在JNI编程中，一个常见误区是认为只要Java对象（如JniUser）被垃圾回收器回收，其背后由本地代码分配的内存也会自动释放。事实并非如此：JVM仅负责管理Java堆上的对象（如String、int字段封装等），而通过JNI在本地（C/C++）侧分配的内存（例如malloc、new、或OpenCV中的图像缓冲区）完全脱离JVM的GC控制范围。
以OpenCV的Mat类为例：其Java端Mat对象仅是一个轻量级包装器，真正的大块图像数据存储在本地内存中。当该Mat对象超出作用域并被GC回收时，Java层引用消失，但本地内存不会自动释放——必须显式调用mat.release()才能触发本地资源清理。若遗漏此步骤，即产生内存泄漏；若重复调用或释放后继续使用，则引发use-after-free等严重错误。
因此，正确的资源管理实践应遵循“谁分配、谁释放”原则，并在Java层提供明确的资源释放接口：
public class JniUser {
private long nativeHandle; // 持有本地对象指针（如void*）
private String name;
private int age;
public native int getAge();
public native String getName();
// 显式释放本地资源的方法（推荐命名为 close() 或 dispose()）
public native void dispose();
// 推荐：实现 AutoCloseable，支持 try-with-resources
@Override
public void close() {
if (nativeHandle != 0) {
dispose(); // 调用JNI方法释放本地内存
nativeHandle = 0;
}
}
}
在本地代码（C/C++）中，对应实现需安全处理空指针和重复释放：
JNIEXPORT void JNICALL Java_JniUser_dispose(JNIEnv *env, jobject obj) {
jlong handle = (*env)->GetLongField(env, obj, g_nativeHandleFieldID);
if (handle != 0) {
MyNativeObject* ptr = (MyNativeObject*)handle;
free(ptr); // 或 delete ptr; 根据分配方式决定
(*env)->SetLongField(env, obj, g_nativeHandleFieldID, 0);
}
}
⚠️ 注意事项：
-
禁止依赖
finalize()：该方法不保证及时执行，且自Java 9起已被弃用，不可用于关键资源释放； -
优先使用
AutoCloseable + try-with-resources：确保异常场景下资源仍能释放； -
避免在
getName()等getter中隐式分配/泄露本地内存：若返回jstring，应使用NewStringUTF并确保其生命周期由JVM管理（无需手动释放）；但若返回的是需长期持有的本地结构体指针，则必须配套释放逻辑； - 记录资源归属：在设计JNI接口时，清晰定义每块本地内存的生命周期归属方（Java层 or native层），并在文档中标明调用约束。
总结：JNI不是内存管理的“黑盒”，而是责任边界的显式划分。Java程序员不仅需要理解GC机制，更需主动承担本地资源的生命周期管理职责——这是编写健壮、可维护JNI代码的核心前提。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
