SpringMVC源码探索之RequestBody的工作原理-蒲公英云

SpringMVC源码探索之RequestBody的工作原理

遇到一个很奇怪的问题，后面发现了问题所在，原因是自己太过匆忙、连快捷键都被复制粘贴省略了。虽然出现问题的原因有点傻逼，但是之所以出现这种问题的原因却更加引人入胜。

问题现象描述

Controller中没有逻辑，只有一个@RequestBody注释的form表单
在这里插入图片描述
然而这个TestBean有点特殊，非一般的get/set方法

按照常理，发送post请求，body中塞入{"param":"hello"}即可成功注入到TestBean的实例中

高潮在后面，如果我改成{"paramA":"hello"}，结果却能成功接收：

综上所述，paramA为之前定义的一个变量，我把它改成了新的变量param，然后顺便把paramA的get/set方法中的this.paramA改成了this.param。然后就出现了上面的情况。要知道，这个现象很反常，并且不常见。非常想知道为什么！

怎么通向背后的原因

从源码中看spring是如何处理@RequestBody

站在巨人肩膀上

从网上的参考资料来看，处理相关内容的源码可能位于一个叫做readWithMessageConverters()方法中。打开该方法所在的类（双击shift，然后输入方法名），大致是八九不离十的，如下：
在这里插入图片描述
打开至该方法后，使用debug模式，在可能的地方打上断点，发送postman请求，等待请求的到来：

接着往下看，寻找到一个能将JSON转换成对象的方法：

此时的messageConverters和body内容如下：

这里的read()，才是真正的开始。

向着jackson-databind的源码出发

跟着上面的read()方法，一路打断点达到了这里，这可以说是最终setter方法的执行处，代码如下：
加粗样式
所以，为什么setter方法会变成setParamA()呢？ 目前为止，可行的解释为：jackson是根据已解析的出来的json的键，去寻找对应键的setter方法，与对应的Form表单类中的成员变量的值无关，因此也解释了刚开头那一幕戏剧性的现象。但是，源代码在哪里？

如何寻找对应的setter方法

经过一次又一次的打断点、跟踪代码运行，终于将规则锁定在了POJOPropertiesCollector.java这个类上了。这里面还涉及到了打断点、跟踪代码的一些技巧，一定要分清F7、F8、F9呀，不然就很容易就要从头再来。
to be continued...
从上面的代码来看，对TestForm的解析，变成了只有一个变量为paramA的bean类。所以，按照paramA的键，去JSON中取数据，然后调用对应的setter方法，最后赋值给了param，过程就是这样。

总结

对这个流程的跟踪，发现：只有第一次请求的时候，会初始化一个把JSON转化成对象的这样一个类，缓存使用的是LRUMap。其中desc是一个解析器，包含了变量与getter/setter方法之间的映射关系。关键的代码如下：
在这里插入图片描述
调试跟踪的过程中，主要的时间都花在了desc的初始化上。因为后续的调用，就是根据desc的映射关系去执行。