在 Java 生态中，JNI（Java Native Interface）一直被视为“老牌”的本地调用方案。说它重要，不少业务开发几乎用不到；说它过时，但凡遇到操作系统底层、硬件驱动、加密算法或遗留 C/C++ 库，它依然是绕不开的桥梁。今天来聊聊如何把 JNI 用好，避免用它制造性能瓶颈或内存崩溃——遵循正确实践，JNI 完全可以达到接近本地的运行效率。

1. JNI 的核心应用场景

Java 需要调用 C/C++ 库的场景十分清晰：操作系统 API、硬件驱动、加密算法与遗留代码。JNI 是标准桥接技术，但错误使用会引发性能损失与内存崩溃。掌握正确的实践方法，就能获得接近本地的性能表现。

2. 减少边界切换开销

JNI 的性能瓶颈往往不是调用本身有多慢，而是边界切换带来的额外成本。几个核心策略：

批处理：避免在循环中逐个发起 native 调用，改为传入数组，在 native 端一次性处理整体数据。

直接缓冲区：使用 ByteBuffer.allocateDirect，让 native 代码直接访问内存，省去数据复制环节。

Critical 数组：借助 GetPrimitiveArrayCritical 获取指针，但该方法会阻塞 GC，务必尽快释放。

缓存 jmethodID/jfieldID：在 native 代码中缓存这些 ID，避免每次调用都重新执行 GetMethodID 查找。

3. 严谨的内存管理

JNI 的内存泄漏是常见的“隐形杀手”。重点关注三点：

释放本地引用：调用 DeleteLocalRef，否则本地引用表会溢出——默认上限仅 512 个。

全局引用：NewGlobalRef 必须与 DeleteGlobalRef 配对使用，否则必然内存泄漏。

异常检查：调用 Java 方法后务必检查 ExceptionOccurred 并妥善处理，否则崩溃随时可能发生。

4. JNI 性能对比实例

一个图像处理任务可以说明问题：纯 Java 实现 vs 调用 C++ OpenCV。JNI 版本使用 GetDirectBufferAddress 直接操作像素数据，耗时 12ms；Java 版本使用 BufferedImage 需要 85ms。至于 JNI 调用自身的成本，每次约 50 纳秒，几乎可以忽略不计。

5. 案例：密码学加速

某金融系统需要高频签名（SM2 算法），Java 实现的签名速度不够。改用 JNI 调用 C++ 的 GMSSL 库，策略如下：

一次 JNI 调用批量处理一组签名请求（数组），避免多次边界切换。

使用 DirectBuffer 传递签名参数。

在 native 层管理签名上下文对象，Java 层仅持有 long 指针，避免反复创建对象。

最终签名吞吐量提升了 10 倍。

6. 替代方案概览

JNI 并非唯一选择。Java 外部内存访问 API（Foreign Memory Access）从 Java 14 预览到 Java 18 正式发布，比 JNI 更简洁。JNA 支持动态调用，无需生成头文件，但性能低于 JNI。Project Panama 则是未来彻底替代 JNI 的方向。

7. 总结

JNI 是 Java 调用本地代码的经典方式。正确运用批处理、直接缓冲区与缓存策略，可以获得接近原生的性能。对于需要复用大量 C/C++ 库的 Java 项目，JNI 依然是不可或缺的工具。