幾個(gè)星期前，我想讓我的代碼運(yùn)行快1000倍，同時(shí)不改變復(fù)雜度，正如標(biāo)題所說的，使用Java反射機(jī)制，可以讓代碼運(yùn)行得更快。

　　首先來解釋一下為什么會首先使用反射機(jī)制。

　　我有一個(gè)接口（表示一個(gè)樹節(jié)點(diǎn)）和一個(gè)實(shí)現(xiàn)這個(gè)接口的大量類（100+）。訣竅在于，樹是異構(gòu)的，每個(gè)節(jié)點(diǎn)類型可以有不同數(shù)量的子節(jié)點(diǎn)，或者以不同的方式存儲它們。

　　我需要讓代碼能夠在這樣的組合樹上運(yùn)行起來。簡單的方法是簡單地向接口添加一個(gè)children（）方法，并在每個(gè)節(jié)點(diǎn)中實(shí)現(xiàn)它。當(dāng)然，這很繁瑣，也很乏味。

　　相反，我注意到所有的子節(jié)點(diǎn)都是直接的字段，或者聚集在包含節(jié)點(diǎn)集合的字段中。所以可以用反射的方式寫一小段代碼，這也對每一個(gè)節(jié)點(diǎn)都適用！

　　我已經(jīng)在Github上放了一個(gè)簡化版的代碼。我會把相關(guān)的部分聯(lián)系起來。

　　初始化代碼

　　這是我提出的第一版本代碼：WalkerDemoSlowest.java

　　它相當(dāng)簡單：獲取節(jié)點(diǎn)類的方法，過濾掉那些不是getter的方法，然后只考慮返回節(jié)點(diǎn)或節(jié)點(diǎn)集合。調(diào)用這些方法，并在子節(jié)點(diǎn)上遞歸地調(diào)用walk方法。

　　如果我說這樣的進(jìn)展很慢，有人會感到驚訝嗎？

　　緩存

　　有一個(gè)簡單的調(diào)整，可以使它更快：使用緩存方法查找。

　　下面是緩存版本：WalkerDemoSlow.java

　　這和每個(gè)實(shí)現(xiàn)節(jié)點(diǎn)的類都是一樣的，創(chuàng)建一個(gè)ClassData對象來緩存所有相關(guān)的getter方法，所以只需要查找一次，這會產(chǎn)生一個(gè)令人滿意的10倍加速。

　　LambdaMetafactory 奇跡

　　不幸的是，這仍然太慢了。所以我向谷歌尋求幫助，發(fā)現(xiàn)了一個(gè)很有用的StackOverflow社區(qū)。

　　有答案建議使用LambdaMetafactory，這是一個(gè)標(biāo)準(zhǔn)的庫類，它支持lambda語法調(diào)用。

　　細(xì)節(jié)在我看來有些模糊，但似乎通過使用這些工具，可以在代碼中“打開編譯器”，并優(yōu)化反射機(jī)制來進(jìn)行本機(jī)調(diào)用。這就是一種假設(shè)。

　　這是代碼：walkerdemofast.java

　　現(xiàn)在，我的代碼可以做到100倍的加速。然而，在寫這篇文章的時(shí)候，想用一些代碼片段來演示這個(gè)效果，但是沒有成功。我試著給接口實(shí)現(xiàn)3個(gè)子類，并使用一些偽方法進(jìn)行過濾，但還是沒有效果。第二版和第三版的代碼運(yùn)行速度差不多。

　　我重新檢查了原來的代碼，一切看起來都很好。在原始代碼中，樹是通過解析一些源文件得到的抽象語法樹（AST）。如果限制了前14個(gè)源文件的輸入，我發(fā)現(xiàn)會得到不同的結(jié)果。

　　這些文件相對較短（幾乎沒有10行），語法簡單。但僅僅有這些，第二和第三版代碼仍會以同樣的速度運(yùn)行。但是在第15個(gè)文件中進(jìn)行輸入（少于100行），那么第二個(gè)版本的代碼會花費(fèi)36秒，而第三個(gè)版本代碼會在0.2秒內(nèi)完成，這是700倍的差異。

　　我的假設(shè)是，如果場景足夠簡單，優(yōu)化器會注意到正在運(yùn)行的代碼并選擇離開。在更復(fù)雜的情況下，它會耗盡優(yōu)化預(yù)算，然后回到未優(yōu)化的版本以及糟糕的性能狀態(tài)。但是，優(yōu)化器已經(jīng)足夠靈活，如果有一個(gè)能擊敗它的示例，那似乎是非常成功的。

　　LambdaMetafactory 可能性

　　我有點(diǎn)好奇LambdaMetafactory會有什么樣的可能性。在我的示例中，它會產(chǎn)生奇跡，因?yàn)榉瓷湔{(diào)用比簡單的緩存查找要昂貴得多。但它是否也能對常規(guī)代碼進(jìn)行優(yōu)化處理呢？這似乎不太可能讓megamorphic call sites提供幫助，因?yàn)榫幾g的方法必須以某種方式檢索，而查找的成本將使收益相形見絀。

　　但是，如何在運(yùn)行組合代碼時(shí)進(jìn)行優(yōu)化呢？可以提供數(shù)據(jù)結(jié)構(gòu)，或者為數(shù)據(jù)結(jié)構(gòu)提供解釋器，并使用LambdaMetafactory“編譯”它們。這是否足夠智能呢，可以對給定數(shù)據(jù)結(jié)構(gòu)的代碼進(jìn)行部分評估，從而將解釋器轉(zhuǎn)換成等價(jià)的“plain”代碼？

　　順便說一下，這正是Truffle框架所采用的方法，它在Graal VM上運(yùn)行，所以這個(gè)想法肯定有一定的意義。可能暫時(shí)無法使用當(dāng)前的JVM，因此需要修改GraalVM。

　　在任何情況下，都會盡量使一些功能成為一個(gè)庫，可以在“常規(guī)程序”（非編譯器）中使用。編寫簡單的解釋器通常是解決一些問題的最簡單方法。

相關(guān)電子資料下載

• 一文詳解ZGC關(guān)鍵技術(shù) 26
• SpringBoot物理線程、虛擬線程、Webflux性能比較 37
• Rust語言為什么這么卷？ 21
• 什么是分布式鎖 Redis的五種分布式鎖方案 32
• Guava中這些Map的操作，讓我的代碼量減少了50% 70
• java實(shí)現(xiàn)定時(shí)器的四種方式 83
• 基于OkHttp 3.10.0的源碼案例解析 26
• 如何用Rust通過JNI和Java進(jìn)行交互 120
• JVM指針壓縮的工作原理 66
• 什么是SQL注入？Java項(xiàng)目防止SQL注入方式 37