本文地址：https://juejin.cn/post/7140462361759973384
背景
公司有个渠道系统，专门对接三方渠道使用，没有什么业务逻辑，主要是转换报文和参数校验之类的工作，起着一个承上启下的作用。
最近在优化接口的响应时间，优化了代码之后，但是时间还是达不到要求；有一个诡异的100ms左右的耗时问题，在接口中打印了请求处理时间后，和调用方的响应时间还有差了100ms左右。比如程序里记录150ms，但是调用方等待时间却为250ms左右。
下面记录下当时详细的定位&解决流程（其实解决很简单，关键在于怎么定位并找到解决问题的方法）
一、定位过程
分析代码
渠道系统是一个常见的spring-boot web工程，使用了集成的tomcat。分析了代码之后，发现并没有特殊的地方，没有特殊的过滤器或者拦截器，所以初步排除是业务代码问题
分析调用流程
Nginx -反向代理-> 渠道系统[jboss@VM_0_139_centos ~]$ ping 10.0.0.139
PING 10.0.0.139 (10.0.0.139) 56(84) bytes of data.
64 bytes from 10.0.0.139: icmp_seq=1 ttl=64 time=0.029 ms
64 bytes from 10.0.0.139: icmp_seq=2 ttl=64 time=0.041 ms
64 bytes from 10.0.0.139: icmp_seq=3 ttl=64 time=0.040 ms
64 bytes from 10.0.0.139: icmp_seq=4 ttl=64 time=0.040 ms
# 由于日志是没问题的，这里直接复制上面日志了
[jboss@VM_0_139_centos ~]$ ping 10.0.0.139
PING 10.0.0.139 (10.0.0.139) 56(84) bytes of data.
64 bytes from 10.0.0.139: icmp_seq=1 ttl=64 time=0.029 ms
64 bytes from 10.0.0.139: icmp_seq=2 ttl=64 time=0.041 ms
64 bytes from 10.0.0.139: icmp_seq=3 ttl=64 time=0.040 ms
64 bytes from 10.0.0.139: icmp_seq=4 ttl=64 time=0.040 ms
[jboss@VM_10_91_centos tmp]$ curl -w "@curl-time.txt" http://127.0.0.1:7744/send
success
http: 200
dns: 0.001s
redirect: 0.000s
time_connect: 0.001s
time_appconnect: 0.000s
time_pretransfer: 0.001s
time_starttransfer: 0.073s
size_download: 7bytes
speed_download: 95.000B/s
----------
time_total: 0.073s 请求总耗时
[jboss@VM_10_91_centos tmp]$ curl -w "@curl-time.txt" http://127.0.0.1:7744/send
success
http: 200
dns: 0.001s
redirect: 0.000s
time_connect: 0.001s
time_appconnect: 0.000s
time_pretransfer: 0.001s
time_starttransfer: 0.003s
size_download: 7bytes
speed_download: 2611.000B/s
----------
time_total: 0.003s
二、Arthas分析问题
Arthas 是Alibaba开源的Java诊断工具，深受开发者喜爱。当你遇到以下类似问题而束手无策时，Arthas可以帮助你解决：
1、trace 方法内部调用路径，并输出方法路径上的每个节点上耗时
2、trace 命令能主动搜索 class-pattern／method-pattern
3、对应的方法调用路径，渲染和统计整个调用链路上的所有性能开销和追踪调用链路。
有了神器，那么该追踪什么方法呢？由于我对Tomcat源码不是很熟，所以只能从spring mvc下手，先来trace一下spring mvc的入口：
[jboss@VM_10_91_centos tmp]$ curl -w "@curl-time.txt" http://127.0.0.1:7744/send
success
http: 200
dns: 0.001s
redirect: 0.000s
time_connect: 0.001s
time_appconnect: 0.000s
time_pretransfer: 0.001s
time_starttransfer: 0.115s
size_download: 7bytes
speed_download: 60.000B/s
----------
time_total: 0.115sorg.springframework.web.servlet.DispatcherServlet作为参数：org.apache.coyote.http11.Http11Processor.service ，从名字上看，http1.1处理器，这可能是一个比较好的切入点。下面来trace一下：+---[min=0.004452ms,max=34.479307ms,total=74.206249ms,count=31] org.apache.catalina.webresources.TomcatJarInputStream:getNextJarEntry() #117
The purpose of this sub-class is to obtain references to the JarEntry objects for META-INF/ and META-INF/MANIFEST.MF that are otherwise swallowed by the JarInputStream implementation.
[arthas@24851]$ trace org.apache.catalina.webresources.TomcatJarInputStream *
Press Q or Ctrl+C to abort.
Affect(class-cnt:1 , method-cnt:4) cost in 44 ms.
`---ts=2019-09-14 21:37:47;thread_name=http-nio-7744-exec-5;id=14;is_daemon=true;priority=5;TCCL=org.springframework.boot.loader.LaunchedURLClassLoader@20ad9418
`---[0.234952ms] org.apache.catalina.webresources.TomcatJarInputStream:createZipEntry()
+---[0.039455ms] java.util.jar.JarInputStream:createZipEntry() #43
`---[0.007827ms] java.lang.String:equals() #44
`---ts=2019-09-14 21:37:47;thread_name=http-nio-7744-exec-5;id=14;is_daemon=true;priority=5;TCCL=org.springframework.boot.loader.LaunchedURLClassLoader@20ad9418
`---[0.050222ms] org.apache.catalina.webresources.TomcatJarInputStream:createZipEntry()
+---[0.001889ms] java.util.jar.JarInputStream:createZipEntry() #43
`---[0.001643ms] java.lang.String:equals() #46
#这里一共31个trace日志，删减了剩下的
/**
* Creates a newJarEntry(ZipEntry) for the
* specified JAR file entry name. The manifest attributes of
* the specified JAR file entry name will be copied to the new
*JarEntry.
*
* @param name the name of the JAR/ZIP file entry
* @return theJarEntryobject just created
*/
protected ZipEntry createZipEntry(String name) {
JarEntry e = new JarEntry(name);
if (man != ) {
e.attr = man.getAttributes(name);
}
return e;
}
createZipEntry 有个name参数，从注释上看，是jar/zip文件名，如果能得到文件名这种关键信息，就可以直接定位问题了；还是通过Arthas，使用watch命令，动态监测方法调用数据watch方法执行数据观测
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-swagger2</artifactId>
<version>2.9.2</version>
</dependency>
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-swagger-ui</artifactId>
<version>2.9.2</version>
</dependency>
三、Tomcat embed Bug分析&解决
1、为什么每次请求会加载Jar包内的静态资源
关键在于 org.apache.catalina.mapper.Mapper#internalMapWrapper
2、为什么连续请求不会出现问题
因为Tomcat对于这种静态资源的解析是有缓存的，优先从缓存查找，缓存过期后再重新解析。具体参考org.apache.catalina.webresources.Cache ，默认过期时间ttl是5000ms。
3、为什么本地不会复现
其实确切的说，是通过spring-boot打包插件后不能复现。由于启动方式的不同，tomcat使用了不同的类去处理静态资源，所以没问题
4、如何解决
升级tomcat-embed版本即可
通过替换springboot pom properties方式
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.2.RELEASE</version>
<relativePath/>
</parent>
<tomcat.version>8.5.40</tomcat.version>
</properties>
5、升级spring boot版本
springboot 2.1.0.RELEASE中的tomcat embed版本已经大于8.5.31了，所以直接将springboot升级至该版本及以上版本就可以解决此问题！