在編譯時不知道Java類的最快方法是什么？ Java框架通常會這樣做。 很多。 它可以直接影響其性能。 因此，讓我們對不同的方法進行基準測試，例如反射，方法句柄和代碼生成。

用例

假設我們有一個簡單的Person類，其中包含名稱和地址：

public class Person {...public String getName() {...}public Address getAddress() {...}}

并且我們想使用諸如以下的框架：

• XStream ，JAXB或Jackson來將實例序列化為XML或JSON。
• JPA /休眠將人員存儲在數據庫中。
• OptaPlanner分配地址（如果他們是游客或無家可歸的人）。

這些框架都不了解Person類。 因此，他們不能簡單地調用person.getName() ：

// Framework codepublic Object executeGetter(Object object) {// Compilation error: class Person is unknown to the frameworkreturn ((Person) object).getName();}

相反，代碼使用反射，方法句柄或代碼生成。

但是這樣的代碼被稱為很多 ：

• 如果在數據庫中插入1000個不同的人，則JPA / Hibernate可能會調用2000次這樣的代碼：
  • 1000次調用Person.getName()
• 同樣，如果您用XML或JSON編寫1000個不同的人，則XStream，JAXB或Jackson可能會進行2000次調用。

顯然，當這種代碼每秒被調用x次時， 其性能很重要 。

基準測試

使用JMH，我在帶有32GB RAM的64位8核Intel i7-4790臺式機上的Linux上使用OpenJDK 1.8.0_111運行了一組微型基準測試。 JMH基準測試有3個分支，5個1秒的預熱迭代和1秒的20個測量迭代。

該基準的源代碼位于此GitHub存儲庫中 。

TL; DR結果

• Java反射很慢。 （*）
• Java MethodHandles也很慢。 （*）
• 用javax.tools生成的代碼很快。 （*）

（*）在用例中，我以使用的工作量作為基準。 你的旅費可能會改變。

因此，魔鬼在細節中。 讓我們瀏覽一下實現，以確認我應用了典型的魔術技巧（例如setAccessible(true) ）。

實作

直接訪問（基準）

我使用了一個普通的person.getName()調用作為基準：

public final class MyAccessor {public Object executeGetter(Object object) {return ((Person) object).getName();}}

每次操作大約需要2.7納秒：

Benchmark Mode Cnt Score Error Units =================================================== DirectAccess avgt 60 2.667 ± 0.028 ns/op

直接訪問自然是運行時最快的方法，而沒有引導成本。 但是它在編譯時導入Person ，因此每個框架都無法使用它。

反射

框架在運行時讀取getter的明顯方法是不預先知道它的方法是通過Java Reflection：

