用於運行時字節碼生成的許多庫（工具） ASM，Javassit，CGLIB，BCEL。所有這些工具都能夠動態地操作java字節碼，這與javac編譯器等工具不同。用於較大方法/類的運行時字節碼生成
我的理解是生成字節碼並稍後將它們加載到類加載器中。對我而言，問題是在生成可能非常大的Java方法/類的字節碼時，這些工具之間是否存在性能差異和問題。
另一個方案是應用其保持在時間運行，並且將所生成的字節碼將是微不足道的，但是連續的（應用不斷產生的字節代碼的類和裝載/卸載到類加載器連續地）
還有另一個Dynamic Java Bytecode Manipulation Framework Comparison但我還沒有得到回答。如果有些人可以提供有用的鏈接，或者形成學術/行業的調查/報告，我將不勝感激。
在運行時生成類並不比填充包含內容的字節數組更有趣。在JVM被告知將這些內容解釋爲Java類的地方，它與從硬盤驅動器加載的預編譯類被添加到運行時環境的方式沒有什麼不同。
由於填充字節數組很微不足道，所以性能取決於確定內容的規則。解析源代碼並驗證其正確性是一項昂貴的任務。另一方面，根據硬編碼規則生成代碼，例如，通過調用一個指定的方法（如lambda instantiation works）來實現一個接口，通常比從硬盤驅動器加載等效代碼的速度快得多。具有這樣的規則是運行時字節碼生成的典型用例。
但是在考慮性能之前，您應該問自己爲什麼要考慮動態字節碼生成。在大多數現實生活場景中，對這個問題的回答已經包含了對性能是否與所有相關的問題或者爲什麼預計通過生成代碼來改進的問題的答案。
在現實世界中，使用哪個框架並不重要。除非您計劃生成數百萬種新方法並在運行時加載它們，否則開始時這將是一個糟糕的主意。
我認爲ASM是最強的選擇有兩個原因。首先，它具有所有JVM特性的最新功能，其次，它的Visitor Pattern API非常高效。這個第二點解決了你的性能問題，我想。