每篇一句
胡適:多談些問題,少聊些主義
前言
Spring MVC
和MyBatis
作為當下最為流行的兩個框架,大家平時開發中都在用。如果你往深了一步去思考,你應該會有這樣的疑問:
- 在使用
Spring MVC
的時候,你即使不使用注解,只要參數名和請求參數的key對應上了,就能自動完成數值的封裝 - 在使用
MyBatis
(接口模式)時,接口方法向xml里的SQL語句傳參時,必須(當然不是100%的必須,特殊情況此處不做考慮)
使用@Param('')
指定key值,在SQL中才可以取到
我敢相信這絕不是我一個人的疑問,因為我在第一次使用MyBatis
的時候就產生過這個疑問並且也嘗試過去掉@Param
注解,因為我覺得一個名稱讓我寫兩次是有點多此一舉的(我太懶了)。
和Spring MVC
人性化處理比起來,當時覺得MyBatis
對這塊的處理簡直弱爆了。費解了這么長時間,今天我終於可以解釋這個現象了,來揭開它的面紗~
問題發現
java
使用者都知道,.java
文件屬於源碼文件,它需要經過了javac
編譯器編譯為.class
字節碼文件才能被JVM
執行的。
對.class
字節碼稍微有點了解的小伙伴應該也知道這一點:Java
在編譯的時候對於方法,默認是不會
保留方法參數名,因此如果我們在運行期想從.class
字節碼里直接拿到方法的參數名是做不到的。
如下案例,很明顯就是獲取不到真實參數名嘍:
public static void main(String[] args) throws NoSuchMethodException {
Method method = Main.class.getMethod("test1", String.class, Integer.class);
int parameterCount = method.getParameterCount();
Parameter[] parameters = method.getParameters();
// 打印輸出:
System.out.println("方法參數總數:" + parameterCount);
Arrays.stream(parameters).forEach(p -> System.out.println(p.getType() + "----" + p.getName()));
}
打印內容:
方法參數總數:2
class java.lang.String----arg0
class java.lang.Integer----arg1
從結果中可以看到我們並不能獲取到真實方法參數名(獲取到的是無意義的arg0、arg1
等),這個結果符合我們的理論知識以及預期。
若你有一定技術敏感性,這個時候你應該有這樣的疑問:在使用Spring MVC
的時候,Controller
的方法中不使用注解一樣可以自動封裝啊,形如這樣:
@GetMapping("/test")
public Object test(String name, Integer age) {
String value = name + "---" + age;
System.out.println(value);
return value;
}
請求:/test?name=fsx&age=18
。控制台輸出:
fsx---18
從結果中可見:看似辦不到的case,Spring MVC
竟然給做到了(獲取到了方法參數名,進而完成封裝),是不是有點不可思議???
再看此例(還原Spring MVC獲取參數名的場景):
public static void main(String[] args) throws NoSuchMethodException {
Method method = Main.class.getMethod("test1", String.class, Integer.class);
MethodParameter nameParameter = new MethodParameter(method, 0);
MethodParameter ageParameter = new MethodParameter(method, 1);
// 打印輸出:
// 使用Parameter輸出
Parameter nameOriginParameter = nameParameter.getParameter();
Parameter ageOriginParameter = ageParameter.getParameter();
System.out.println("===================源生Parameter結果=====================");
System.out.println(nameOriginParameter.getType() + "----" + nameOriginParameter.getName());
System.out.println(ageOriginParameter.getType() + "----" + ageOriginParameter.getName());
System.out.println("===================MethodParameter結果=====================");
System.out.println(nameParameter.getParameterType() + "----" + nameParameter.getParameterName());
System.out.println(ageParameter.getParameterType() + "----" + ageParameter.getParameterName());
System.out.println("==============設置上ParameterNameDiscoverer后MethodParameter結果===============");
ParameterNameDiscoverer parameterNameDiscoverer = new DefaultParameterNameDiscoverer();
nameParameter.initParameterNameDiscovery(parameterNameDiscoverer);
ageParameter.initParameterNameDiscovery(parameterNameDiscoverer);
System.out.println(nameParameter.getParameterType() + "----" + nameParameter.getParameterName());
System.out.println(ageParameter.getParameterType() + "----" + ageParameter.getParameterName());
}
輸出結果:
===================源生Parameter結果=====================
class java.lang.String----arg0
class java.lang.Integer----arg1
===================MethodParameter結果=====================
class java.lang.String----null
class java.lang.Integer----null
==============設置上ParameterNameDiscoverer后MethodParameter結果===============
class java.lang.String----name
class java.lang.Integer----age
從結果能看出來:Spring MVC
借助ParameterNameDiscoverer
完成了方法參數名的獲取,進而完成數據封裝。關於ParameterNameDiscoverer
它的講解,可先行參閱:【小家Spring】Spring標准處理組件大合集(ParameterNameDiscoverer、AutowireCandidateResolver、ResolvableType。。。)
該問介紹了ParameterNameDiscoverer
的基本使用和提供的能力,但並沒有深入分析。那么本文就分析為何Spring MVC
為何可以正確的解析到方法參數名稱這個問題,從字節碼角度深入分析其緣由~
為了便於理解,先簡單說說字節碼中的兩個概念:LocalVariableTable
和LineNumberTable
。它哥倆經常被拿出來一起說,當然本文關注的焦點是LocalVariableTable
,但也借此機會一筆帶過LineNumberTable
。
LineNumberTable
你是否曾經疑問過:線上程序拋出異常時顯示的行號,為啥就恰好就是你源碼的那一行呢?有這疑問是因為JVM
執行的是.class
文件,而該文件的行和.java
源文件的行肯定是對應不上的,為何行號卻能在.java
文件里對應上?
這就是LineNumberTable
它的作用了:LineNumberTable屬性存在於代碼(字節碼)屬性中, 它建立了字節碼偏移量到源代碼行號之間的聯系
LocalVariableTable
LocalVariableTable
屬性建立了方法中的局部變量與源代碼中的局部變量之間的對應關系。這個屬性也是存在於代碼(字節碼)中~
從名字可以看出來:它是局部變量
的一個集合。描述了局部變量和描述符以及和源代碼的對應關系。
下面我使用javac
和javap
命令來演示一下這個情況:
.java
源碼如下:
package com.fsx.maintest;
public class MainTest2 {
public String testArgName(String name,Integer age){
return null;
}
}
說明:源碼我都是頂頭寫的,所以請注意行號~
使用javac MainTest2.java
編譯成.class
字節碼,然后使用javap -verbose MainTest2.class
查看該字節碼信息如下:
從圖中可看到,我紅色標注出的行號和源碼處完全一樣,這就解答了我們上面的行號對應的疑問了:LineNumberTable
它記錄着在源代碼處的行號。
Tips:此處並沒有,並沒有,並沒有LocalVariableTable
。
源碼不變,我使用javac -g MainTest2.java
來編譯,再看看對應的字節碼信息如下(注意和上面的區別):
這里多了一個LocalVariableTable
,即局部變量表,就記錄着我們方法入參的形參名字。既然記錄着了,這樣我們就可以通過分析字節碼信息來得到這個名稱了~
說明:javac的調試選項主要包含了三個子選項:
lines,source,vars
如果不使用-g來編譯,只保留源文件和行號信息;如果使用-g來編譯那就都有了~
和-parameters
有什么區別??
知道-g
編譯參數的少,反倒對Java8
新推出的-parameters
知道的人更多一些。那么它和-g
參數有什么區別呢???
百聞不如一見,我比較喜歡自己搞個例子來說明問題,.java
源代碼如下:
import java.lang.reflect.Method;
import java.lang.reflect.Parameter;
public class MainTest2 {
public static void main(String[] args) throws NoSuchMethodException {
Method method = MainTest2.class.getMethod("testArgName", String.class, Integer.class);
System.out.println("paramCount:" + method.getParameterCount());
for (Parameter parameter : method.getParameters()) {
System.out.println(parameter.getType().getName() + "-->" + parameter.getName());
}
}
public String testArgName(String name, Integer age) {
return null;
}
}
下面分別用javac、javac -g、javac -parameters
來編譯后再執行,結果圖如下:
從分別編譯、再運行打印的結果圖中看,結果以及他們的區別已經很清晰了,我就不再筆墨,有疑問的可以給我留言。
另外附上-parameters
編譯后的字節碼信息,方便你做分析對比:
獲取方法參數名的3種方式介紹
雖然Java編譯器默認情況下會抹去方法的參數名,但有上面介紹了字節碼的相關知識可知,我們還是有方法來得到方法的參數名的。下面介紹3個方案,供以參考。
方法一:使用-parameters
最為簡單直接的方式,Java8
源生支持:直接從java.lang.reflect.Parameter
就能獲取到,形如這樣:
public class MainTest2 {
public static void main(String[] args) throws NoSuchMethodException {
Method method = MainTest2.class.getMethod("testArgName", String.class, Integer.class);
System.out.println("paramCount:" + method.getParameterCount());
for (Parameter parameter : method.getParameters()) {
System.out.println(parameter.getType().getName() + "-->" + parameter.getName());
}
}
public String testArgName(String name, Integer age) {
return null;
}
}
輸出:
paramCount:2
java.lang.String-->name
java.lang.Integer-->age
當然,它有兩個最大的弊端:
- 必須Java8或以上(由於java8已經普及率非常高了,所以這個還好)
- 編譯參數必須有
-parameters
(由於依賴編譯參數,所以對遷移是不太友好的,這點比較致命)
指定-parameters
編譯參數的方式:
- 手動命令方式編譯:
javac -parameters XXX.java
- IDE(以Idea為例)編譯:
- Maven編譯:通過編譯插件指定,保證項目遷移的正確性(推薦)
<!-- 編譯環境在1.8編譯 且附加編譯參數:-parameters-->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<compilerArgs>
<arg>-parameters</arg>
</compilerArgs>
<source>${java.version}</source>
<target>${java.version}</target>
<compilerVersion>${java.version}</compilerVersion>
<encoding>${project.build.sourceEncoding}</encoding>
</configuration>
</plugin>
優點:簡單方便
缺點:需要特別的指定-parameters
,不太方便(當然使用maven編輯插件來指定是相對靠譜的方案且推薦使用)
方案二:使用-g
+ javap
命令
如上例子可以使用javac -g
編譯后,再使用javap
獲取到字節碼信息,然后自己根據信息的格式把參數名提取出來(自己做、自己做、自己做)
這無異於讓你自己解析http協議一般,你願意做嗎???所以此辦法雖為一種辦法,但是顯然不便采用
方案三:借助ASM
(推薦)
說到ASM
,小伙伴們至少對這個名字應該是不陌生的。它是一個Java
字節碼操控框架,它能被用來動態生成類或者增強既有類的功能,它能夠改變類行為,分析類信息,甚至能夠根據用戶要求生成新類。
對於ASM
來說,Java class
被描述為一棵樹;使用 “Visitor”模式(導游模式)遍歷整個二進制結構;事件驅動的處理方式使得用戶只需要關注於對其編程有意義的部分(比如本文只關注方法參數,其它的不關心),而不必了解 Java 類文件格式的所有細節。
ASM方式,它仍舊還是基於編譯后的字節碼做事的,正所謂巧婦難為無米之炊,所以它仍舊必須依賴於編譯時的LocalVariableTable
(-g 參數)。
你可能會發問:我使用idea編譯/maven編譯都沒有自己去指定-g參數啊,為什么也好使呢?你的疑問同樣也是我的疑問,我至今也還沒弄清楚更根本的原因,但是我可以說如下兩個現象:
- idea默認使用的是javac編譯器,編譯出來的字節碼是帶有
LocalVariableTable
的。但你也可以關閉它,如下圖:
- maven默認使用的也是javac編譯,字節碼也帶有
LocalVariableTable
(但是maven編譯時候的編譯命令、參數等,我無法獲知。懇請精通maven的同學指點~)
小插曲:關於代理的科普(Proxy、CGLIB、Javassist、ASM ):
ASM
:Java
字節碼開源操控框架。操縱的級別是底層JVM的匯編指令級別,這就要求使用者對class組織結構和JVM匯編指令有一定的了解,要求頗高。Javassist
:效果同上。相較於ASM
它的特點是操作簡單,並且速度還可以(當然沒有ASM快)。重要的是:它並不要求你了解JVM指令/匯編指令~Proxy
動態代理:動態生成(非提前編譯好)代理類:$Proxy0 extends Proxy implements MyInterface{ ... }
,這就決定了它只能對接口(或者實現接口的類)進行代理,單繼承機制也決定了它不能對(抽象)類進行代理~CGLIB
:是一個基於ASM的強大的,高性能,高質量的字節碼生成庫。它可以在運行期擴展Java類與實現Java接口。
Spring AOP
以及Hibernate
對代理對象的創建中都使用了CGLIB
前面文章有介紹過了直接使用CGLIB
的API
來操作字節碼/生成代理對象,本文將簡單演示一下直接使用ASM
框架來操作的示例:
ASM使用示例
首先導入asm
依賴包:
<!-- https://mvnrepository.com/artifact/asm/asm -->
<dependency>
<groupId>asm</groupId>
<artifactId>asm</artifactId>
<version>3.3.1</version>
</dependency>
說明:asm現已升級到7.x版本了,並且GAV已變化。由於我對3.x熟悉點,所以此處我還是守舊吧~
基於ASM
提供工具方法getMethodParamNames(Method)
,獲取到任何一個Method
的入參名稱:
public class MainTest2 {
// 拿到指定的Method的入參名們(返回數組,按照順序返回)
public static String[] getMethodParamNames(Method method) throws IOException {
String methodName = method.getName();
Class<?>[] methodParameterTypes = method.getParameterTypes();
int methodParameterCount = methodParameterTypes.length;
String className = method.getDeclaringClass().getName();
boolean isStatic = Modifier.isStatic(method.getModifiers());
String[] methodParametersNames = new String[methodParameterCount];
// 使用org.objectweb.asm.ClassReader來讀取到此方法
ClassReader cr = new ClassReader(className);
ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_MAXS);
// 這一步是最紅要的,開始visitor瀏覽了
// ClassAdapter是org.objectweb.asm.ClassVisitor的子類~~~~
cr.accept(new ClassAdapter(cw) {
// 因為此處我們只關心對方法的瀏覽,因此此處只需要復寫此方法即可
@Override
public MethodVisitor visitMethod(int access, String name, String desc, String signature, String[] exceptions) {
MethodVisitor mv = super.visitMethod(access, name, desc, signature, exceptions);
final Type[] argTypes = Type.getArgumentTypes(desc);
// 只visitor方法名相同和參數類型都相同的方法~~~
if (!methodName.equals(name) || !matchTypes(argTypes, methodParameterTypes)) {
return mv;
}
// 構造一個MethodVisitor返回 重寫我們關心的方法visitLocalVariable~~~
return new MethodAdapter(mv) {
//特別注意:如果是靜態方法,第一個參數就是方法參數,非靜態方法,則第一個參數是 this ,然后才是方法的參數
@Override
public void visitLocalVariable(String name, String desc, String signature, Label start, Label end, int index) {
// 處理靜態方法與否~~
int methodParameterIndex = isStatic ? index : index - 1;
if (0 <= methodParameterIndex && methodParameterIndex < methodParameterCount) {
methodParametersNames[methodParameterIndex] = name;
}
super.visitLocalVariable(name, desc, signature, start, end, index);
}
};
}
}, 0);
return methodParametersNames;
}
/**
* 比較參數是否一致
*/
private static boolean matchTypes(Type[] types, Class<?>[] parameterTypes) {
if (types.length != parameterTypes.length) {
return false;
}
for (int i = 0; i < types.length; i++) {
if (!Type.getType(parameterTypes[i]).equals(types[i])) {
return false;
}
}
return true;
}
}
運行案例:
public class MainTest2 {
// 使用工具方法獲取Method的入參名字~~~
public static void main(String[] args) throws SecurityException, NoSuchMethodException, IOException {
Method method = MainTest2.class.getDeclaredMethod("testArgName", String.class, Integer.class);
String[] methodParamNames = getMethodParamNames(method);
// 打印輸出
System.out.println(StringUtils.arrayToCommaDelimitedString(methodParamNames));
}
private String testArgName(String name, Integer age) {
return null;
}
}
輸出:
name,age
效果復合預期,使用ASM拿到了我們期望的真實的方法參數名(沒有指定任何編譯參數哦)。使用基於ASM的方式,即使你是Java8以下的版本,都是能夠正常獲取到的,因為它並不依賴編譯參數~~~
有了這些基礎知識,那么書歸正傳,來解釋文首的疑問:
Spring MVC為何好使?
首先使用上需明確:Spring MVC
好使但它並不依賴於-parameters
參數,也不依賴於-g
這個編譯參數,因為它是借助ASM
來實現的~
spring-core
中有個ParameterNameDiscoverer
就是用來獲取參數名的,底層用的是asm解析,但是接口方法的參數名無法得到,即只能是非接口類的方法參數名可以。
從文首的例子可以看出Spring MVC
它最終依賴的是DefaultParameterNameDiscoverer
去幫忙獲取到入參名,看看這塊代碼:
// @since 4.0
public class DefaultParameterNameDiscoverer extends PrioritizedParameterNameDiscoverer {
public DefaultParameterNameDiscoverer() {
if (!GraalDetector.inImageCode()) {
if (KotlinDetector.isKotlinReflectPresent()) {
addDiscoverer(new KotlinReflectionParameterNameDiscoverer());
}
addDiscoverer(new StandardReflectionParameterNameDiscoverer());
addDiscoverer(new LocalVariableTableParameterNameDiscoverer());
}
}
}
DefaultParameterNameDiscoverer
它就是一個責任鏈模式的體現,靠它添加進來的實現類來處理,也就是這哥倆:
StandardReflectionParameterNameDiscoverer
:依賴於-parameters
才會有效(有java版本要求和編譯參數要求)
LocalVariableTableParameterNameDiscoverer
:基於ASM
實現,無版本和編譯參數要求~
備注:
Spring
使用ASM
無需額外導包,因為自給自足了:
MyBatis為何不好使?
首先使用上需要明確這一點:MyBatis
是通過接口跟SQL語句綁定然后生成代理類來實現的。
既然有了強大的ASM
,那么問題來了:難道ASM
也幫不到MyBatis
來簡化開發?
看看我給的這個例子或許你就能明白了並不能怪MyBatis
呀:
public class MainTest2 {
// 使用工具方法獲取Method的入參名字~~~
public static void main(String[] args) throws SecurityException, NoSuchMethodException, IOException {
Method method = MainTest2.class.getDeclaredMethod("testArgName", String.class, Integer.class);
String[] methodParamNames = getMethodParamNames(method);
// 打印輸出
System.out.println(StringUtils.arrayToCommaDelimitedString(methodParamNames));
}
}
// 接口方法
interface MyDemoInterface{
String testArgName(String name, Integer age);
}
輸出:
null,null
可見即使強如ASM
,也是木有辦法直接獲取到接口的形參名的。
這是可以被理解的,因為接口方法不是實際方法,它的形參名是會被實現類覆蓋的,所以接口方法的形參名意義不大~
Tips:接口上的
default
方法和static
方法的參數名是可以被正常獲取到的,有興趣的小伙伴可以自己動手試試~
至於ASM
為何對接口無效,其根本原因我展示一下字節碼一看便清楚了:
因為抽象方法沒有方法體,也就沒有局部變量,自然也就沒有局部變量表了,所以即使使用ASM
也拿不到它的變量名~
說明:在
Java8
后使用-parameter
參數即使是接口,是可以直接通過Method獲取到入參名的,這個對MyBatis
是好用的。當然為了保證兼容性,個人建議還是乖乖使用@Param注解來指定吧~
至此,我有理由相信小伙伴是和我一樣,徹底搞明白為何Spring MVC可以,但MyBatis卻不可以這個疑問了吧~~~
總結
本文深入到字節碼處分析了這個有可能也是困擾了你很久的問題(問題如題),希望為你答疑解惑了。同時也介紹了ASM
的基本用法,或許對你后續理解別的框架會有所幫助~
== 若對Spring、SpringBoot、MyBatis等源碼分析感興趣,可加我wx:fsx641385712,手動邀請你入群一起飛 ==
== 若對Spring、SpringBoot、MyBatis等源碼分析感興趣,可加我wx:fsx641385712,手動邀請你入群一起飛 ==