施用 Java Native Interface 的最佳实践

使用 Java Native Interface 的最佳实践???????? Java? 本机接口（Java Native Interface，JNI）是一个标准的

使用 Java Native Interface 的最佳实践

???????? Java? 本机接口（Java Native Interface，JNI）是一个标准的 Java API，它支持将 Java 代码与使用其他编程语言编写的代码相集成。如果您希望利用已有的代码资源，那么可以使用 JNI 作为您工具包中的关键组件 —— 比如在面向服务架构（SOA）和基于云的系统中。但是，如果在使用时未注意某些事项，则 JNI 会迅速导致应用程序性能低下且不稳定。本文将确定 10 大 JNI 编程缺陷，提供避免这些缺陷的最佳实践，并介绍可用于实现这些实践的工具。

Java 环境和语言对于应用程序开发来说是非常安全和高效的。但是，一些应用程序却需要执行纯 Java 程序无法完成的一些任务，比如：

与旧有代码集成，避免重新编写。

实现可用类库中所缺少的功能。举例来说，在 Java 语言中实现 ping 时，您可能需要 Internet Control Message Protocol (ICMP) 功能，但基本类库并未提供它。

最好与使用 C/C++ 编写的代码集成，以充分发掘性能或其他与环境相关的系统特性。

解决需要非 Java 代码的特殊情况。举例来说，核心类库的实现可能需要跨包调用或者需要绕过其他 Java 安全性检查。

JNI 允许您完成这些任务。它明确分开了 Java 代码与本机代码（C/C++）的执行，定义了一个清晰的 API 在这两者之间进行通信。从很大程度上说，它避免了本机代码对 JVM 的直接内存引用，从而确保本机代码只需编写一次，并且可以跨不同的 JVM 实现或版本运行。

借助 JNI，本机代码可以随意与 Java 对象交互，获取和设计字段值，以及调用方法，而不会像 Java 代码中的相同功能那样受到诸多限制。这种自由是一把双刃剑：它牺牲 Java 代码的安全性，换取了完成上述所列任务的能力。在您的应用程序中使用 JNI 提供了强大的、对机器资源（内存、I/O 等）的低级访问，因此您不会像普通 Java 开发人员那样受到安全网的保护。JNI 的灵活性和强大性带来了一些编程实践上的风险，比如导致性能较差、出现 bug 甚至程序崩溃。您必须格外留意应用程序中的代码，并使用良好的实践来保障应用程序的总体完整性。

本文介绍 JNI 用户最常遇到的 10 大编码和设计错误。其目标是帮助您认识到并避免它们，以便您可以编写安全、高效、性能出众的 JNI 代码。本文还将介绍一些用于在新代码或已有代码中查找这些问题的工具和技巧，并展示如何有效地应用它们。

JNI 编程缺陷可以分为两类：

性能：代码能执行所设计的功能，但运行缓慢或者以某种形式拖慢整个程序。 正确性：代码有时能正常运行，但不能可靠地提供所需的功能；最坏的情况是造成程序崩溃或挂起。

性能技巧 #1

查找并全局缓存常用的类、字段 ID 和方法 ID。

清单 3 没有使用缓存的字段 ID：

清单 3. 未缓存字段 ID

性能技巧 #2

获取和更新仅本机代码需要的数组部分。在只要数组的一部分时通过适当的 API 调用来避免复制整个数组。

GetTypeArrayRegion() 和 SetTypeArrayRegion() 方法允许您获取和更新数组的一部分，而不是整个数组。通过使用这些方法访问较大的数组，您可以确保只复制本机代码将要实际使用的数组部分。

举例来说，考虑相同方法的两个版本，如清单 4 所示：

清单 4. 相同方法的两个版本

性能技巧 #3

在单个 API 调用中尽可能多地获取或更新数组内容。如果可以一次较多地获取和更新数组内容，则不要逐个迭代数组中的元素。

另一方面，如果您最终要获取数组中的所有元素，则使用 GetTypeArrayRegion() 逐个获取数组中的元素是得不偿失的。要获取最佳的性能，应该确保以尽可能大的块的来获取和更新数组元素。如果您要迭代一个数组中的所有元素，则清单 4 中这两个 getElement() 方法都不适用。比较好的方法是在一个调用中获取大小合理的数组部分，然后再迭代所有这些元素，重复操作直到覆盖整个数组。

性能技巧 #4

如果可能，将各参数传递给 JNI 本机代码，以便本机代码回调 JVM 获取所需的数据。

sumValues2() 方法需要 6 个 JNI 回调，并且运行 10,000,000 次需要 3,572 ms。其速度比 sumValues() 慢 6 倍，后者只需要 596 ms。通过传递 JNI 方法所需的数据，sumValues() 避免了大量的 JNI 开销。

性能技巧 #5

定义 Java 代码与本机代码之间的界限，最大限度地减少两者之间的互相调用。

因此，在设计 Java 代码与本机代码之间的界限时应该最大限度地减少两者之间的相互调用。消除不必要的越界调用，并且应该竭力在本机代码中弥补越界调用造成的成本损失。最大限度地减少越界调用的一个关键因素是确保数据处于 Java/本机界限的正确一侧。如果数据未在正确的一侧，则另一侧访问数据的需求则会持续发起越界调用。

举例来说，如果我们希望使用 JNI 为某个串行端口提供接口，则可以构造两种不同的接口。第一个版本如清单 6 所示：

清单 6. 到串行端口的接口：版本 1

性能技巧 #6

构造应用程序的数据，使它位于界限的正确的侧，并且可以由使用它的代码访问，而不需要大量跨界调用。

