揭開java method的一個秘密：巨型函數(shù)

相信，很多人都不知道Java的Method的上限為64K。本文將超過這個上限的函數(shù)叫做巨型函數(shù)。

巨型函數(shù)的問題

1、如果代碼超過了這個限制，Java編譯器就報"Code too large to complier"的錯誤。 2、代碼并沒有超過64K的限制，但是在運行時由于其他工具或者library使得對應的代碼超過了64K的限制，那么Java會給我們一個java.lang.VerifyError的錯誤。

巨型函數(shù)是怎么來的

如下一些僅僅是一些可能導致出現(xiàn)巨型函數(shù)的常見情況，還有很多其他情況就不一一列舉了。

一些工具生成的代碼

很多大函數(shù)并不是人手動寫出來的，是一些代碼生成工具生成的，例如ANTLR（ANother Tool for language Recognition）就有可能生成巨大的Method。

初始化函數(shù)

Initialization方法就很容易變成巨型函數(shù)，尤其是一些GUI的初始化函數(shù)，很容易在一個代碼段中塞進去很多對應的GUI的布局定義代碼和attaching listener代碼，導致巨型函數(shù)的產(chǎn)生。

數(shù)組初始化

測者在工作中也遇見過static final 數(shù)組編譯器使用load或者sotre的指令初始化數(shù)組。這有時候也會導致出現(xiàn)巨型函數(shù)。

很長的JSP頁面

很多JSP的編譯器也會將所有的JSP代碼編譯到一個函數(shù)中，導致巨型函數(shù)的出現(xiàn)。

如何解決巨型函數(shù)的問題

最好也是最根本的解決巨型函數(shù)的方法就是拆分。無論是代碼生成工具還是JSP都允許我們進行代碼的拆分。但是其他一些例如調(diào)用第三方工具或者library導致的這個問題，很多時候就不能通過粗暴的代碼拆分解決問題了，需要重新設計，優(yōu)化算法等方式避免巨型函數(shù)的出現(xiàn)。也有很多時候我們沒有辦法避免巨型函數(shù)的64K限制，我們最終的根本方法還是寄希望于Java自身接觸64K的限制。

關注測者，關注測試