解决偶现的MissingServletRequestParameterException异常问题

这篇文章主要介绍了解决偶现的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 'xxx' is not present at org.springframework.web.method.annotation.RequestParamMethodArgumentResolver.handleMissingValue(RequestParamMethodArgumentResolver.java:198) at org.springframework.web.method.annotation.AbstractNamedValueMethodArgumentResolver.resolveArgument(AbstractNamedValueMethodArgumentResolver.java:109) at org.springframework.web.method.support.HandlerMethodArgumentResolverComposite.resolveArgument(HandlerMethodArgumentResolverComposite.java:121) at org.springframework.web.method.support.InvocableHandlerMethod.getMethodArgumentValues(InvocableHandlerMethod.java:158) at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:128) at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:97) at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:827) at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:738) at org.springframework.web.servlet.mvc.method.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.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

在请求中显然是带了这个参数的,开始时还以为自己眼花,于是又试了一下,结果接口返回又正常了。

但是,既然错误日志出现了,就不能轻易地放过,尤其是这种偶现的错误,充满着风险,极有可能在某个关键时刻爆发。因此决定抽出时间排查这个问题。接下来,就是整个排查过程。

排查过程

具体的请求如下所示:

 curl -X GET --header "Accept: */*" http://localhost:8080/xxx/api/v3/xxx/getXX?param=123456

其中param在Controller的方法中被声明为required=true,也就是必传参数,而在前后端交互里,这个参数也是一定会传的。

既然这是一个偶现的问题,就不可能通过手动一次次地调用请求进行问题的重现。在这里我采用了Jmeter作为请求触发器,进行30次一批的重复请求,结果在跑第一次的时候,就出现了一次请求异常。

反复跑了两三次之后,都出现了同样的结果,既然问题已经确认,并且能够稳定重现,接下来就是如何找到问题的根源并解决这个问题了。

因为有具体的异常类,所以我的第一想法就是在这个异常类的构造函数中加断点,看看为什么会抛出这个异常。通过调用栈,在RequestParamMethodArgumentResolver(AbstractNamedValueMethodArgumentResolver)中发现如下代码片段

 Object arg = resolveName(resolvedName.toString(), nestedParameter, webRequest); //在RequestParamMethodArgumentResolver中,直接通过调用request.getParameterValues(name)来获取普通请求的参数 if (arg == null) { if (namedValueInfo.defaultValue != null) { arg = resolveStringValue(namedValueInfo.defaultValue); } else if (namedValueInfo.required && !nestedParameter.isOptional()) { handleMissingValue(namedValueInfo.name, nestedParameter, webRequest); //如果没有获取到且没有默认值,就会在这里抛出异常。 } arg = handleNullValue(namedValueInfo.name, arg, nestedParameter.getNestedParameterType()); } else if ("".equals(arg) && namedValueInfo.defaultValue != null) { arg = resolveStringValue(namedValueInfo.defaultValue); }

看到这里的时候心里不禁疑惑,难道真的没传参数?或者是参数在传递的过程丢了?或者…被框架吃了?!

但疑惑不是我想要的,答案才是我想要的。既然request.getParameterValues里面没有得到想要的值,那就应该去找正常请求时,这个值是如何被设置的。

首先想到的是查看Request的类图结构。以及请求被处理的流程图

Request类图

Request处理流程图

所以,最原始的数据被保存在了org.apache.coyote.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; decodedQuery.recycle(); parseFailedReason = null; }

由于Tomcat中,Request以及Response对象都是会被循环使用的,因此这个时候也是整个Request被重置的时候。

所以根本原因是,在Parameter被重置了之后,didQueryParameters又被置成了true,导致新的请求参数没有被正确解析,就报错了(此时的parameterMap已经被重置,为空)。

而didQueryParameters只有在一种情况下才会被置为true,也就是handleQueryParameters方法被调用时。

而handleQueryParameters会在多个场景中被调用,其中一个就是getParameterValues,获取请求参数的值。

到这里,就可以推断,应用中可能存在代码,在请求结束之后,仍然通过Request对象获取其中的参数值。

全局搜索引用了HttpServletRequest的地方。最终发现埋点类中有如下代码

 @Async public void buryPoint(long userId, HttpServletRequest request.....) { if (request != null) { xxx = request.getParameter("xxx"); }

由于这段逻辑是异步执行的,因此完全有可能在请求结束之后,仍然调用request.getParameter方法,导致下一次的请求参数不被解析。将此段代码注释掉,重新使用Jmeter进行请求,错误不再出现。

结论

不要将HttpServletRequest传递到任何异步方法中!

以上为个人经验,希望能给大家一个参考,也希望大家多多支持0133技术站。

以上就是解决偶现的MissingServletRequestParameterException异常问题的详细内容,更多请关注0133技术站其它相关文章!

赞(0) 打赏
未经允许不得转载:0133技术站首页 » Java