最显著的一个问题就是，清单 6 中的接口在设置或检索每个位，以及从串行端口读取字节或者向串行端口写入字节都需要一个 JNI 调用。这会导致读取或写入的每个字节的 JNI 调用变成原来的 9 倍。第二个问题是，清单 6 将串行端口的配置信息存储在 Java/本机界限的错误一侧的某个 Java 对象上。我们仅在本机侧需要此配置数据；将它存储在 Java 侧会导致本机代码向 Java 代码发起大量回调以获取/设置此配置信息。清单 7 将配置信息存储在一个本机结构中（比如，一个 struct），并向 Java 代码返回了一个不透明的句柄，该句柄可以在后续调用中返回。这意味着，当本机代码正在运行时，它可以直接访问该结构，而不需要回调 Java 代码获取串行端口硬件地址或下一个可用的缓冲区等信息。因此，使用清单 7 的实现的性能将大大改善。

性能技巧 #7

当本机代码造成创建大量本地引用时，在各引用不再需要时删除它们。

这些本地引用会在本机方法终止时自动释放。JNI 规范要求各本机代码至少能创建 16 个本地引用。虽然这对许多方法来说都已经足够了，但一些方法在其生存期中却需要更多的本地引用。对于这种情况，您应该删除不再需要的引用，方法是使用 JNI DeleteLocalRef() 调用，或者通知 JVM 您将使用更多的本地引用。

清单 9 向清单 8 中的示例添加了一个 DeleteLocalRef() 调用，用于通知 JVM 本地引用已不再需要，以及将可同时存在的本地引用的数量限制为一个合理的数值，而与数组的大小无关：

清单 9. 添加 DeleteLocalRef()

性能技巧 #8

如果某本机代码将同时存在大量本地引用，则调用 JNI EnsureLocalCapacity() 方法通知 JVM 并允许它优化对本地引用的处理。

您可以调用 JNI EnsureLocalCapacity() 方法来通知 JVM 您将使用超过 16 个本地引用。这将允许 JVM 优化对该本机代码的本地引用的处理。如果无法创建所需的本地引用，或者 JVM 采用的本地引用管理方法与所使用的本地引用数量之间不匹配造成了性能低下，则未成功通知 JVM 会导致 FatalError。

正确性技巧 #1

仅在相关的单一线程中使用 JNIEnv。

线程可以调用通过 JavaVM 对象使用 JNI 调用接口的 GetEnv() 来获取 JNIEnv。JavaVM 对象本身可以通过使用 JNIEnv 方法调用 JNI GetJavaVM() 来获取，并且可以被缓存以及跨线程共享。缓存 JavaVM 对象的副本将允许任何能访问缓存对象的线程在必要时获取对它自己的 JNIEnv 访问。要实现最优性能，线程应该绕过 JNIEnv，因为查找它有时会需要大量的工作。

正确性技巧 #2

在发起可能会导致异常的 JNI 调用后始终检测异常。

添加异常检测代码要比在事后尝试调试崩溃简单很多。经常，您只需要检测是否出现了某个异常，如果是则立即返回 Java 代码以便抛出异常。然后，使用常规的 Java 异常处理流程处理它或者显示它。举例来说，清单 11 将检测异常：

清单 11. 检测异常

正确性技巧 #3

始终检测 JNI 方法的返回值，并包括用于处理错误的代码路径。

您可以确定以下代码的问题吗？

正确性技巧 #4

不要忘记为每个 GetXXX() 使用模式 0（复制回去并释放内存）调用 ReleaseXXX()。

在提供直接指向数组的指针的 JVM 上，该数组将被更新；但是，在返回副本的 JVM 上则不是如此。这会造成您的代码在一些 JVM 上能够正常运行，而在其他 JVM 上却会出错。您应该始终始终包括一个释放（release）调用，如清单 12 所示：

清单 12. 包括一个释放调用

正确性技巧 #5

确保代码不会在 GetXXXCritical() 和 ReleaseXXXCritical() 调用之间发起任何 JNI 调用或由于任何原因出现阻塞。

但是，我们需要验证在调用 processBufferHelper() 时可以运行的所有代码都没有违反任何限制。这些限制适用于在 Get 和 Release 调用之间执行的所有代码，无论它是不是本机的一部分。

正确性技巧 #6

始终跟踪全局引用，并确保不再需要对象时删除它们。

创建全局引用时，JVM 会将它添加到一个禁止垃圾收集的对象列表中。当本机返回时，它不仅会释放全局引用，应用程序还无法获取引用以便稍后释放它 — 因此，对象将会始终存在。不释放全局引用会造成各种问题，不仅因为它们会保持对象本身为活动状态，还因为它们会将通过该对象能接触到的所有对象都保持为活动状态。在某些情况下，这会显著加剧内存泄漏。

通过查看后续 Java 转储中报告的数值，您可以确定全局引用是否出现的泄漏。

参见参考资料获取关于使用转储文件以及 IBM JVM 的 jextract 的更多信息。

结束语

现在，您已经了解了 10 大 JNI 编程缺陷，以及一些用于在已有或新代码中确定它们的良好实践。坚持应用这些实践有助于提高 JNI 代码的正确率，并且您的应用程序可以实现所需的性能水平。

有效集成已有代码资源的能力对于面向对象架构（SOA）和基于云的计算这两种技术的成功至关重要。JNI 是一项非常重要的技术，用于将非 Java 旧有代码和组件集成到基于 Java 的平台中，充当 SOA 或基于云的系统的基本元素。正确使用 JNI 可以加速将这些组件转变为服务的过程，并允许您从现有投资中获得最大优势。