1. 从一次内存泄漏排查说起那个诡异的 long 值几年前我在维护一个音视频处理项目时遇到了一个让人头疼的问题。这个项目使用 Java 作为主控逻辑层核心的音视频编解码算法则用 C 实现通过 JNI 进行桥接。项目运行一段时间后内存占用会持续飙升最终导致进程崩溃。使用常规的 Java 内存分析工具如 MAT去排查发现堆内存很健康但整个进程的 RSS常驻内存却高得离谱。问题的矛头很快指向了 JNI 层。我们有一个NativeDecoder类它的native long createDecoder(String config)方法会返回一个long类型的值我们称之为nativeHandle。后续所有操作比如decodeFrame(long handle, byte[] data)、release(long handle)都依赖这个handle。当时一个初级同事怀疑是这个long值在传递过程中“损坏”了导致release时无法正确释放 C 对象从而引发内存泄漏。他提出了一个看似合理的猜想Java 的long是 64 位有符号整数而 C 的指针在 32 位系统上是 32 位在 64 位系统上是 64 位。会不会是位数不对齐或者符号位干扰导致这个long值无法准确“指向” C 对象使得release函数调用了错误的内存地址进而无法释放资源这个猜想听起来挺像那么回事也触及了 JNI 编程的一个核心困惑Java 世界里一个普普通通的long型变量凭什么就能在 C 那边准确地找到一个对象并对其进行操作这背后不是魔法而是一个精巧且必须深刻理解的机制——指针的跨语言“伪装”与传递。理解它不仅是解决这类内存问题的关键更是写出稳健、高效 JNI 代码的基石。今天我们就来彻底拆解这个long背后的秘密。2. 跨越语言的鸿沟JNI 中对象引用的两种范式要理解long为何能定位 C 对象首先得明白 JNI 设计之初为 Java 与本地代码C/C之间的对象交互提供的两种基本范式。这两种范式决定了本地代码“看见”和“操作”Java 对象的方式也反向影响了 Java 代码如何“持有”本地对象。2.1 范式一JNI 对象引用JNI Object References这是 JNI 最直接、最“安全”的对象交互方式。当你在本地代码中通过GetObjectField,CallObjectMethod等函数获取到一个jobject或其子类如jstring,jarray时你得到的并不是 Java 对象在内存中的直接地址而是一个由 JNI 层管理的“引用”Reference。这个引用可以理解为指向 JNI 内部某个结构体的句柄该结构体再关联到真正的 Java 对象。JNI 引用主要分为两种局部引用Local Reference在本地方法调用期间创建在该方法返回后会自动被 JVM 垃圾回收器识别并可能释放。你不能在方法返回后继续使用它。它的存在是为了防止本地代码长期持有 Java 对象导致其无法被 GC。全局引用Global Reference通过NewGlobalRef函数创建它会阻止所引用的 Java 对象被 GC直到你显式调用DeleteGlobalRef将其删除。这允许你在多个本地方法调用间、甚至在不同线程间共享同一个 Java 对象。为什么需要这个“引用”层核心是为了维护 Java 内存模型的安全性与一致性。JVM 的垃圾回收器GC会移动对象以压缩内存标记-整理算法。如果 C 代码直接持有 Java 对象的裸内存地址GC 一动这个地址就失效了程序必然崩溃。JNI 引用作为一个中间层GC 在移动对象后会更新 JNI 内部结构体中的实际指针而 C 代码持有的“引用”值那个句柄保持不变从而保证了安全性。2.2 范式二直接地址jlong与指针的转换JNI 对象引用虽然安全但有其局限性。它主要服务于Java 对象的生命周期管理。当我们想在 Java 端长期持有并管理一个 C 本地对象时JNI 引用就不适用了。因为 C 对象的生命周期完全由本地代码通常是new/delete或malloc/free管理JVM 的 GC 对其一无所知。这时就需要一种更“原始”的传递方式。JNI 提供了jlong类型它在 C/C 端通常被定义为long long是一个 64 位的有符号整数类型。它的妙用在于我们可以将一个 C 对象的指针内存地址强制转换cast成一个jlong类型的整数然后将其从本地方法返回给 Java。// C 侧代码示例 JNIEXPORT jlong JNICALL Java_MyClass_createNativeObject(JNIEnv* env, jobject thiz) { // 1. 在堆上创建一个 C 对象 MyNativeClass* nativeObj new MyNativeClass(); // 2. 关键步骤将 C 对象指针转换为 jlong jlong handle reinterpret_castjlong(nativeObj); // 3. 将这个“句柄”返回给 Java return handle; }在 Java 侧对应的方法声明则使用long类型来接收这个值// Java 侧代码示例 public class MyClass { // 声明一个返回 long 的 native 方法 public native long createNativeObject(); // 后续用这个 long 来操作对应的 C 对象 public native void operateOnObject(long handle); public native void destroyNativeObject(long handle); private long nativeHandle; // 用一个 long 成员变量来保存这个“句柄” }这个过程可以形象地理解为我们把 C 对象的“家庭住址”指针写在一张纸条jlong上然后把这张纸条交给了 Java。Java 看不懂地址但它可以妥善保管这张纸条。当它需要通知 C 对这个家做什么事时比如调用operateOnObject就把这张纸条原封不动地递回给 C。C 拿到纸条读出上面的地址reinterpret_castMyNativeClass*(handle)就能找到那个对象。这里就回答了标题的核心问题Java 里的一个long为什么能找到 C 对象答案就是这个long值根本不是一个普通的数字它是 C 对象指针经过类型转换后得到的数值化表示。它本身不包含任何对象信息只是一个“定位坐标”。真正的“寻找”动作发生在 C 代码收到这个long并将其转换回指针的那一刻。3. 指针与jlong互转的底层原理与风险理解了基本范式我们深入到比特位层面看看指针到jlong的转换到底发生了什么以及这里埋藏着哪些“坑”。3.1 类型转换的底层操作在 C 中指针本质上是一个存储内存地址的变量。在 64 位系统上这个地址是 64 位宽度的。reinterpret_cast是 C 中用于进行低级别、重新解释类型的转换运算符。reinterpret_castjlong(ptr)所做的就是告诉编译器“别管ptr原来是什么类型的指针就把它占用的那 64 位内存数据当作一个jlonglong long类型的整数来用。”这个过程是双向的传出C - Java:jlong handle reinterpret_castjlong(nativeObjPtr);传入Java - C:MyNativeClass* objPtr reinterpret_castMyNativeClass*(handle);从内存角度看没有任何数据被创建或销毁只是同一段比特数据那个 64 位的内存地址被赋予了不同的“类型标签”以便在不同语境C指针 vs Java long下传递。3.2 关键风险符号位与平台差异虽然原理简单但魔鬼在细节中。直接转换指针到有符号的jlong存在两个主要风险1. 符号扩展Sign Extension问题这是开头提到的同事所怀疑的问题之一。如果我们在一个32 位系统上指针是 32 位将一个指针转换成jlong64 位编译器会进行“符号扩展”。即它会根据指针值的最高位第31位是0还是1来决定新扩展的高32位是补0还是补1。如果指针值最高位是0地址小于2GB转换后高32位补0结果正确。如果指针值最高位是1地址大于等于2GB转换后高32位补1这个jlong就变成了一个负数。当这个负数传回 Java再传回 C 转换时如果处理不当就可能出错。不过在现代 64 位 JVM 和系统中通常直接使用 64 位指针和jlong这个问题不常见但在涉及混合架构或历史代码时仍需警惕。2. 指针值本身的有效性这是更常见、更致命的问题。转换本身不检查指针是否有效。你完全可以把任意一个数字比如0或0xDEADBEEF当作handle传给 CC 也会忠实地把它当作地址去访问结果就是段错误Segmentation Fault或访问违规导致程序崩溃。注意这里必须强调一个重要的安全原则。在 JNI 编程中绝对不能将来自 Java 的、未经校验的long值直接转换回指针并使用。必须建立某种形式的“句柄管理”或验证机制。一个简单的做法是在创建对象时不仅返回指针还可以将一个已知的魔数Magic Number或校验和与指针一起存储在一个结构体中然后将该结构体的指针作为handle返回。在转换回指针后先检查魔数是否正确。3.3 对比与 JNI 对象引用的本质区别为了更清晰我们通过一个表格对比这两种机制特性JNI 对象引用 (jobject,jstring等)直接指针转换 (jlong/long)管理对象Java 对象C/Native 对象生命周期管理受 JVM GC 影响局部/全局引用完全由本地代码手动控制 (new/delete)安全性高JNI 层保证引用有效性防止野指针低完全依赖开发者正确传递和转换性能开销较高涉及 JNI 引用表查找和管理极低本质就是整数传递和强制转换典型用途在本地方法中操作传入的 Java 对象参数在 Java 端持有并管理本地资源的“句柄”GC 影响GC 会移动 Java 对象但 JNI 引用会更新GC 不影响 C 对象地址跨线程全局引用可以但需谨慎处理JNIEnv*handle值本身可以传递但对象线程安全性需自行保证4. 实战设计一个稳健的 Native 句柄管理系统理解了原理和风险后我们不能停留在“能跑就行”的层面。在实际项目中尤其是需要创建大量本地对象或对象关系复杂时直接裸传指针是极其危险的。我们需要构建一个健壮的“句柄”管理系统。下面我分享一个在实际项目中经过验证的、相对完善的方案。4.1 基础方案封装与校验最基础的改进是为每个返回的handle增加校验信息。我们不是直接返回MyClass*而是返回一个Handle结构体的指针。// native_lib.h #ifndef NATIVE_LIB_H #define NATIVE_LIB_H #include cstdint // 定义一个魔数用于校验 handle 的有效性 constexpr uint64_t HANDLE_MAGIC 0xDEADBEEFC0FEE123; struct NativeHandle { uint64_t magic; // 魔数用于验证 void* nativeObject; // 真正的 C 对象指针 // 可以扩展其他信息如创建时间戳、类型标识等 }; #endif //NATIVE_LIB_H对应的实现文件// native_lib.cpp #include native_lib.h #include my_native_class.h // 你的实际 C 类头文件 #include jni.h extern C { JNIEXPORT jlong JNICALL Java_com_example_MyClass_createHandle(JNIEnv* env, jobject thiz) { // 1. 创建真正的业务对象 MyNativeClass* realObj new (std::nothrow) MyNativeClass(); if (!realObj) { // 处理内存分配失败 return 0; // 返回 0 表示失败 } // 2. 创建 Handle 结构体 NativeHandle* handle new (std::nothrow) NativeHandle(); if (!handle) { delete realObj; return 0; } // 3. 填充 Handle handle-magic HANDLE_MAGIC; handle-nativeObject static_castvoid*(realObj); // 4. 将 Handle 结构体的指针作为 jlong 返回 return reinterpret_castjlong(handle); } JNIEXPORT void JNICALL Java_com_example_MyClass_useHandle(JNIEnv* env, jobject thiz, jlong handleLong) { // 1. 转换回指针并校验是否为 nullptr NativeHandle* handle reinterpret_castNativeHandle*(handleLong); if (handle nullptr) { // 记录错误日志或抛出 Java 异常 return; } // 2. 校验魔数这是防止非法 handle 的关键 if (handle-magic ! HANDLE_MAGIC) { // 魔数不对说明这是一个无效的、或被破坏的 handle // 可能是内存越界、重复释放、或传入了一个随机数 // 必须在此处失败返回绝不能继续使用 return; } // 3. 安全地取出真正的对象指针 MyNativeClass* realObj static_castMyNativeClass*(handle-nativeObject); if (realObj) { realObj-doSomething(); // 安全地调用 } } JNIEXPORT void JNICALL Java_com_example_MyClass_destroyHandle(JNIEnv* env, jobject thiz, jlong handleLong) { NativeHandle* handle reinterpret_castNativeHandle*(handleLong); if (handle nullptr || handle-magic ! HANDLE_MAGIC) { // 无效 handle无需释放或记录错误 return; } // 1. 删除真正的业务对象 MyNativeClass* realObj static_castMyNativeClass*(handle-nativeObject); delete realObj; handle-nativeObject nullptr; // 2. 将魔数置为无效值防止 Use-After-Free handle-magic 0; // 3. 删除 Handle 结构体本身 delete handle; } }这个方案虽然增加了一层间接性和微小的内存开销但带来了巨大的安全性提升。它能有效拦截大部分因handle值错误如传递了未初始化的long、错误的对象handle、或已释放的handle导致的崩溃。4.2 进阶方案句柄映射表与并发安全对于更复杂的系统特别是需要支持对象查询、调试信息收集或担心handle值被意外篡改的场景可以使用“句柄映射表”方案。核心思想不在 Java 和 C 间直接传递指针而是传递一个在映射表中查找的“键”Key。这个键可以是一个简单的递增整数int或long。C 侧维护一个全局的std::unordered_mapHandleID, NativeObject*。create时生成一个新 ID将(ID, object_ptr)插入映射表返回 ID。use时通过 ID 在映射表中查找object_ptr。如果找不到说明 ID 无效或对象已释放。destroy时通过 ID 找到object_ptr并删除然后从映射表中移除该条目。优点安全性更高Java 端持有的只是一个不透明的 ID即使被篡改也只是一个在映射表中不存在的数字查找失败返回nullptr不会导致随机的内存访问。便于调试和管理映射表本身可以记录额外的元信息如创建栈、引用计数、类型方便内存泄漏排查和运行时诊断。可以处理指针复用有些系统如某些嵌入式平台的内存地址可能范围很小直接传递指针值可能重复。使用唯一 ID 可以避免这个问题。缺点性能开销每次操作都需要一次哈希表查找O(1) 平均但有开销。并发问题全局映射表是共享资源在多线程 JNI 调用下必须加锁如std::mutex否则会导致数据竞争。这会成为性能瓶颈。一个简单的线程安全映射表示例#include jni.h #include unordered_map #include mutex #include atomic std::mutex gHandleMapMutex; std::unordered_mapjlong, MyNativeClass* gHandleMap; std::atomicjlong gNextHandleId{1}; // 原子递增避免ID冲突 JNIEXPORT jlong JNICALL Java_MyClass_createNativeObject(JNIEnv*, jobject) { MyNativeClass* obj new MyNativeClass(); jlong handleId gNextHandleId.fetch_add(1); // 原子获取下一个ID std::lock_guardstd::mutex lock(gHandleMapMutex); gHandleMap[handleId] obj; return handleId; } JNIEXPORT void JNICALL Java_MyClass_useNativeObject(JNIEnv*, jobject, jlong handleId) { std::lock_guardstd::mutex lock(gHandleMapMutex); auto it gHandleMap.find(handleId); if (it ! gHandleMap.end()) { it-second-doSomething(); } else { // 无效句柄记录日志或抛出异常 } }选择基础方案还是映射表方案取决于你的具体需求。对于性能极度敏感、对象数量可控、生命周期清晰的场景基础方案带校验的指针转换是更优选择。对于需要高安全性、便于调试或对象关系复杂的场景映射表方案更值得考虑。5. 避坑指南那些年我们踩过的long/指针转换的坑理论结合实践最后分享几个我在实际项目中踩过的、与这个long/指针转换机制相关的“坑”。希望你能绕道而行。5.1 坑一误用int而非long在早期 32 位系统为主流的时代有些开发者为了“节省空间”会用int或jint来传递指针。在 32 位系统上这确实可以工作因为指针和int都是 32 位。但这是一颗定时炸弹。问题当应用迁移到 64 位系统时指针变为 64 位。如果本地代码依然将 64 位指针强制转换为jint返回高 32 位数据会被直接截断Java 拿到一个被截断的int再传回给 CC 将其转换回指针这个地址完全是错误的必然导致崩溃或内存错误。教训永远使用jlong/long来传递可能是指针的句柄即使你在 32 位平台上开发。这保证了代码的跨平台兼容性。jlong在 32 位和 64 位系统上都是 64 位足以容纳任何平台的指针。5.2 坑二在finalize()中释放 Native 资源这是一个经典的、可能导致崩溃或资源泄漏的陷阱。public class NativeResourceHolder { private long nativeHandle; public NativeResourceHolder() { nativeHandle createNativeResource(); } // 错误的做法 Override protected void finalize() throws Throwable { releaseNativeResource(nativeHandle); // 调用 JNI 释放 super.finalize(); } }问题时机不确定finalize()方法何时被 GC 调用是不确定的甚至可能永远不被调用如果程序退出很快。这会导致 Native 资源如文件句柄、内存、GPU 显存无法及时释放。可能访问已失效对象finalize()被调用时对象可能处于“半死亡”状态其成员变量如nativeHandle可能已被破坏或重置。线程安全问题finalize()由 JVM 的 Finalizer 线程调用如果 Native 资源的释放不是线程安全的会引发问题。正确做法显式释放。实现Closeable或AutoCloseable接口提供close()或dispose()方法并要求调用者在使用完毕后显式调用。同时在finalize()中添加一个安全网但仅作为备份。public class NativeResourceHolder implements AutoCloseable { private long nativeHandle; private volatile boolean closed false; public NativeResourceHolder() { nativeHandle createNativeResource(); } Override public void close() { if (!closed) { releaseNativeResource(nativeHandle); nativeHandle 0; // 将 handle 置为无效值 closed true; } } // 安全网防止用户忘记调用 close() Override protected void finalize() throws Throwable { try { if (!closed) { // 这里最好只记录一个严重的警告日志而不是实际释放。 // 因为 finalize 线程环境复杂实际释放可能不安全。 System.err.println(WARNING: NativeResourceHolder was not closed properly!); } } finally { super.finalize(); } } } // 使用 try-with-resources 确保释放 try (NativeResourceHolder holder new NativeResourceHolder()) { holder.use(); }5.3 坑三多线程环境下的句柄共享与竞争假设你在 Java 端创建了一个对象获得了nativeHandle然后把这个对象连同它的handle传递给另一个线程使用。问题如果两个线程几乎同时调用useHandle和destroyHandle可能会发生线程 A 正在通过handle访问 C 对象例如正在解码一帧视频。线程 B 同时调用了destroyHandle释放了 C 对象的内存。线程 A 访问了已释放的内存导致未定义行为崩溃、数据错误。解决方案为 C 对象添加引用计数或使用智能指针。这是 C 中管理跨线程对象生命周期的标准做法。// 在 C 侧使用 std::shared_ptr JNIEXPORT jlong JNICALL Java_MyClass_createSharedObject(JNIEnv*, jobject) { std::shared_ptrMyNativeClass sharedObj std::make_sharedMyNativeClass(); // 将 shared_ptr 的指针存储到 Handle 中 NativeHandle* handle new NativeHandle(); handle-magic HANDLE_MAGIC; // 注意这里存储的是 shared_ptr 对象本身的地址或者将其拷贝到 Handle 内嵌的结构中。 // 更常见的做法是设计 Handle 时直接包含一个 shared_ptr。 // 为了简化这里假设我们有一个能持有 shared_ptr 的 Handle 结构。 handle-nativeObject new std::shared_ptrMyNativeClass(sharedObj); return reinterpret_castjlong(handle); } JNIEXPORT void JNICALL Java_MyClass_destroySharedHandle(JNIEnv*, jobject, jlong handleLong) { NativeHandle* handle reinterpret_castNativeHandle*(handleLong); if (handle handle-magic HANDLE_MAGIC) { // 删除内部的 shared_ptr当最后一个引用消失时对象自动销毁 delete static_caststd::shared_ptrMyNativeClass*(handle-nativeObject); handle-nativeObject nullptr; handle-magic 0; delete handle; } }这样只要还有任何一个线程持有这个shared_ptr或其包装的handle对象就不会被销毁。当所有引用都释放后对象才会被自动清理。这从根本上解决了生命周期竞争的问题。当然你还需要确保 C 对象本身的方法是线程安全的或者通过互斥锁进行保护。回到文章开头那个内存泄漏的问题。最终的排查结果并不是long值传递错误而是我们遗漏了对nativeHandle生命周期管理。某个异常分支导致release函数没有被调用而 C 对象又没有实现引用计数导致其永远无法被删除。我们引入了类似第 4 节的带校验Handle结构并在Handle中增加了简单的引用计数和日志很快就定位到了泄漏点。所以Java 里的那个long它只是一个信使。它能否准确找到 C 对象取决于你是否给了它正确的地址以及你是否在 C 侧建立了一套可靠的机制来验证和使用这个地址。理解这背后的指针本质是写出高质量、无隐患 JNI 代码的必经之路。