public final class MyAccessor {private final Method getterMethod;public MyAccessor() {getterMethod = Person.class.getMethod("getName");// Skip Java language access checking during executeGetter()getterMethod.setAccessible(true);}public Object executeGetter(Object bean) {return getterMethod.invoke(bean);}}

添加setAccessible(true)調用可使這些反射調用更快，但是即使這樣，每個調用也要花費5.5納秒。

Benchmark Mode Cnt Score Error Units =================================================== DirectAccess avgt 60 2.667 ± 0.028 ns/op Reflection avgt 60 5.511 ± 0.081 ns/op

反射比直接訪問慢106％（大約慢一倍）。 預熱還需要更長的時間。

這對我來說不是什么大驚喜，因為當我使用OptaPlanner在980個城市中描述（使用抽樣）一個人為簡單的旅行商問題時，反射成本像拇指酸痛一樣突出：

方法句柄

Java 7中引入了MethodHandle來支持invokedynamic指令。 根據javadoc，它是對基礎方法的類型化，直接可執行的引用。 聽起來很快，對不對？

public final class MyAccessor {private final MethodHandle getterMethodHandle;public MyAccessor() {MethodHandle temp = lookup.findVirtual(Person.class, "getName", MethodType.methodType(String.class));temp = temp.asType(temp.type().changeParameterType(0 , Object.class));getterMethodHandle = temp.asType(temp.type().changeReturnType(Object.class));}public Object executeGetter(Object bean) {return getterMethodHandle.invokeExact(bean);}}

不幸的是， MethodHandle甚至比 OpenJDK 8中的反射還要慢 。它每次操作花費6.1納秒，因此比直接訪問慢132％。

Benchmark Mode Cnt Score Error Units =================================================== DirectAccess avgt 60 2.667 ± 0.028 ns/op Reflection avgt 60 5.511 ± 0.081 ns/op MethodHandle avgt 60 6.188 ± 0.059 ns/op StaticMethodHandle avgt 60 5.481 ± 0.069 ns/op

話雖如此，如果MethodHandle在靜態字段中，則每次操作只需要5.5納秒，這仍然與反射一樣慢 。 此外，對于大多數框架而言，這是無法使用的。 例如，JPA實現可能需要反映n類（ Person ， Company ， Order等等）的m getters（ getName() ， getAddress() ， getBirthDate() ，...），因此JPA實現如何有n * m靜態字段，在編譯時不知道n或m ？

我確實希望MethodHandle在將來的Java版本中能夠像直接訪問一樣快，從而取代對...的需求。

使用javax.tools.JavaCompiler生成的代碼

在Java中，可以在運行時編譯和運行生成的Java代碼。 因此，使用javax.tools.JavaCompiler API，我們可以在運行時生成直接訪問代碼：

public abstract class MyAccessor {public static MyAccessor generate() {final String String fullClassName = "x.y.generated.MyAccessorPerson$getName";final String source = "package x.y.generated;\n"+ "public final class MyAccessorPerson$getName extends MyAccessor {\n"+ " public Object executeGetter(Object bean) {\n"+ " return ((Person) object).getName();\n"+ " }\n"+ "}";JavaFileObject fileObject = new ...(fullClassName, source);JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();ClassLoader classLoader = ...;JavaFileManager javaFileManager = new ...(..., classLoader)CompilationTask task = compiler.getTask(..., javaFileManager, ..., singletonList(fileObject));boolean success = task.call();...Class compiledClass = classLoader.loadClass(fullClassName);return compiledClass.newInstance();}// Implemented by the generated subclasspublic abstract Object executeGetter(Object object);}

有關如何使用javax.tools.JavaCompiler更多信息，請參見本文或本文的 第2頁 。 除了javax.tools之外，類似的方法也可以使用ASM或CGLIB，但是這些方法會推斷出額外的依賴性，并且可能會產生不同的性能結果。

無論如何， 生成的代碼與直接訪問一樣快 ：

Benchmark Mode Cnt Score Error Units =================================================== DirectAccess avgt 60 2.667 ± 0.028 ns/op GeneratedCode avgt 60 2.745 ± 0.025 ns/op

因此，當我再次在OptaPlanner中運行該完全相同的Traveling Salesman問題時，這一次使用代碼生成來訪問計劃變量， 因此總分計算速度提高了18％ 。 并且分析（使用采樣）看起來也更好：

請注意，在正常使用情況下，由于大量CPU需要實際復雜的分數計算，因此性能提升幾乎是無法檢測到的...

運行時代碼生成的唯一缺點是，它會導致可觀的引導成本，特別是如果生成的代碼未進行批量編譯時。 因此，我仍然希望有一天MethodHandles能夠像直接訪問一樣快，只是為了避免增加引導成本。

結論

在此基準測試中，反射和MethodHandles的速度是OpenJDK 8中直接訪問的兩倍，但是生成的代碼的速度是直接訪問的速度。

Benchmark Mode Cnt Score Error Units =================================================== DirectAccess avgt 60 2.667 ± 0.028 ns/op Reflection avgt 60 5.511 ± 0.081 ns/op MethodHandle avgt 60 6.188 ± 0.059 ns/op StaticMethodHandle avgt 60 5.481 ± 0.069 ns/op GeneratedCode avgt 60 2.745 ± 0.025 ns/op

翻譯自: https://www.javacodegeeks.com/2018/01/java-reflection-much-faster.html

總結

以上是生活随笔為你收集整理的Java反射，但速度更快的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。