这类问题本质是JNI层资源管理失控导致的宿主机崩溃，核心是裸指针生命周期失控、跨模块共享资源时释放缺失，引发use-after-free或重复释放，最终触发SIGSEGV/SIGABRT或破坏JVM堆结构。

这类问题本质是 JNI 层资源管理失控导致的宿主机（JVM 或系统级进程）崩溃，不是 Java 层空指针或逻辑异常，而是原生侧释放缺失引发的 use-after-free 或 重复释放，最终触发 SIGSEGV、SIGABRT 或直接破坏 JVM 堆结构。

核心问题定位：本地方法中裸指针生命周期失控

多模块依赖下，多个模块可能通过 JNI 共享同一块原生资源（如图像缓冲区、解码器句柄、自定义对象指针）。常见错误包括：

• 模块 A 分配内存并传指针给 Java 层，Java 将该指针作为 long 存储在某个对象字段中
• 模块 B 在回调中误认为该指针仍有效，直接解引用或再次 free
• 模块 C 在析构时未检查指针是否已被其他模块释放，执行二次 free
• Java 对象被 GC 回收后，未触发 nativeFinalize 或未注册 NativeReference，导致原生资源永久泄漏

典型崩溃现场特征

查看崩溃栈时，重点关注三点：

• pc 地址非法：如 pc=0x0000000000000000（空指针解引用）或 pc=0xdeadbeef（已释放内存地址）
• 调用链含 JNIEnv 操作但无 Java 栈帧：说明崩溃发生在 native 回调内部，而非 Java 主动调用
• 崩溃点在 std::string 构造、malloc_usable_size、vtable 调用等底层函数：暗示堆元数据已被破坏，通常是多次释放或越界写入所致

可靠防御措施

不依赖“谁先释放”，而靠机制保障唯一所有权和自动清理：

• 所有跨模块传递的原生指针，必须封装为 std::shared_ptr 或 std::unique_ptr，并通过 JNI_OnLoad 注册全局弱引用表（WeakGlobalRef + 自定义 deleter）
• Java 层使用 Cleaner 或 PhantomReference 替代 finalize()，确保 GC 触发时能安全回调 native 释放逻辑
• 每个模块在获取指针前，必须调用 isValidHandle(ptr) —— 该函数基于内存页保护（mprotect）或原子计数校验其有效性，而非仅判空
• 启用 GWP-ASan 编译选项，在测试阶段随机拦截堆分配，提前暴露 use-after-free 和 double-free

调试与复现建议

仅靠日志难定位，需组合工具链：

• 用 adb shell setprop debug.malloc.options backtrace 开启 libc malloc 调试，获取每次 malloc/free 的完整调用栈
• 在崩溃设备上抓取 tombstone，并用 ndk-stack -sym $SO_PATH 符号化解析，确认 free 和 crash 是否来自不同模块
• 对关键 native 对象添加 ASAN_OPTIONS=detect_stack_use_after_return=1 运行，捕获栈变量逃逸问题