Method.invoke()本身要用數組包裝參數；而且每次調用都必須檢查方法的可見性(在Method.invoke()里)，也必須檢查每個實際參數與形式參數的類型匹配性(在NativeMethodAccessorImpl.invoke0()里或者生成的Java版MethodAccessor.invoke()里)；而且Method.invoke()就像是個獨木橋一樣，各處的反射調用都要擠過去，在調用點上收集到的類型信息就會很亂，影響內聯程序的判斷，使得Method.invoke()自身難以被內聯到調用方。關于反射調用方法的一個log?rednaxelafx.iteye.com

關于這個問題，R大在他的ITeyeblog上講到過

根據這篇文章介紹

每一個Method都有一個root，不暴漏給外部，而是每次copy一個Method。

具體的反射調用邏輯是委托給MethodAccessor的，而accessor對象會在第一次invoke的時候才創建，是一種lazy init方式。而且默認Class類會cache method對象。目前MethodAccessor的實現有兩種，通過設置inflation，一個native方式，一種生成java bytecode方式。native方式啟動快，但運行時間長了不如java方式，個人感覺應該是java方式運行長了,jit compiler可以進行優化。所以JDK6的實現，在native方式中，有一個計數器，當調用次數達到閥值，就會轉為使用java方式。默認值是15。java方式的實現，基本和非反射方式相同。主要影響性能的問題，1是method.invoke中每次都要進行參數數組包裝，2.在method.invoke中要進行方法可見性檢查，3在accessor的java實現方式下，invoke時會檢查參數的類型匹配。而在JDK7中methodhandle來做反射調用，形參和實參是準確的，所以只需要在鏈接方法的時候做檢查，調用時不用再做檢查。并且methodhandle是不可變值，所以jvm可以做激進優化，例如內聯。

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的java反射的优化_请问Java反射的性能为什么比直接调用慢一个数量级左右？的全部內容，希望文章能夠幫你解決所遇到的問題。

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