是什么使JNI通话变慢？

我知道在Java中进行JNI调用时“跨越边界”很慢。

不过，我想知道什么是它，使得它慢？进行JNI调用如此之慢时，底层jvm实现会做什么？

首先，值得注意的是，“慢”是指可能花费数十纳秒的时间。对于琐碎的本机方法，2010年，我在Windows桌面上测得的呼叫平均时间为40 ns，在Mac桌面上测得的平均呼叫时间为11 ns。除非您打很多电话，否则您不会注意到。

也就是说，调用本机方法可能比进行常规Java方法调用慢。原因包括：

• JVM不会内联本机方法。也不会为该特定机器及时编译它们-它们已经被编译。
• 可以复制Java数组以使用本机代码进行访问，然后再复制回去。成本在阵列大小上可以是线性的。我测量了100,000个阵列的JNI 复制，在我的Windows桌面上平均大约75微秒，在Mac上平均为82微秒。幸运的是，可以通过GetPrimitiveArrayCritical或NewDirectByteBuffer获得直接访问。
• 如果该方法传递了一个对象，或者需要进行回调，则本机方法可能会自己对JVM进行调用。从本机代码访问Java字段，方法和类型需要进行类似于反射的操作。签名是在字符串中指定的，并从JVM查询。这既缓慢又容易出错。
• Java字符串是对象，具有长度并且已编码。访问或创建字符串可能需要O（n）副本。

在Steve Wilson和Jeff Kesselman于2000年出版的“ Java？平台性能：策略和策略”中的“ 9.2：检查JNI成本”部分中，可以找到一些可能过时的附加讨论。大约是此页面下三分之一的位置，在下面@Philip的评论中提供。

2009年IBM developerWorks论文“使用Java本机接口的最佳实践”提供了一些有关避免JNI的性能陷阱的建议。

值得一提的是，并非所有标有Java的方法native都是“慢速”的。其中一些是内在函数，使它们变得非常快。要检查哪些是固有的，哪些不是固有的，可以do_intrinsic在vmSymbols.hpp中查找。

基本上，JVM会为每个JNI调用解释性地构造C参数，并且不会对代码进行优化。

本文概述了更多细节

如果您对基准测试JNI与本机代码感兴趣，则该项目具有用于运行基准测试的代码。