論java如何通過反射獲得方法真實參數名及擴展研究
前言
前段時間，在做一個小的工程時，遇到瞭需要通過反射獲得方法真實參數名的場景，在這裡我遇到瞭一些小小的問題，後來在部門老大的指導下，我解決瞭這個問題。通過解決這個問題，附帶著我瞭解到瞭很多新的知識，我覺得有必要和大傢分享交流一下。
示例
咱們先來看這樣一個小的demo：
這是一個很簡單的小demo，裡面就是一個簡簡單單的類Test1，Test1有一個包含兩個參數的方法test，在Test1的main方法中通過射來獲得test方法的所有參數的名字，並將其輸出到標準流。我本以為這個demo的運行結果會得到方法的參數名。
結果
驚不驚喜，意不意外？和說好的不一樣啊！
咱們先停一下，先把為什麼反射沒有拿到正確的值放到一邊，先說說我為什麼要研究“通過反射原理獲得方法參數的實際名稱”這件事呢：是因為我想仿照並實現Spring MVC中的“自動綁定”功能。大傢知道Spring MVC裡有一個“自動綁定”的功能，能夠自動綁定請求參數的值到@RequestMapping方法的參數上的，而不用任何額外的操作。
這個功能我覺得很方便，所以我想嘗試自己仿造這個功能，然後用在公司的項目開發中。我猜測Spring是通過反射獲得方法的參數名後根據參數名到request中getParam(String name)來獲得實際的值然後綁定的。因此我就嘗試著按照這個思路做，結果就遇到瞭上邊提到的反射獲得不瞭參數實際名稱的問題。我將這個問題請教瞭老大，老大瞭解到我的意圖後，經過驗證，得出結論：Spring MVC能不能正常使用自動綁定是與java編譯器編譯時加不加-g參數有關的，而這個-g參數是代表著java編譯器在編譯時是否會輸出調試信息。
調試
其實也就是說：Spring是通過讀取java編譯器生成的調試信息從而獲得的方法中參數的真實名稱的。說到這裡，這個問題基本也解決瞭，但是我還是想再多說一點我後續的學習結果。後續我研究瞭一下Spring對於方法參數這塊的處理邏輯，也就是對於“自動綁定”功能的底層的實現。
那麼，Spring 到底是用瞭什麼“黑科技”來做到獲得方法實際參數名的呢，咱們不妨就看Spring的源碼吧，看看Spring到底是如何實現的。
Spring源碼
Spring海量的源代碼，從何看起呢，這裡，我是這樣解決的：我大體知道這個獲得方法實際參數名的操作應當和Method的getParameters()方法有關，或者說它的方法裡或許會調用到這個方法，那麼好瞭，我們可以使用idea提供的“查看調用棧”的功能，來順藤摸瓜，看看在Spring中有沒有調用到這個方法，如果有，那麼解決方案應當就在調用方法的附近。
我們可以看到，果不其然，在調用棧裡就有org.spring包中的方法，其中有兩個方法都是StandardReflectionParameterNameDiscoverer類的方法，其實我們已經找到瞭，看這個類的名字就能知道，它是處理ParameterName的Discoverer的（在這裡我想再說點題外話，我個人非常贊同Spring這種全命名的編碼風格，看到命名就能看明白這個類是在幹什麼，所以說代碼應當是能“自描述”的）
註釋
好，我們再回到代碼中來，繼續看這個類：發現它有一段簡要的註釋：
大意就是這個類是針對使用瞭JDK8基於-parameters編譯參數的ParameterNameDiscoverer的實現，這裡這個-parameters參數是怎麼回事咱們先放一邊。
實現接口類
繼續向上看StandardReflectionParameterNameDiscoverer所實現的這個接口ParameterNameDiscoverer，打開ParameterNameDiscoverer這個接口，我們用idea的查看子類的功能，能夠看到它一共有包括StandardReflectionParameterNameDiscoverer在內的8個子類
其中有一個名字裡帶“Default”的子類DefaultParameterNameDiscoverer，按照一般套路來說，帶Default的都是默認的實現，那麼好瞭我們優先看它吧。
打開DefaultParameterNameDiscoverer，我們發現，他做的大體就是通過判斷standardReflectionAvailable這個值來走向不同分支流程：一個是走向剛才提到的利用JDK8編譯參數的StandardReflectionParameterNameDiscoverer另一個是走向瞭LocalVariableTableParameterNameDiscoverer
好，現在又出現瞭熟悉的StandardReflectionParameterNameDiscoverer瞭，那麼我們返回去看吧，一會再看另一個分支的LocalVariableTableParameterNameDiscoverer。
我們回到StandardReflectionParameterNameDiscoverer中，再來看剛才那個-parameters編譯參數，這是個什麼黑科技？既然他是個編譯參數，那麼咱們不妨試著用它編譯一下咱們的代碼試一下吧。
我們將idea設置上-parameters編譯參數從新運行剛才的demo，發現這回的輸出結果是：
已經能夠拿到參數的真實名稱瞭。那麼，這個-parameters到底是什麼呢：我們可以來看一下oracle官方提供的javac文檔：
通過文檔可以看出加上這個參數後，編譯器會生成元數據，從而使方法參數的反射能夠拿到參數的信息。
這個功能是jdk8的新特性，我們就不仔細展開瞭，詳情可以查看這兩篇文檔：
JDK 8 Features
JEP 118: Access to Parameter Names at Runtime
-parameters這個黑科技咱們已經瞭解瞭，利用這個編譯參數是可以獲得方法參數的真實名稱的，但是這個參數是jdk8之後才有的，那麼之前的版本如何獲得呢？我們繼續看Spring源代碼吧。現在我們來看另一個分支：LocalVariableTableParameterNameDiscoverer，打開這個類：
其實看註釋就明白瞭，這個LocalVariableTableParameterNameDiscoverer是通過ASM library分析LocalVariableTable來實現獲得參數實際名稱的，ASM是一個第三方的字節碼操縱庫，用這個庫可以讀取寫入class文件，這個庫有很廣泛的應用，具體的我不展開介紹瞭。
我們重點說一下這個LocalVariableTable吧，這個LocalVariableTable是什麼呢？我們不用文字來說明瞭，直接來看代碼吧：
我們這次不看源文件瞭，來直接看編譯後的class文件。
編譯後的class文件
用idea打開Test1.class：
然後在View菜單中點選Show Bytecode：
在彈出窗口中，我們可以看到，idea以大綱的方式把class文件的信息列瞭出來，而在其中就有LocalVariableTable存在，而且在“LocalVariableTable”附近我們可以看到我們定義方法的參數的真實名稱。現在我們也就明白瞭，對於8以下的jdk編譯環境，Spring是使用ASM來讀取class文件中LocalVariableTable信息從而獲得參數真實名稱的。
到此為止，我們已經基本瞭解瞭Spring中自動綁定背後的黑科技瞭。
這裡我還想繼續再多說一點，有關LocalVariableTable和Java class文件：class文件可以說是Java實現跨平臺特性的根本！不管在什麼平臺下，隻要編譯出來的class文件符合規范，虛擬機就能夠正常的執行。瞭解一下class文件的相關知識其實對於理解各類class文件操縱庫以及基於class操縱的AOP等等編程模式的原理是很有幫助的，所以我們可以瞭解一下class文件是什麼樣的結構的。想要瞭解class文件的結構，最權威的莫過於官方的《Java虛擬機規范瞭》，在Java虛擬機規范中，第四章是有關class文件結構的內容，我們可以大致過一遍。
通過閱讀，我們可以大致瞭解到class的結構：
A class file consists of a stream of 8-bit bytes. All 16-bit, 32-bit, and 64-bit
quantities are constructed by reading in two, four, and eight consecutive 8-bit
bytes, respectively. Multibyte data items are always stored in big-endian order,
where the high bytes come first. In the Java SE platform, this format is supported
by interfaces java.io.DataInput and java.io.DataOutput and classes such as
java.io.DataInputStream and java.io.DataOutputStream.
class文件結構
class文件可以用一個結構來表示：
這個結構中每一項大致的含義我們來簡單說明一下吧（詳情請查看虛擬機規范）：
開頭的magic u4叫做“魔數”，Java虛擬器通過讀取這個數來判斷當前文件是不是有效的u4代表它是無符號的4個byte，這個數始終應該是0xCAFEBABE；
minor_version、major_version分別是class文件的次版本和主版本；
u2 constant_pool_count 、cp_info constant_pool[constant_pool_count-1]代表常量池中項目數和代表瞭常量池本身；
u2 access_flags : 代表class訪問標記，例如：public protected；
u2 this_class : 代表放置類名在常量池中的索引；
u2 super_class : 代表父類名稱在常量池中的索引；
u2 interfaces_count; u2 interfaces[interfaces_count]; 代表所實現的接口集合的大小，及接口集合本身；
u2 fields_count; field_info fields[fields_count]; 代表屬性集合大小以及屬性集合本身；
u2 methods_count; method_info methods[methods_count]; 代表方法集合大小以及方法集合本身；
u2 attributes_count; attribute_info attributes[attributes_count]; java class文件內部屬性信息集合大小和內部屬性信息集合本身。這裡提一下，我們前面的提到的LocalVariableTable的信息就存儲在這裡。
總結
到瞭這裡我們大致回顧一下吧，我們從嘗試解決反射獲得方法參數真實名稱開始，瞭解瞭Java編譯參數、Spring自動綁定相關處理原理、jdk8編譯參數新特性、以及Java class文件的結構。通過這個過程，我們看到，就一個“自動綁定”這個平常都感覺不到它存在的小功能背後，還有這莫多深層次的技術在裡面，由此可見，Spring之所以如此強大而且易用，離不開各類底層技術的支持，這就讓我想起以前看到過的一位技術博主的標語：“隻有深入，方能淺出”，想想確實是這個道理。
以上就是論java如何通過反射獲得方法真實參數名及擴展研究的詳細內容，更多關於java反射獲得真實參數名的資料請關註WalkonNet其它相關文章！