作者：京东零售 李文龙 。

1.背景

“ 俗话说：为了修复一个小bug而引入了一个更大bug ” 。

因所负责的系统使用的spring框架版本5.1.5.RELEASE在线上出过一个偶发的小事故，最后定位为spring-context中的一个bug导致的.

为了修复此bug进行了spring版本的升级，最终定的版本为收银台团队使用的版本5.2.12.RELEASE，对应的springboot版本为2.2.12.RELEASE.

选择这个版本的原因是:

1. 有团队经过了长时间的线上验证 。

2. 修复了5.1.5.RELEASE对应的bug 。

2.升级上线

升级相关版本后在预发环境进行了验证，暂未遇到关于框架的问题。本以为安全升级完成，在上线过程中发现在APP中无法访问，此时还未挂载流量.

日志中分析是某些参数未解析到，后在nginx日志中查到相关请求，使用 postman模拟请求可以正常使用 .

3.分析验证定位原因

1.临时修复

在代码一致的情况下，唯一的可能就只能是线上与预发配置不同，经对比分析得出是某个 过滤器的顺序 在线上未配置，按照预发的配置后可正常使用。我们暂且称修改的这两个过滤器为 M 和 A .

其中默认情况下执行顺序为 M->A ，顺序修改为A->M后正常，其两者作用大致为:

M : 通用过滤器，解析url中的参数至parameterMap中，并初始化读取了body中的inputstream进行了byte数组的缓存，用于解决重复读取流问题 A: 特定处理器，先是查询parameter中的参数，然后逻辑处理后再设置一些特殊参数.

2.为何需要改过滤器顺序

经查未升级前过滤器的顺序与升级后过滤器顺序一致，为何升级spring框架后需要修改配置。此时猜测可能是spring在升级过程中修改了一部分代码， 。

但未有头绪，只能先调转方向分析为什么postman和浏览器中的swagger可以正常使用 。

3.分析nginx日志

前端请求与postman请求的nginx日志进行了分析得出了原因，对比日志如下:

postman ： POST /shop/bpaas/floor?client&clientVersion&ip=111.202.149.19&gfid=getShopMainFloor&body= 前端 : POST /shop/bpaas/floor HTTP/1.0" 200 634 "-" "api" "0.94" 0.008 0.007 client&clientVersion&ip=111.202.149.17&gfid=getShopMainFloor&body= 。

经过以上对比发现虽然postman使用了post请求，但数据还是放置在url中，在经过系统的一个内置过滤器M时将url中的参数解析到了parameterMap中，后续过滤器可以使用 。

request.getParameter 获取到，注意此方法是解决问题的关键，此时还未意识到.

4.升级前后框架是否有大的修改

因升级的版本是升级了一个小版本号，所以不好对比升级的buglist，只能慢慢进行分析，后在分析过滤器时发现升级spring后过滤器个数由11个减少到了10个，减少了那一个为:

                        
                          org.springframework.web.filter.HiddenHttpMethodFilter

                        
                      

此过虑器的作用是在浏览器不支持PUT、DELETE、PATCH等method时，可以在form表单中使用隐藏的_method参数支持这几种method。好像跟参数解析没有任何关系， 。

继续分析升级版本中 （由2.1.3.RELEASE->2.2.12.RELEASE）是否修改了此过滤器的一些内容，后在 2.2.0.M5 的release notes中发现HiddenHttpMethodFilter相关的:

“ Disable auto-configuration of HiddenHttpMethodFilter by default ” github上对应的版本release notes： https://github.com/spring-projects/spring-boot/releases/tag/v2.2.0.M5 。

也就是说升级后HiddenHttpMethodFilter默认配置由enable修改为了disable，如果再修改回去是不是可以修复参数解析的问题呢?

5.添加过滤器enable配置

因bug修复列表中有对应的issues，所以找到了此过滤器对应的配置:

-Dspring.mvc.hiddenmethod.filter.enabled=true 。

添加后可以正常使用，证明是此过滤器中在某种条件下不可缺少.

6.未升级spring版本时disable验证

在确认未升级版本的spring支持此参数的情况下，添加了以上参数，将默认的启动修改成了禁用，经验证：在不代码修改的情况下，无此过滤器时参数无法解析。证明了上步的猜测.

7.深入源码分析

此时需要分析HiddenHttpMethodFilter过滤器中是否有特殊操作，源码如下:

                        
                          protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
			throws ServletException, IOException {

		HttpServletRequest requestToUse = request;

		if ("POST".equals(request.getMethod()) && request.getAttribute(WebUtils.ERROR_EXCEPTION_ATTRIBUTE) == null) {
			String paramValue = request.getParameter(this.methodParam);
			if (StringUtils.hasLength(paramValue)) {
				String method = paramValue.toUpperCase(Locale.ENGLISH);
				if (ALLOWED_METHODS.contains(method)) {
					requestToUse = new HttpMethodRequestWrapper(request, method);
				}
			}
		}

		filterChain.doFilter(requestToUse, response);
	}

                        
                      

分析以上源码可以发现，有且只有一种可能，就是 request.getParameter 可能是解决问题的是关键.

8.大胆猜测

分析后源码猜测，第一步中的修改顺序有可能是A中有调用 getParameter ，所以顺序调整为A->M后，相当于间接使用了HiddenHttpMethodFilter.

9.开始验证

在不使用HiddenHttpMethodFilter的情况下，如果在过滤器原有顺序不修改的情况下，只要在 M 执行前调用了 request.getParameter ，理论上可以正常为使用。所以在debug情况下 。

利用工具在 M 过滤器调用前先行执行 request.getParameter ，发现的确可以正常使用.

10.分析过滤器

先前简述了M的功能，主要是包装了request，后读源码时发现，如果是post请求，读取body体中的数据后并未解析body中的参数至parameterMap中，而代码中的其它过滤器都是 。

通过 request.getParameter 获取的数据，重写后的代码:

                        
                          public String getParameter(String name) {
		if ( this.parameterMap.containsKey(name) )
			return this.parameterMap.get(name);
		else {
			return super.getParameter(name);
		}
	}

                        
                      

在经过request包装后，先是从paremeterMap中获取数据，此时map肯定是没有数据，只能从父类获取，而父类获取时会解析parameter，解析时使用到了inputStream，但M过滤器 。

的在初始化时解析了输入流，此时tomcat内部使用内部的request获取stream时将获取到空数据，即无法从parameter中获取到body体中的数据.

而如果在调用M前调用了 request.getParameter， tomcat内部将提前于M解析parameter，可以保证后续可获取到相关参数.

4. 修复方案

既然得出了结论，那么升级spring版本后修复此bug可选择的方案就比较多了，主要有:

1. 启用HiddenHttpMethodFilter，添加对应的参数，保证升级前后过滤器个数与顺序一致 。

2. 调整理过滤器 A与M 的顺序，保证M在A之前执行即可.

3. 修改过滤器 M 内部的逻辑，不在初始化的时候解析body，或是在解析body后将参数重新放置到parameterMap中.

此文是笔者按照分析流程进行简单验证，分析验证过程中难免有遗漏之处，如有错误遗漏还烦请各位指出共同进步.

最后此篇关于springboot升级过程中踩坑定位分析记录|京东云技术团队的文章就讲到这里了,如果你想了解更多关于springboot升级过程中踩坑定位分析记录|京东云技术团队的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。