一旦我不顧一切地嘗試優化Class.resolveName()依賴于基準測驗的結果（在參考的 PR 中可用）復制上述方法的邏輯。優化的想法很簡單，new StringBuilder().append()用簡單的連接代替。事實證明，雖然基準測驗顯示出顯著的改進，但修補方法本身卻退步了。正如公關評論中指出的那樣
JMH 測驗可能會顯示更好的結果，因為它被編譯為位元組碼，該位元組碼使用基于特殊呼叫動態的字串連接和基于最佳 MH 的底層策略。由于引導問題，java.lang.Class 中的代碼無法編譯為使用這種連接，因此被編譯為直接使用 StringBuilder 的位元組碼（很像??修補方法的現有代碼）。
實際上，字串的連接java.base被編譯成StringBuilder基于 - 的位元組碼，這與為客戶端代碼所做的不同（它們invokedynamic與 一起使用StringConcatFactory）。
我已經調查了那些“引導問題”，但我發現的唯一一件事是關于類加載的順序。如果一個運行java -Xlog:class init -version它變得很明顯，StringConcatFactory加載遠在j.l.Class. 同時，j.l.Class在它之后加載的還有許多其他類。
所以我的問題是為什么javac可以使用 eg StringBuilderwithin Class.resolveName()，但不能StringConcatFactory？這門課有什么特別之處？
或者也許我的猜測是錯誤的，引導問題與StringConcatFactoryand無關invokedynamic？
uj5u.com熱心網友回復：
這里的“引導問題”是先有雞還是先有蛋的問題。
StringConcatFactory依賴于 JSR 292 機制，而后者又使用java.base使用字串連接的類。為了解決這種回圈依賴，連接是java.base類以不依賴的老式方式編譯StringConcatFactory。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/459271.html