Java反射慢，到底慢在哪裡？
如遇圖片載入失敗，可嘗試使用手機流量訪問
反射具體是怎麼影響效能的？這引起了我的反思。是啊，在闡述某個觀點時確實有必要說明原因，並且證明這個觀點是對的，雖然反射影響效能人盡皆知，我曾經也真的研究過反射是否存在效能問題，但並沒有在寫文章的時候詳細說明。這讓我想到網上很多資訊只會告訴你結論，並不會說明原因，導致很多學到的東西都是死記硬背，而不是真正掌握，別人一問或者自己親身遇到同樣的問題時，傻眼了。
反射真的存在效能問題嗎？
為了放大問題，找到共性，採用逐漸擴大測試次數、每次測試多次取平均值的方式，針對同一個方法分別就直接呼叫該方法、反射呼叫該方法、直接呼叫該方法對應的例項、反射呼叫該方法對應的例項分別從1-1000000，每隔一個數量級測試一次：
測試程式碼如下（Person、ICompany、ProgramMonkey這三個類已在之前的文章中貼出）：
public
class
ReflectionPerformanceActivity
extends
Activity{
private TextView mExecuteResultTxtView =
null;
private EditText mExecuteCountEditTxt =
null;
private Executor mPerformanceExecutor = Executors.newSingleThreadExecutor();
private
static
final
int AVERAGE_COUNT =
10;
@Override
protected
void
onCreate
(Bundle savedInstanceState){
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_reflection_performance_layout);
mExecuteResultTxtView = (TextView)findViewById(R.id.executeResultTxtId);
mExecuteCountEditTxt = (EditText)findViewById(R.id.executeCountEditTxtId);
}
public
void
onClick
(View v){
switch(v.getId()){
case R.id.executeBtnId:{
execute();
}
break;
default:{
}
break;
}
}
private
void
execute
(){
mExecuteResultTxtView.setText(
"");
mPerformanceExecutor.execute(
new Runnable(){
@Override
public
void
run
(){
long costTime =
0;
int executeCount = Integer.parseInt(mExecuteCountEditTxt.getText().toString());
long reflectMethodCostTime=
0,normalMethodCostTime=
0,reflectFieldCostTime=
0,normalFieldCostTime=
0;
updateResultTextView(executeCount +
"毫秒耗時情況測試");
for(
int index =
0; index < AVERAGE_COUNT; index++){
updateResultTextView(
"第 " + (index+
1) +
" 次");
costTime = getNormalCallCostTime(executeCount);
reflectMethodCostTime += costTime;
updateResultTextView(
"執行直接呼叫方法耗時：" + costTime +
" 毫秒");
costTime = getReflectCallMethodCostTime(executeCount);
normalMethodCostTime += costTime;
updateResultTextView(
"執行反射呼叫方法耗時：" + costTime +
" 毫秒");
costTime = getNormalFieldCostTime(executeCount);
reflectFieldCostTime += costTime;
updateResultTextView(
"執行普通呼叫例項耗時：" + costTime +
" 毫秒");
costTime = getReflectCallFieldCostTime(executeCount);
normalFieldCostTime += costTime;
updateResultTextView(
"執行反射呼叫例項耗時：" + costTime +
" 毫秒");
}
updateResultTextView(
"執行直接呼叫方法平均耗時：" + reflectMethodCostTime/AVERAGE_COUNT +
" 毫秒");
updateResultTextView(
"執行反射呼叫方法平均耗時：" + normalMethodCostTime/AVERAGE_COUNT +
" 毫秒");
updateResultTextView(
"執行普通呼叫例項平均耗時：" + reflectFieldCostTime/AVERAGE_COUNT +
" 毫秒");
updateResultTextView(
"執行反射呼叫例項平均耗時：" + normalFieldCostTime/AVERAGE_COUNT +
" 毫秒");
}
});
}
private
long
getReflectCallMethodCostTime
(
int count){
long startTime = System.currentTimeMillis();
for(
int index =
0 ; index < count; index++){
ProgramMonkey programMonkey =
new ProgramMonkey(
"小明",
"男",
12);
try{
Method setmLanguageMethod = programMonkey.getClass().getMethod(
"setmLanguage", String
.
class);
setmLanguageMethod.setAccessible(
true);
setmLanguageMethod.invoke(programMonkey,
"Java");
}
catch(IllegalAccessException e){
e.printStackTrace();
}
catch(InvocationTargetException e){
e.printStackTrace();
}
catch(NoSuchMethodException e){
e.printStackTrace();
}
}
return System.currentTimeMillis()-startTime;
}
private
long
getReflectCallFieldCostTime
(
int count){
long startTime = System.currentTimeMillis();
for(
int index =
0 ; index < count; index++){
ProgramMonkey programMonkey =
new ProgramMonkey(
"小明",
"男",
12);
try{
Field ageField = programMonkey.getClass().getDeclaredField(
"mLanguage");
ageField.set(programMonkey,
"Java");
}
catch(NoSuchFieldException e){
e.printStackTrace();
}
catch(IllegalAccessException e){
e.printStackTrace();
}
}
return System.currentTimeMillis()-startTime;
}
private
long
getNormalCallCostTime
(
int count){
long startTime = System.currentTimeMillis();
for(
int index =
0 ; index < count; index++){
ProgramMonkey programMonkey =
new ProgramMonkey(
"小明",
"男",
12);
programMonkey.setmLanguage(
"Java");
}
return System.currentTimeMillis()-startTime;
}
private
long
getNormalFieldCostTime
(
int count){
long startTime = System.currentTimeMillis();
for(
int index =
0 ; index < count; index++){
ProgramMonkey programMonkey =
new ProgramMonkey(
"小明",
"男",
12);
programMonkey.mLanguage =
"Java";
}
return System.currentTimeMillis()-startTime;
}
private
void
updateResultTextView
(
final String content){
ReflectionPerformanceActivity.
this.runOnUiThread(
new Runnable(){
@Override
public
void
run
(){
mExecuteResultTxtView.append(content);
mExecuteResultTxtView.append(
"\n");
}
});
}
}
測試結果如下：
反射效能測試結果 如遇圖片載入失敗，可嘗試使用手機流量訪問
測試結論：
-
反射的確會導致效能問題； -
反射導致的效能問題是否嚴重跟使用的次數有關係，如果控制在100次以內，基本上沒什麼差別，如果呼叫次數超過了100次，效能差異會很明顯； -
四種訪問方式，直接訪問例項的方式效率最高；其次是直接呼叫方法的方式，耗時約為直接呼叫例項的1.4倍；接著是透過反射訪問例項的方式，耗時約為直接訪問例項的3.75倍；最慢的是透過反射訪問方法的方式，耗時約為直接訪問例項的6.2倍；
反射到底慢在哪？
跟蹤原始碼可以發現，四個方法中都存在例項化ProgramMonkey的程式碼，所以可以排除是這句話導致的不同呼叫方式產生的效能差異；透過反射呼叫方法中呼叫了setAccessible方法，但該方法純粹只是設定屬性值，不會產生明顯的效能差異；所以最有可能產生效能差異的只有getMethod和getDeclaredField、invoke和set方法了，下面分別就這兩組方法進行測試，找到具體慢在哪？
首先測試invoke和set方法，修改getReflectCallMethodCostTime和getReflectCallFieldCostTime方法的程式碼如下：
private
long
getReflectCallMethodCostTime
(
int count){
long startTime = System.currentTimeMillis();
ProgramMonkey programMonkey =
new ProgramMonkey(
"小明",
"男",
12);
Method setmLanguageMethod =
null;
try{
setmLanguageMethod = programMonkey.getClass().getMethod(
"setmLanguage", String
.
class);
setmLanguageMethod.setAccessible(
true);
}
catch(NoSuchMethodException e){
e.printStackTrace();
}
for(
int index =
0 ; index < count; index++){
try{
setmLanguageMethod.invoke(programMonkey,
"Java");
}
catch(IllegalAccessException e){
e.printStackTrace();
}
catch(InvocationTargetException e){
e.printStackTrace();
}
}
return System.currentTimeMillis()-startTime;
}
private
long
getReflectCallFieldCostTime
(
int count){
long startTime = System.currentTimeMillis();
ProgramMonkey programMonkey =
new ProgramMonkey(
"小明",
"男",
12);
Field ageField =
null;
try{
ageField = programMonkey.getClass().getDeclaredField(
"mLanguage");
}
catch(NoSuchFieldException e){
e.printStackTrace();
}
for(
int index =
0 ; index < count; index++){
try{
ageField.set(programMonkey,
"Java");
}
catch(IllegalAccessException e){
e.printStackTrace();
}
}
return System.currentTimeMillis()-startTime;
}
沿用上面的測試方法，測試結果如下：
invoke和set 如遇圖片載入失敗，可嘗試使用手機流量訪問
修改getReflectCallMethodCostTime和getReflectCallFieldCostTime方法的程式碼如下，對getMethod和getDeclaredField進行測試：
private
long
getReflectCallMethodCostTime
(
int count){
long startTime = System.currentTimeMillis();
ProgramMonkey programMonkey =
new ProgramMonkey(
"小明",
"男",
12);
for(
int index =
0 ; index < count; index++){
try{
Method setmLanguageMethod = programMonkey.getClass().getMethod(
"setmLanguage", String
.
class);
}
catch(NoSuchMethodException e){
e.printStackTrace();
}
}
return System.currentTimeMillis()-startTime;
}
private
long
getReflectCallFieldCostTime
(
int count){
long startTime = System.currentTimeMillis();
ProgramMonkey programMonkey =
new ProgramMonkey(
"小明",
"男",
12);
for(
int index =
0 ; index < count; index++){
try{
Field ageField = programMonkey.getClass().getDeclaredField(
"mLanguage");
}
catch(NoSuchFieldException e){
e.printStackTrace();
}
}
return System.currentTimeMillis()-startTime;
}
沿用上面的測試方法，測試結果如下：
getMethod和getDeclaredField 如遇圖片載入失敗，可嘗試使用手機流量訪問
測試結論：
-
getMethod和getDeclaredField方法會比invoke和set方法耗時； -
隨著測試數量級越大，效能差異的比例越趨於穩定；
由於測試的這四個方法最終呼叫的都是native方法，無法進一步跟蹤。個人猜測應該是和在程式執行時操作class有關，比如需要判斷是否安全？是否允許這樣操作？入參是否正確？是否能夠在虛擬機器中找到需要反射的類？主要是這一系列判斷條件導致了反射耗時；也有可能是因為呼叫natvie方法，需要使用JNI介面，導致了效能問題（參照Log.java、System.out.println，都是呼叫native方法，重複呼叫多次耗時很明顯）。
如果避免反射導致的效能問題？
透過上面的測試可以看出，過多地使用反射，的確會存在效能問題，但如果使用得當，所謂反射導致效能問題也就不是問題了，關於反射對效能的影響，參照下面的使用原則，並不會有什麼明顯的問題：
-
不要過於頻繁地使用反射，大量地使用反射會帶來效能問題； -
透過反射直接訪問例項會比訪問方法快很多，所以應該優先採用訪問例項的方式。
後記
上面的測試並不全面，但在一定程度上能夠反映出反射的確會導致效能問題，也能夠大概知道是哪個地方導致的問題。如果後面有必要進一步測試，我會從下面幾個方面作進一步測試：
-
測試頻繁呼叫native方法是否會有明顯的效能問題； -
測試同一個方法內，過多的條件判斷是否會有明顯的效能問題； -
測試類的複雜程度是否會對反射的效能有明顯影響。
來源：jianshu.com/p/4e2b49fa8ba1
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70035356/viewspace-2996040/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- Java反射到底慢在哪？Java反射
- Redis到底快在哪裡Redis
- 為什麼 .NET 的反射這麼慢？反射
- 檢視等待事件慢在哪個object上事件Object
- Java的慢和穩Java
- MVVM 到底比 MVC 好在哪裡？MVVMMVC
- 程式設計到底難在哪裡？程式設計
- script標籤到底該放在哪裡
- 中國做3A遊戲到底難在哪裡？遊戲
- WSL裡Nginx+PHP，經常反映慢，卡住NginxPHP
- 大資料中臺之Kafka，到底好在哪裡？大資料Kafka
- 高階程式設計師到底強在哪裡？程式設計師
- 好的程式設計師到底好在哪裡？程式設計師
- 自媒體盈利模式到底在哪裡？模式
- 基於雲的CRM系統到底好在哪裡？
- SQL：我為什麼慢你心裡沒數嗎？SQL
- MySQL 慢查詢日誌——讓“慢”無所遁形MySql
- 網站速度慢，網站速度慢，網站速度慢的幾種原因分析網站
- 同樣是搞Java，年薪15W和50W的到底差在哪裡？Java
- Java 17的計算速度比Java 8慢? - marianJava
- 初級還是高階開發者，到底區別在哪裡？
- Java中的反射到底是個啥？Java反射
- Web前端慢加密Web前端加密
- MySQL 慢查詢MySql
- MySQL慢查詢MySql
- Redis 慢查詢Redis
- redis慢日誌Redis
- solaris 9 ftp 慢FTP
- truncate 比 delete 慢delete
- truncate操作巨慢
- Git hub載入慢？下載慢？瀏覽慢？幾個小技巧讓你一鍵起飛！Git
- 解決weblogic啟動慢和建立域慢的方法Web
- HTTPS和HTTP有什麼區別，到底安全在哪裡？HTTP
- 阿里開源的32B大模型到底強在哪裡？阿里大模型
- java動態代理動態在哪裡？Java
- PHP慢指令碼日誌和Mysql的慢查詢日誌PHP指令碼MySql
- mongodb慢查詢分析MongoDB
- 慢Sql優化思路SQL優化