本地方法栈不负责内存分配与回收，仅提供native方法执行的栈空间；native内存由malloc/free等操作系统级操作管理，jvm不可见且不参与gc，泄漏需手动释放。
本地方法栈本身不负责内存分配与回收，它只是为 Native 方法执行提供栈空间。真正涉及内存分配与回收的，是 Native 方法内部调用的操作系统级逻辑，比如 malloc/free、mmap/munmap，或 JVM 封装的 Unsafe.allocateMemory/freeMemory。JVM 层面对这部分内存“不可见”，也不参与 GC 管理。
本地方法栈只管执行，不管内存
本地方法栈是线程私有的运行时区域，作用是支持 native 方法（如用 C/C++ 编写的 JNI 方法）的调用。它保存的是 native 方法的局部变量、参数、返回地址等栈帧信息，和 Java 方法在虚拟机栈中的行为类似。但栈本身不分配堆外数据内存——它只是“运行现场”，不是“内存仓库”。
- 栈空间由 JVM 在线程创建时划出，大小可通过
-Xss控制，溢出抛StackOverflowError或OutOfMemoryError - Native 方法里申请的内存（如
malloc(1024)）属于操作系统本地堆，JVM 不感知、不跟踪、不回收 - 如果 Native 方法泄漏了 malloc 的内存，JVM GC 完全无能为力，只能靠开发者手动
free
Native 方法中常见内存分配方式
Java 侧触发的直接内存（如 ByteBuffer.allocateDirect）虽常被误认为“本地方法栈分配”，实则由 JVM 底层调用 Unsafe 完成，且配套 Cleaner 机制实现自动回收；而纯 JNI/native 方法里的内存，完全由开发者控制：
-
JNI 层 malloc/free：C 代码中用
malloc分配，必须配对free，否则直接内存泄漏 -
Unsafe.allocateMemory：Java 层调用，返回 long 地址，需显式调用
freeMemory（否则无 Cleaner 绑定，不会自动回收） - mmap/munmap：用于大块内存或文件映射，同样需成对调用，JVM 不介入生命周期管理
为什么没有 GC 参与？
因为 JVM 的垃圾收集器只管理 Java 堆（Heap）和元空间（Metaspace）中的对象，所有 Native 层分配的内存都位于 JVM 进程的本地地址空间，绕过 Java 对象模型：
- GC 根集合（GC Roots）不含 Native 指针，无法识别 native 分配的内存是否还被引用
- 本地方法栈帧销毁，只释放栈空间本身，不影响其内部 malloc 出来的堆内存
- 即使 native 方法返回，只要指针被上层 C/C++ 代码保留（比如存入全局变量），那块内存就一直存活
排查与避坑建议
Native 内存泄漏难定位，但可通过工具链辅助发现：
- 用
jcmd <pid> VM.native_memory summary</pid>查看 JVM 进程整体 native 内存使用趋势 - Linux 下结合
pstack+cat /proc/<pid>/maps</pid>观察异常增长的大块匿名内存段 - JNI 代码务必遵循 RAII 原则：在
try-finally或DeleteLocalRef后立即释放资源 - 避免在 native 方法中长期持有 Java 对象全局引用（GlobalRef），防止 Java 对象无法被 GC
