對Java字節碼有一定了解的朋友應該知道，Java 在編譯的時候，默認不會保留方法參數名，因此我們無法在運行時獲取參數名稱。但是在使用 SpringMVC 的時候，我發現一個奇怪的現象：當我們需要接收請求參數的時候，相應的 Controller 方法只需要正常聲明，就可以直接接收正確的參數，例如：

注：以下例子使用 maven 進行編譯，且非 SpringBoot 項目，SpringBoot 已經自動解決了參數名解析的問題，后面咱們會討論@RestController@RequestMapping("calculator")public class CalculatorController { @GetMapping("add") public int add(int aNum, int bNum) { return aNum + bNum; }}

當接收到 /calculator/add?aNum=12&bNum=3 這樣的請求時，會返回 15，即aNum 和 bNum 都能被正確解析。

然而，當我們使用 MyBatis 時，如果接口方法有多個參數而且我們沒有打上 @Param 注解的話，執行的時候就會報錯。例如，我們有如下的接口：

@Mapper

public interface AccountMapper {

Account getByNameAndMobilePhone(String name, String mobilePhone);

}

方法中包含兩個參數，但是沒有打上 @Param 注解，這時候如果調用這個方法，會報錯：

org.apache.ibatis.binding.BindingException: Parameter 'name' not found.

Available parameters are [arg1, arg0, param1, param2]

從錯誤信息中可以看出，是因為 MyBatis 沒有正確解析方法參數名稱導致異常。

這就很奇怪了，為什么 Spring 可以正確解析方法參數名稱，但是 MyBatis 卻不行？Java編譯的時候默認會將方法參數名抹除，但我并沒有做特殊處理，Spring 又是從哪里找到方法參數名的呢？

帶著這些問題，我開始進行研究和探索。

# 獲取參數名的方式

通過查閱各種資料，我知道了獲取參數名稱的方式。

-g 參數

當我們對 Java 源碼進行編譯時，無論是直接使用命令行還是使用 IDE 為我們編譯，實際上最終都是調用 javac 命令進行的，在編譯的時候，我們如果添加上 -g 參數，即告訴編譯器，我們需要調試信息，這時，生成的字節碼當中就會包含局部變量表的信息(方法參數也是局部變量)，于是我們就可以通過解析字節碼獲取參數名了。

我們用最最經典的 HelloWorld 程序中的 main 方法為例，看一下編譯的效果：

public class HelloWorld{ public static void main(String[] argsName){ System.out.println("HelloWorld!"); }}

我們直接執行如下 javac 命令來編譯并使用 javap 命令查看生成的字節碼信息：

javac HelloWorld.javajavap -verbose HelloWorld.class

可以看到，我們的參數名 argsName 已經被抹掉了。而如果字節碼中都沒有我們所需要的信息，那么在運行時，反射或者是別的方法也都無能為力了，巧婦難為無米之炊吶。

接下來，我們試一下添加 -g 參數會發生什么：

javac -g HelloWorld.javajavap -verbose HelloWorld.class

可以看到，這里多了一個 LocalVariableTable，即局部變量表，其中就有我們的參數名稱 argsName！

那么，我們如何在方法運行時從字節碼信息中獲取參數名稱呢？你可以直接通過 javap 來獲取字節碼信息，然后自己去根據信息的格式去解析，然而這樣太低效了，而且太繁瑣了。

# ASM 框架

這時候如果我們請大名鼎鼎的 ASM 來當“導游”，帶著我們游覽字節碼內部構造，實現起來就輕松多了。

這個 ASM 可牛了，它不僅可以查看字節碼的信息，甚至可以動態修改類的定義或者新建一個原本沒有的類！在各種框架中被廣泛地使用，SpringAOP中使用的 CGLib 底層就是使用 ASM 來實現的。有興趣可以查看官網：https://asm.ow2.io/ 之前我也寫過一篇文章《Java用ASM寫一個HelloWorld程序》，有興趣可以看一下。

言歸正傳，如何通過 ASM 來獲取參數名稱呢？ 直接上代碼：

asm asm 3.3.1/*** 使用字節碼工具ASM來獲取方法的參數名*/public static String[] getMethodParamNames(final Method method) throws IOException { final int methodParameterCount = method.getParameterTypes().length; final String[] methodParametersNames = new String[methodParameterCount]; ClassReader cr = new ClassReader(method.getDeclaringClass().getName()); ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_MAXS); 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); //參數類型不一致 if (!method.getName().equals(name) || !matchTypes(argTypes, method.getParameterTypes())) { return mv; } return new MethodAdapter(mv) { @Override public void visitLocalVariable(String name, String desc, String signature, Label start, Label end, int index) { //如果是靜態方法，第一個參數就是方法參數，非靜態方法，則第一個參數是 this, 然后才是方法的參數 int methodParameterIndex = Modifier.isStatic(method.getModifiers()) ? 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;}

簡而言之，ASM使用了訪問者模式，它就像一個導游，帶著我們去游覽字節碼文件中的各個“景點”。我們實現不同的 Visitor 接口就像是手上握有不同景點門票，導游會帶著 ClassVisitor 去總體參觀類定義的景觀，而類內部有方法，如果你想看一下方法內部的定義，需要"額外購票"，即需要實現 MethodVisitor 才能跟著導游去參觀方法定義這個景點。而在游覽各個景點的時候，我們可以只游覽我們感興趣的部分，這就可以繼承適配器(ClassAdapter和MethodAdapter分別是ClassVisitor和MethodVisitor的適配器)然后只實現我們感興趣的方法即可。

這里對于類的定義，我們只對方法感興趣，因此只實現 visitMethod 方法；在方法中，我們只對 LocalVariableTable 有興趣，因此只實現 visitLocalVariable 方法。這樣我們得到了局部變量表，再根據一些規則就可以拿到我們的參數名稱了！是不是很棒！

順便說一下，如果你使用 maven 來管理項目的話，這個 -g 參數會在編譯的時候自動加上，因此我們不需要額外添加就可以通過字節碼拿到，這也就是為什么 SpringMVC 可以拿到方法參數名稱的原因。

但是這種方式對于接口和抽象方法是不管用的，因為抽象方法沒有方法體，也就沒有局部變量，自然也就沒有局部變量表了：

MyBatis 是通過接口跟 SQL 語句綁定然后生成代理類來實現的，因此它無法通過解析字節碼來獲取方法參數名。

end：如果你覺得本文對你有幫助的話，記得關注點贊轉發，你的支持就是我更新動力。

總結

以上是生活随笔為你收集整理的mybatis是什么_为什么SpringMVC可以正确解析方法参数名称，但MyBatis却不行？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。