大家知道,Spring MVC 有一項非常實用的功能,叫參數綁定。其具體能實現的功能異常強大,這裏不再贅述,網上有非常多的資料可供參考,僅舉一例用以描述問題。
@RestController
public class FooController {
@GetMapping("/methodOne")
public Boolean methodOne(Integer filedOne, String fieldTwo) {
System.out.println(filedOne);
System.out.println(fieldTwo);
return Boolean.TRUE;
}
}
這是一種很常見的使用姿勢 - GET請求,有兩個參數,分別爲filedOne(Integer),fieldTwo(String)。
先前一直都知道Spring MVC 有參數綁定功能,也一直心安理得去使用,把結論當成必然去記,一直未曾探究其原理。其實,我好奇的並非Spring MVC完成參數綁定的過程,而是好奇,Spring如何獲取到方法的形參名,並完成屬性注入?
難道大家沒有這樣的疑問?在Java 8及之後,編譯的時候可以通過-parameters
爲反射生成元信息,可以獲取到方法的參數名,但這個行爲默認是關閉的,且更靠前的Java 6 Java 7呢,甚至沒有這個參數,因此應該不是通過反射獲取參數名。既然反射走不通,那Spring又是使用了哪種奇淫技巧來獲取方法的參數名呢?帶着這個問題一起來看源碼。
注:下面的源碼分析基於Spring 4.3.17
假設我們請求 GET http://localhost:8080/methodOne?fieldTwo=jack,
即請求methodOne,參數名爲fieldTwo,參數值爲jack,接下來就看看Spring MVC是怎麼處理的。
一個Spring MVC的應用,當有一個Web請求的進來的時候,我們一般從org.springframework.web.servlet.DispatcherServlet#doDispatch
開始分析
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
...(省略)
// Determine handler for the current request.
mappedHandler = getHandler(processedRequest);
...(省略)
// Determine handler adapter for the current request.
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
...(省略)
// Actually invoke the handler.
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
...(省略)
}
我們重點看mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
,調用HandlerAdapter的handle方法,實際上會進入到org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter#handleInternal
@Override
protected ModelAndView handleInternal(HttpServletRequest request,
HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {
ModelAndView mav;
checkRequest(request);
// Execute invokeHandlerMethod in synchronized block if required.
if (this.synchronizeOnSession) {
HttpSession session = request.getSession(false);
if (session != null) {
Object mutex = WebUtils.getSessionMutex(session);
synchronized (mutex) {
mav = invokeHandlerMethod(request, response, handlerMethod);
}
}
else {
// No HttpSession available -> no mutex necessary
mav = invokeHandlerMethod(request, response, handlerMethod);
}
}
else {
// No synchronization on session demanded at all...
mav = invokeHandlerMethod(request, response, handlerMethod);
}
...(省略)
}
synchronizeOnSession默認爲false,不用管,因此會走到else的分支,即mav = invokeHandlerMethod(request, response, handlerMethod);
protected ModelAndView invokeHandlerMethod(HttpServletRequest request,
HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {
ServletWebRequest webRequest = new ServletWebRequest(request, response);
try {
WebDataBinderFactory binderFactory = getDataBinderFactory(handlerMethod);
ModelFactory modelFactory = getModelFactory(handlerMethod, binderFactory);
ServletInvocableHandlerMethod invocableMethod = createInvocableHandlerMethod(handlerMethod);
invocableMethod.setHandlerMethodArgumentResolvers(this.argumentResolvers);
invocableMethod.setHandlerMethodReturnValueHandlers(this.returnValueHandlers);
invocableMethod.setDataBinderFactory(binderFactory);
invocableMethod.setParameterNameDiscoverer(this.parameterNameDiscoverer);
...(省略)
invocableMethod.invokeAndHandle(webRequest, mavContainer);
...(省略)
}
將handlerMethod包裝成ServletInvocableHandlerMethod,並設置argumentResolvers、returnValueHandlers、binderFactory、parameterNameDiscoverer。其中,argumentResolvers需要重點關注,因爲它是用來做參數解析的。接下來看invocableMethod.invokeAndHandle(webRequest, mavContainer);
public void invokeAndHandle(ServletWebRequest webRequest, ModelAndViewContainer mavContainer,
Object... providedArgs) throws Exception {
Object returnValue = invokeForRequest(webRequest, mavContainer, providedArgs);
...(省略)
}
即將進入重要方法getMethodArgumentValues
private Object[] getMethodArgumentValues(NativeWebRequest request, ModelAndViewContainer mavContainer,
Object... providedArgs) throws Exception {
MethodParameter[] parameters = getMethodParameters();//獲取方法參數
Object[] args = new Object[parameters.length];
for (int i = 0; i < parameters.length; i++) {
MethodParameter parameter = parameters[i];
parameter.initParameterNameDiscovery(this.parameterNameDiscoverer);//設置參數名發現者
args[i] = resolveProvidedArgument(parameter, providedArgs);
if (args[i] != null) {
continue;
}
if (this.argumentResolvers.supportsParameter(parameter)) {//從參數解析器列表裏找到能夠支持該參數解析的
try {
args[i] = this.argumentResolvers.resolveArgument(
parameter, mavContainer, request, this.dataBinderFactory);//進行參數解析
continue;
}
catch (Exception ex) {
if (logger.isDebugEnabled()) {
logger.debug(getArgumentResolutionErrorMessage("Failed to resolve", i), ex);
}
throw ex;
}
}
if (args[i] == null) {
throw new IllegalStateException("Could not resolve method parameter at index " +
parameter.getParameterIndex() + " in " + parameter.getMethod().toGenericString() +
": " + getArgumentResolutionErrorMessage("No suitable resolver for", i));
}
}
return args;
}
- 獲取方法參數。
MethodParameter[] parameters = getMethodParameters();
這裏的參數是指我們最上面定義的public Boolean methodOne(Integer filedOne, String fieldTwo)
參數表示,因爲我們定義了兩個參數,所以這裏parameters有兩個元素。
我們看一下MethodParameter
類的定義:
public class MethodParameter {
private static final Annotation[] EMPTY_ANNOTATION_ARRAY = new Annotation[0];
private static final Class<?> javaUtilOptionalClass;
private final Method method;
private final Constructor<?> constructor;
private final int parameterIndex;
private int nestingLevel = 1;
/** Map from Integer level to Integer type index */
Map<Integer, Integer> typeIndexesPerLevel;
private volatile Class<?> containingClass;
private volatile Class<?> parameterType;
private volatile Type genericParameterType;
private volatile Annotation[] parameterAnnotations;
private volatile ParameterNameDiscoverer parameterNameDiscoverer;
private volatile String parameterName;
private volatile MethodParameter nestedMethodParameter;
...(省略)
}
- method 記錄參數屬於哪個方法(在這裏,
public java.lang.Boolean com.example.demo.controller.FooController.methodOne(java.lang.Integer,java.lang.String)
) - parameterIndex 記錄參數在所屬方法的位置索引(在這裏,filedOne的index = 0,fieldTwo的index = 1)
- containingClass記錄了所屬的Class(在這裏,
com.example.demo.controller.FooController
) - parameterType 記錄參數的類型(在這裏,filedOne的類型是
java.lang.Integer
,fieldTwo的類型是java.lang.String
) - parameterAnnotations 記錄參數上有什麼註解(在這裏,無註解,因此爲空)
- parameterNameDiscoverer 記錄參數名解析器,非常重要,它能解答最開始提出的問題
- parameterName 記錄參數名。我們就是要找到Spring MVC如何解析參數名,並給這個屬性賦值。
第一次進入到getMethodArgumentValues
方法的時候,調用getMethodParameters
方法可以直接獲取到parameters,因爲應用啓動的時候就解析好了,但是啓動的時候並沒有解析參數名,因此parameterName爲空。
- 設置參數名解析器:
parameter.initParameterNameDiscovery(this.parameterNameDiscoverer);
其中,this.parameterNameDiscoverer
是InvocableHandlerMethod
類的一個成員變量,直接new了一個 DefaultParameterNameDiscoverer
,是ParameterNameDiscoverer
的默認實現。
public class InvocableHandlerMethod extends HandlerMethod {
private WebDataBinderFactory dataBinderFactory;
private HandlerMethodArgumentResolverComposite argumentResolvers = new HandlerMethodArgumentResolverComposite();
private ParameterNameDiscoverer parameterNameDiscoverer = new DefaultParameterNameDiscoverer();
...(省略)
}
public class DefaultParameterNameDiscoverer extends PrioritizedParameterNameDiscoverer {
private static final boolean standardReflectionAvailable = ClassUtils.isPresent(
"java.lang.reflect.Executable", DefaultParameterNameDiscoverer.class.getClassLoader());
public DefaultParameterNameDiscoverer() {
if (standardReflectionAvailable) {
addDiscoverer(new StandardReflectionParameterNameDiscoverer());
}
addDiscoverer(new LocalVariableTableParameterNameDiscoverer());
}
}
我們看到,DefaultParameterNameDiscoverer
繼承自PrioritizedParameterNameDiscoverer
(一個ParameterNameDiscoverer代理,裏面維護了帶優先級的參數名解析器集合,先添加的優先解析,如果某個解析器解析後返回null,則會使用下一個解析器進行解析,默認情況下使用Java 8的反射機制進行解析,解析失敗就fall back到使用基於ASM的參數解析器去獲取class文件裏的debug信息),在構造DefaultParameterNameDiscoverer時就維護瞭解析器集合,如果類路徑下存在java.lang.reflect.Executable
,就添加一個StandardReflectionParameterNameDiscoverer
(使用Java 8的反射機制),再添加基於ASM的參數解析器LocalVariableTableParameterNameDiscoverer
,用於fall back時的解析
- 從參數解析器列表裏找到能夠支持該參數解析的
if (this.argumentResolvers.supportsParameter(parameter))
private HandlerMethodArgumentResolver getArgumentResolver(MethodParameter parameter) {
HandlerMethodArgumentResolver result = this.argumentResolverCache.get(parameter);
if (result == null) {
for (HandlerMethodArgumentResolver methodArgumentResolver : this.argumentResolvers) {
if (logger.isTraceEnabled()) {
logger.trace("Testing if argument resolver [" + methodArgumentResolver + "] supports [" +
parameter.getGenericParameterType() + "]");
}
if (methodArgumentResolver.supportsParameter(parameter)) {
result = methodArgumentResolver;
this.argumentResolverCache.put(parameter, result);
break;
}
}
}
return result;
}
這裏,能夠支持我們代碼中參數解析的解析器爲RequestParamMethodArgumentResolver
,何以見得?我們看org.springframework.web.method.annotation.RequestParamMethodArgumentResolver#supportsParameter
public boolean supportsParameter(MethodParameter parameter) {
if (parameter.hasParameterAnnotation(RequestParam.class)) {//我們的兩個參數都沒有用RequestParam註解進行修飾,因此代碼會走到else
if (Map.class.isAssignableFrom(parameter.nestedIfOptional().getNestedParameterType())) {
String paramName = parameter.getParameterAnnotation(RequestParam.class).name();
return StringUtils.hasText(paramName);
}
else {
return true;
}
}
else {
if (parameter.hasParameterAnnotation(RequestPart.class)) {
return false;
}
parameter = parameter.nestedIfOptional();
if (MultipartResolutionDelegate.isMultipartArgument(parameter)) {
return true;
}
else if (this.useDefaultResolution) {/true
return BeanUtils.isSimpleProperty(parameter.getNestedParameterType());//代碼會走到這裏
}
else {
return false;
}
}
}
public static boolean isSimpleProperty(Class<?> clazz) {
Assert.notNull(clazz, "Class must not be null");
return isSimpleValueType(clazz) || (clazz.isArray() && isSimpleValueType(clazz.getComponentType()));
}
public static boolean isSimpleValueType(Class<?> clazz) {
return (ClassUtils.isPrimitiveOrWrapper(clazz) ||
Enum.class.isAssignableFrom(clazz) ||
CharSequence.class.isAssignableFrom(clazz) ||
Number.class.isAssignableFrom(clazz) ||
Date.class.isAssignableFrom(clazz) ||
URI.class == clazz || URL.class == clazz ||
Locale.class == clazz || Class.class == clazz);
}
其實,Spring MVC在RequestMappingHandlerAdapter
的afterPropertiesSet
方法中初始化了參數解析器列表argumentResolvers
,註冊了四類一系列參數解析器:
- 基於註解的參數解析器
- RequestParamMethodArgumentResolver(@RequestParam,useDefaultResolution = false)
- RequestParamMapMethodArgumentResolver(@RequestParam)
- PathVariableMethodArgumentResolver(@PathVariable)、
- RequestHeaderMethodArgumentResolver(@RequestHeader)
- RequestResponseBodyMethodProcesso(r@RequestBody)
- ServletModelAttributeMethodProcessor(@ModelAttribute, annotationNotRequired = false)
- ...
- 基於類型的參數註解器
- ServletRequestMethodArgumentResolver(ServletRequest、InputStream)
- ServletResponseMethodArgumentResolver(ServletResponse、OutputStream)
- ModelMethodProcessor(Model)
- ...
- 自定義參數解析器
- 兜底參數解析器
- RequestParamMethodArgumentResolver(useDefaultResolution = true)
- ServletModelAttributeMethodProcessor(annotationNotRequired = true)
其中RequestParamMethodArgumentResolver
被註冊了兩次,第一次useDefaultResolution = false,第二次useDefaultResolution = true。
useDefaultResolution的含義是:一個簡單類型的方法參數,如果沒有被諸如@RequestParam等註解修飾,要不要被當成一個請求參數去解析。
我們的兩個請求參數filedOne、filedTwo,都沒有被@RequestParam
進行註解,且類型都是簡單類型(Integer、String)。因此,我們的兩個請求參數都將會被RequestParamMethodArgumentResolver
進行解析
- 進行參數解析
args[i] = this.argumentResolvers.resolveArgument(
parameter, mavContainer, request, this.dataBinderFactory);
public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer,
NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
HandlerMethodArgumentResolver resolver = getArgumentResolver(parameter);
if (resolver == null) {
throw new IllegalArgumentException("Unknown parameter type [" + parameter.getParameterType().getName() + "]");
}
return resolver.resolveArgument(parameter, mavContainer, webRequest, binderFactory);
}
經過上面的分析,知道我們的resolver就是RequestParamMethodArgumentResolver
,它並沒有重寫resolveArgument
方法,因此這裏調用的是父類AbstractNamedValueMethodArgumentResolver
裏的方法,我們接着看
public final Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer,
NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
NamedValueInfo namedValueInfo = getNamedValueInfo(parameter);//獲取參數信息,包含參數名,是否required,以及參數默認值
MethodParameter nestedParameter = parameter.nestedIfOptional();
Object resolvedName = resolveStringValue(namedValueInfo.name);//獲取解析後的參數名
...(省略)
Object arg = resolveName(resolvedName.toString(), nestedParameter, webRequest);//獲取參數值
...(省略)
arg = binder.convertIfNecessary(arg, parameter.getParameterType(), parameter);//轉型成實際的參數類型
...(省略)
handleResolvedValue(arg, namedValueInfo.name, parameter, mavContainer, webRequest);//勾子方法,處理解析之後的值
return arg;
}
進入getNamedValueInfo
方法
private NamedValueInfo getNamedValueInfo(MethodParameter parameter) {
NamedValueInfo namedValueInfo = this.namedValueInfoCache.get(parameter);
if (namedValueInfo == null) {
namedValueInfo = createNamedValueInfo(parameter);
namedValueInfo = updateNamedValueInfo(parameter, namedValueInfo);
this.namedValueInfoCache.put(parameter, namedValueInfo);
}
return namedValueInfo;
}
第一次進來,無法從cache獲取到NamedValueInfo信息,需要經過create、update步驟之後,再放回緩存。
private NamedValueInfo updateNamedValueInfo(MethodParameter parameter, NamedValueInfo info) {
String name = info.name;
if (info.name.isEmpty()) {
name = parameter.getParameterName();
...(省略)
}
我們知道在createNamedValueInfo
中, info.name被賦值爲"",因此直接進入name = parameter.getParameterName()
public String getParameterName() {
ParameterNameDiscoverer discoverer = this.parameterNameDiscoverer; // 這裏是上面提到的DefaultParameterNameDiscoverer
if (discoverer != null) {
String[] parameterNames = (this.method != null ?
discoverer.getParameterNames(this.method) : discoverer.getParameterNames(this.constructor));
if (parameterNames != null) {
this.parameterName = parameterNames[this.parameterIndex];
}
this.parameterNameDiscoverer = null;
}
return this.parameterName;
}
discoverer爲上文中提到的DefaultParameterNameDiscoverer
,因此我們直接進入其getParameterNames
方法,又因未重寫該方法,因此實際上調用的是其父類PrioritizedParameterNameDiscoverer
的相應方法。
@Override
public String[] getParameterNames(Method method) {
for (ParameterNameDiscoverer pnd : this.parameterNameDiscoverers) {
String[] result = pnd.getParameterNames(method);
if (result != null) {
return result;
}
}
return null;
}
正如我們上文提到的,PrioritizedParameterNameDiscoverer
是一個解析器代理,其維護多個解析器。在解析的時候,使用其維護的解析器集合一一進行解析,如果解析成功,直接返回;如果解析失敗,則使用集合中下一個解析器進行解析。
第一個解析器是StandardReflectionParameterNameDiscoverer
,因爲我們並未使用 -parameters
進行編譯,因此解析失敗,返回null。
第二個解析器是LocalVariableTableParameterNameDiscoverer
,其實現如下:
public String[] getParameterNames(Method method) {
Method originalMethod = BridgeMethodResolver.findBridgedMethod(method); //根據橋接方法尋找原始方法,在這裏橋接方法跟原始方法是同一個
Class<?> declaringClass = originalMethod.getDeclaringClass();
Map<Member, String[]> map = this.parameterNamesCache.get(declaringClass);
if (map == null) {
map = inspectClass(declaringClass); //使用ASM獲取類信息
this.parameterNamesCache.put(declaringClass, map);
}
if (map != NO_DEBUG_INFO_MAP) {
return map.get(originalMethod);
}
return null;
}
進入inspectClass
方法
private Map<Member, String[]> inspectClass(Class<?> clazz) {
InputStream is = clazz.getResourceAsStream(ClassUtils.getClassFileName(clazz));
...(省略)
ClassReader classReader = new ClassReader(is);
Map<Member, String[]> map = new ConcurrentHashMap<Member, String[]>(32);
classReader.accept(new ParameterNameDiscoveringVisitor(clazz, map), 0);
return map;
...(省略)
}
先是讀取class文件進流裏,然後藉助ClassVisitor,調用ClassReader
的accept
方法去解析Java類文件。而accept
方法呈現的細節,正是對class文件解析。
class結構如下:
ClassFile {
u4 magic;
u2 minor_version;
u2 major_version;
u2 constant_pool_count;
cp_info constant_pool[constant_pool_count-1];
u2 access_flags;
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];
}
從上述結構中看到,class文件中存儲有一項類型爲method_info的methods屬性,我們稱之爲方法表。再來看看method_info的結構:
method_info {
u2 access_flags;
u2 name_index;
u2 descriptor_index;
u2 attributes_count;
attribute_info attributes[attributes_count];
}
method_info中存儲有一項類型爲attribute_info的attributes屬性,我們稱之爲屬性表。再來看看attribute_info的結構:
attribute_info {
u2 attribute_name_index;
u4 attribute_length;
u1 info[attribute_length];
}
這是attribute_info的通用結構,它可以用在ClassFile、field_info、method_info、Code_attribute中。正是由於這個原因,上面的method_info才能包含attribute_info類型的屬性attributes。而其中有一項屬性叫Code
,其結構爲:
Code_attribute {
u2 attribute_name_index;
u4 attribute_length;
u2 max_stack;
u2 max_locals;
u4 code_length;
u1 code[code_length];
u2 exception_table_length;
{ u2 start_pc;
u2 end_pc;
u2 handler_pc;
u2 catch_type;
} exception_table[exception_table_length];
u2 attributes_count;
attribute_info attributes[attributes_count];
}
剛纔我們說過,attribute_info還能用在Code_attribute中,所以上面的結構中,又包含了attribute_info類型的屬性attributes。其中有一項屬性叫LocalVariableTypeTable
,我們看看其結構:
LocalVariableTable_attribute {
u2 attribute_name_index;
u4 attribute_length;
u2 local_variable_table_length;
{ u2 start_pc;
u2 length;
u2 name_index;
u2 descriptor_index;
u2 index;
} local_variable_table[local_variable_table_length];
}
裏面有一個內嵌屬性local_variable_table,其中的name_index指向了常量池中的某項CONSTANT_Utf8_info
,其值就是我們所要找的參數名。
關於class文件的結構,更詳細的內容可以查閱官方文檔
至此,總算弄明白Spring MVC對於無註解的參數是如何獲取參數名的:通過LocalVariableTableParameterNameDiscoverer進行解析,該解析器藉助了ASM工具,讀取class文件,根據class文件的結構,讀取method_info->Code_attribute->LocalVariableTable_attribute->local_variable_table->name_index->CONSTANT_Utf8_info
,最終找到方法的參數名