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

關(guān)于這個問題，R大在他的ITeyeblog上講到過

根據(jù)這篇文章介紹

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。