java反射原理簡單介紹
幾個星期前，我想讓我的代碼運行快1000倍，同時不改變復雜度，正如標題所說的，使用Java反射機制，可以讓代碼運行得更快。
首先來解釋一下為什么會首先使用反射機制。
我有一個接口（表示一個樹節(jié)點）和一個實現(xiàn)這個接口的大量類（100+）。訣竅在于，樹是異構(gòu)的，每個節(jié)點類型可以有不同數(shù)量的子節(jié)點，或者以不同的方式存儲它們。
我需要讓代碼能夠在這樣的組合樹上運行起來。簡單的方法是簡單地向接口添加一個children（）方法，并在每個節(jié)點中實現(xiàn)它。當然，這很繁瑣，也很乏味。
相反，我注意到所有的子節(jié)點都是直接的字段，或者聚集在包含節(jié)點集合的字段中。所以可以用反射的方式寫一小段代碼，這也對每一個節(jié)點都適用！
我已經(jīng)在Github上放了一個簡化版的代碼。我會把相關(guān)的部分聯(lián)系起來。
初始化代碼
這是我提出的第一版本代碼：WalkerDemoSlowest.java
它相當簡單：獲取節(jié)點類的方法，過濾掉那些不是getter的方法，然后只考慮返回節(jié)點或節(jié)點集合。調(diào)用這些方法，并在子節(jié)點上遞歸地調(diào)用walk方法。
如果我說這樣的進展很慢，有人會感到驚訝嗎？
緩存
有一個簡單的調(diào)整，可以使它更快：使用緩存方法查找。
下面是緩存版本：WalkerDemoSlow.java
這和每個實現(xiàn)節(jié)點的類都是一樣的，創(chuàng)建一個ClassData對象來緩存所有相關(guān)的getter方法，所以只需要查找一次，這會產(chǎn)生一個令人滿意的10倍加速。
LambdaMetafactory 奇跡
不幸的是，這仍然太慢了。所以我向谷歌尋求幫助，發(fā)現(xiàn)了一個很有用的StackOverflow社區(qū)。
有答案建議使用LambdaMetafactory，這是一個標準的庫類，它支持lambda語法調(diào)用。
細節(jié)在我看來有些模糊，但似乎通過使用這些工具，可以在代碼中“打開編譯器”，并優(yōu)化反射機制來進行本機調(diào)用。這就是一種假設。
這是代碼：walkerdemofast.java
現(xiàn)在，我的代碼可以做到100倍的加速。然而，在寫這篇文章的時候，想用一些代碼片段來演示這個效果，但是沒有成功。我試著給接口實現(xiàn)3個子類，并使用一些偽方法進行過濾，但還是沒有效果。第二版和第三版的代碼運行速度差不多。
我重新檢查了原來的代碼，一切看起來都很好。在原始代碼中，樹是通過解析一些源文件得到的抽象語法樹（AST）。如果限制了前14個源文件的輸入，我發(fā)現(xiàn)會得到不同的結(jié)果。
這些文件相對較短（幾乎沒有10行），語法簡單。但僅僅有這些，第二和第三版代碼仍會以同樣的速度運行。但是在第15個文件中進行輸入（少于100行），那么第二個版本的代碼會花費36秒，而第三個版本代碼會在0.2秒內(nèi)完成，這是700倍的差異。
我的假設是，如果場景足夠簡單，優(yōu)化器會注意到正在運行的代碼并選擇離開。在更復雜的情況下，它會耗盡優(yōu)化預算，然后回到未優(yōu)化的版本以及糟糕的性能狀態(tài)。但是，優(yōu)化器已經(jīng)足夠靈活，如果有一個能擊敗它的示例，那似乎是非常成功的。
LambdaMetafactory 可能性
我有點好奇LambdaMetafactory會有什么樣的可能性。在我的示例中，它會產(chǎn)生奇跡，因為反射調(diào)用比簡單的緩存查找要昂貴得多。但它是否也能對常規(guī)代碼進行優(yōu)化處理呢？這似乎不太可能讓megamorphic call sites提供幫助，因為編譯的方法必須以某種方式檢索，而查找的成本將使收益相形見絀。
但是，如何在運行組合代碼時進行優(yōu)化呢？可以提供數(shù)據(jù)結(jié)構(gòu)，或者為數(shù)據(jù)結(jié)構(gòu)提供解釋器，并使用LambdaMetafactory“編譯”它們。這是否足夠智能呢，可以對給定數(shù)據(jù)結(jié)構(gòu)的代碼進行部分評估，從而將解釋器轉(zhuǎn)換成等價的“plain”代碼？
順便說一下，這正是Truffle框架所采用的方法，它在Graal VM上運行，所以這個想法肯定有一定的意義。可能暫時無法使用當前的JVM，因此需要修改GraalVM。
在任何情況下，都會盡量使一些功能成為一個庫，可以在“常規(guī)程序”（非編譯器）中使用。編寫簡單的解釋器通常是解決一些問題的最簡單方法。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%