解决偶现的MissingServletRequestParameterException异常问题
⽬录
概述
排查过程
结论
概述
最近遇到⼀个偶现的问题，在向服务端请求的时候，偶尔会出现异常，在请求中的query String 传递了参数，却出现了异常MissingServletRequestParameterException
如下所⽰：
018-02-05 11:29:34.910 ERROR 41469 --- [a626f375-7f79-4fd2-88be-1db10a3811cb-] [nio-8080-exec-7] c.s.s.f.ValidationGlobalExceptionHandler : org.springframework.web.bind.MissingServletRequestParameterException: Required long parameter 'xx
x' is not pre    at org.hod.annotation.RequestParamMethodArgumentResolver.handleMissingValue(RequestParamMethodArgumentResolver.java:198)
at org.hod.solveArgument(AbstractNamedValueMethodArgumentResolver.java:109)
at org.hod.solveArgument(HandlerMethodArgumentResolverComposite.java:121)
at org.hod.MethodArgumentValues(InvocableHandlerMethod.java:158)
at org.hod.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:128)
at org.springframework.web.hod.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:97)
at org.springframework.web.hod.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:827)
at org.springframework.web.hod.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:738)
at org.springframework.web.hod.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:963)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:897)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:861)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at org.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at at.websocket.server.WsFilter.doFilter(WsFilter.java:52)
在请求中显然是带了这个参数的，开始时还以为⾃⼰眼花，于是⼜试了⼀下，结果接⼝返回⼜正常了。
但是，既然错误⽇志出现了，就不能轻易地放过，尤其是这种偶现的错误，充满着风险，极有可能在某个关键时刻爆发。因此决定抽出时间排查这个问题。接下来，就是整个排查过程。
排查过程
具体的请求如下所⽰：
curl -X GET --header "Accept: */*" localhost:8080/xxx/api/v3/xxx/getXX?param=123456
其中param在Controller的⽅法中被声明为required=true，也就是必传参数，⽽在前后端交互⾥，这个参数也是⼀定会传的。
既然这是⼀个偶现的问题，就不可能通过⼿动⼀次次地调⽤请求进⾏问题的重现。在这⾥我采⽤了Jmeter作为请求触发器，进⾏30次⼀批的重复请求，结果在跑第⼀次的时候，就出现了⼀次请求异常。
反复跑了两三次之后，都出现了同样的结果，既然问题已经确认，并且能够稳定重现，接下来就是如何到问题的根源并解决这个问题了。
因为有具体的异常类，所以我的第⼀想法就是在这个异常类的构造函数中加断点，看看为什么会抛出这个异常。通过调⽤栈，在
RequestParamMethodArgumentResolver(AbstractNamedValueMethodArgumentResolver)中发现如下代码⽚段
Object arg = String(), nestedParameter, webRequest); //在RequestParamMethodArgumentResolver中，直接通过调⽤ParameterValues(name)来获取普通请求的参数
if (arg == null) {
if (namedValueInfo.defaultValue != null) {
arg = resolveStringValue(namedValueInfo.defaultValue);
}
else if (quired && !nestedParameter.isOptional()) {
handleMissingValue(namedValueInfo.name, nestedParameter, webRequest); //如果没有获取到且没有默认值，就会在这⾥抛出异常。
}
arg = handleNullValue(namedValueInfo.name, arg, NestedParameterType());
}
else if ("".equals(arg) && namedValueInfo.defaultValue != null) {
arg = resolveStringValue(namedValueInfo.defaultValue);
}
看到这⾥的时候⼼⾥不禁疑惑，难道真的没传参数？或者是参数在传递的过程丢了？或者…被框架吃了？！
但疑惑不是我想要的，答案才是我想要的。既然ParameterValues⾥⾯没有得到想要的值，
那就应该去正常请求时，这个值是如何被设置的。
⾸先想到的是查看Request的类图结构。以及请求被处理的流程图
所以，最原始的数据被保存在了Request这个类中，深⼊这个类，我们就能够更接近答案。于是直接到了Http11Processor的service⽅法中，看具体的处理过程。⾸先在799⾏加断点，看看是处理结果是什么，由于问题是处在parameter上，直接查看此时request中parameters的各种值。
正常请求：
异常请求：
对⽐两者不难发现，异常请求中的queryMB与正常请求中的是⼀样的，也就是说我们请求中带的参数被传递到了服务器。但异常请求didQueryParameters被置成了true，⽽从代码中可以知道，这个代码实际上是⽤于判断query string是否已经被解析过了，并且，在请求处理结束的时候，会调⽤parameter的recycle⽅法
public void recycle() {
parameterCount = 0;
paramHashValues.clear(); //清空了解析后的parameter map
didQueryParameters=false; //是否被解析过，置成false
encoding=null;
parseFailedReason = null;
}
由于Tomcat中，Request以及Response对象都是会被循环使⽤的，因此这个时候也是整个Request被重置的时候。
所以根本原因是，在Parameter被重置了之后，didQueryParameters⼜被置成了true，导致新的请求参数没有被正确解析，就报错了（此时的parameterMap已经被重置，为空）。
⽽didQueryParameters只有在⼀种情况下才会被置为true，也就是handleQueryParameters⽅法被调⽤时。
⽽handleQueryParameters会在多个场景中被调⽤，其中⼀个就是getParameterValues，获取请求参数的值。
到这⾥，就可以推断，应⽤中可能存在代码，在请求结束之后，仍然通过Request对象获取其中的参数值。
全局搜索引⽤了HttpServletRequest的地⽅。最终发现埋点类中有如下代码
spring framework是什么框架的@Async
public void buryPoint(long userId, ) {
if (request != null) {
xxx = Parameter("xxx");
}
由于这段逻辑是异步执⾏的，因此完全有可能在请求结束之后，仍然调⽤Parameter⽅法，导致下⼀次的请求参数不被解析。将此段代码注释掉，重新使⽤Jmeter进⾏请求，错误不再出现。结论
不要将HttpServletRequest传递到任何异步⽅法中！
以上为个⼈经验，希望能给⼤家⼀个参考，也希望⼤家多多⽀持。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。