本地方法栈内存由操作系统管理，jvm gc无法回收，需手动配对malloc/free；jni中须正确处理引用、线程绑定及内存可见性，directbytebuffer是唯一受gc监管的native内存路径。
本地方法栈不是Java堆，也不归GC管
Java代码调用 JNI 进入C函数后，所有内存分配（比如 malloc、calloc）都在操作系统原生堆上，和 new Object() 完全无关。JVM的GC压根看不见这些内存，更不会回收——哪怕Java对象已经销毁，C侧 malloc 出来的缓冲区还挂着，就是典型的内存泄漏。
常见错误现象：OutOfMemoryError: unable to create native thread 或进程 RSS 持续上涨但 Java 堆稳定；用 valgrind 或 asan 能抓到未释放的 malloc 块，但 JVM 监控工具（如 jstat）完全无反应。
- JNI 函数里必须配对使用
malloc/free、new/delete，不能依赖 Java 对象生命周期 - 避免在
native方法里长期缓存指针或句柄（如全局jobject），除非显式调用NewGlobalRef并配对DeleteGlobalRef - 如果 C 库内部做了内存池或延迟释放，要确认它是否与 JVM 进程生命周期一致——例如嵌入式场景下 JVM 重启频繁，而 C 库静态变量残留会导致脏数据
JNIEnv* 和线程绑定导致的栈/堆混淆
JNIEnv* 不是全局变量，而是每个 OS 线程独有的一块栈空间映射，它里面存的局部引用表（Local Reference Table）默认只在当前 native 方法返回前有效。很多人误以为 jstring 或 jbyteArray 返回后还能直接用 C 指针访问底层数据，其实一出方法就可能失效。
典型错误：在 JNI 函数里调用 GetStringUTFChars 获取 const char*，保存该指针到全局结构体，后续其他线程或回调中直接解引用——结果是随机崩溃或读到垃圾值。
- 要用
GetStringUTFRegion或GetByteArrayElements+Release成对调用，把数据拷贝出来再处理 - 跨线程传递 Java 对象时，必须用
NewGlobalRef提升作用域，且记得在不再需要时DeleteGlobalRef -
JNIEnv*不能缓存复用，不同线程调用AttachCurrentThread得到的JNIEnv*地址不同，也不能在 signal handler 或异步回调里直接用（除非明确 attach）
DirectByteBuffer 是唯一被 JVM “看见”的 native 内存
只有通过 ByteBuffer.allocateDirect() 创建的对象，其背后内存才由 JVM 统一管理（走 Unsafe.allocateMemory），并在 GC 时触发 Cleaner 回调释放。这是 JNI 场景下少有的、能和 GC 协同的 native 内存路径。
但注意：它不解决 C 库自身 malloc 的问题，只是给你一条“受监管”的通道。如果 C 函数想操作这块内存，你得传地址过去（比如 GetDirectBufferAddress），而不是自己再 malloc 一块。
- 不要对
DirectByteBuffer底层地址做free—— JVM 会自己清理，重复 free 导致 double-free crash - 如果 C 库要求固定生命周期（比如初始化时注册一块 buffer 长期使用），建议用
DirectByteBuffer配合PhantomReference+Cleaner做兜底，而非裸 malloc - Android 上
DirectByteBuffer分配可能失败（受限于 ashmem 或 low-memory-killer 策略），需检查返回值是否为NULL
System.loadLibrary 之后的符号解析和内存可见性
System.loadLibrary 加载的是动态库，但符号绑定发生在第一次调用 native 方法时（lazy binding）。如果 C 库内部用了 static 变量或 pthread_once 初始化，多线程首次并发调用可能触发竞态——尤其是初始化逻辑涉及 malloc 或 mmap。
另一个坑是内存屏障缺失：C 函数修改了某块 native 内存，Java 层通过 DirectByteBuffer 读取时，可能因 CPU 缓存不一致看到旧值，尤其在 ARM 或 RISC-V 架构上更明显。
- 确保 C 库初始化函数是线程安全的，必要时加
pthread_mutex_t或用__atomic操作 - 在 Java 层读写
DirectByteBuffer前后，必要时插入Unsafe.storeFence()/Unsafe.loadFence()（JDK9+） - 避免在
static块里直接调用耗时或非幂等的 native 方法，改用双重检查锁或Holder模式延迟初始化
最常被忽略的点：JNI 层的内存模型和 Java 内存模型（JMM）不自动对齐。C 侧写的内存，Java 侧不一定立即可见；Java 侧改的 volatile 字段，C 侧读不到语义保证。这不是 bug，是设计使然——跨语言边界永远要自己加同步、拷贝、或 fence。
13万字C语言保姆级教程（深入）：立即使用
在学习笔记中，你将探索c语言的核心概念和高级技巧！
