前言
异常一个神奇的东西,让广大程序员对它人又爱又恨。
爱它,通过它能快速定位错误,经过层层磨难能学到很多逼坑大法。
恨他,快下班的时刻,周末的早晨,它踏着七彩云毫无征兆的来了。
![](https://cdn.nlark.com/yuque/0/2019/jpeg/285432/1576199524029-c49ba808-22aa-4366-99ed-9804c6194092.jpeg#align=left&display=inline&height=266&name=3.jpg&originHeight=266&originWidth=250&size=9544&status=done&style=none&width=250)
今天,要聊的是它的一项神技 : 辅助源码分析
。
对的,没有听错,它有此功效,只不过我们被恨冲昏了头脑,没看到它的美。
![](https://cdn.nlark.com/yuque/0/2019/gif/285432/1576205206611-31f1e903-d688-4c09-a378-d5791b4c65a3.gif#align=left&display=inline&height=200&name=%E9%99%8D%E9%BE%99.gif&originHeight=200&originWidth=200&size=6417&status=done&style=none&width=200)
前情铺垫
讲之前,先简要铺垫下需要用到的相关知识。
1
了解点jvm知识都应该知道每个线程有自己的JVM Stack,程序运行时,会将方法一个一个压入栈,即栈帧,执行完再弹出栈。如下图。不知道也没关系,现在你也知道了,这是第一点。
![](https://cdn.nlark.com/yuque/0/2019/png/285432/1576203647752-cd3e726b-3639-4664-b2bb-58623765d18e.png#align=left&display=inline&height=566&name=%E6%9C%AA%E5%91%BD%E5%90%8D%E6%96%87%E4%BB%B6.png&originHeight=566&originWidth=915&size=32924&status=done&style=none&width=915)
Java中获取线程的方法调用栈,可通过如下方式
public class Sample {
public static void main(String[] args) {
hello();
}
public static void hello(){
StackTraceElement[] traceElements = Thread.currentThread().getStackTrace();
for(StackTraceElement traceElement : traceElements){
System.err.println(traceElement.getMethodName());
}
}
}
输出结果如下:
getStackTrace
hello
main
可以看到,通上面图中的入栈过程是一致的,唯一区别是多了个getStackTrace的方法,因为我们在hello方法内部调用了。也会入栈。
2
上面说了,是每个线程有自己的方法栈,所以如果在一个线程调用了另一个线程,那么两个线程有各自的方法栈。不废话,上代码。
public class Sample {
public static void main(String[] args) {
hello();
System.err.println("--------------------");
new Thread(){
@Override
public void run() {
hello();
}
}.start();
}
public static void hello(){
StackTraceElement[] traceElements = Thread.currentThread().getStackTrace();
for(StackTraceElement traceElement : traceElements){
System.err.println("Thread:" + Thread.currentThread().getName() + " " + traceElement.getMethodName());
}
}
}
输出结果如下:
Thread:main getStackTrace
Thread:main hello
Thread:main main
--------------------
Thread:Thread-0 getStackTrace
Thread:Thread-0 hello
Thread:Thread-0 run
可以看到,分别在主线程和新开的线程中调用了hello方法,输出的调用栈是各自独立的。
3
如果程序出现异常,会从出现异常的方法沿着调用栈逐步往回找,直到找到捕获当前异常类型的代码块,然后输出异常信息。代码如下。
public class Sample {
public static void main(String[] args) {
hello();
}
public static void hello(){
int[] array = new int[0];
array[1] = 1;
}
}
方法执行后的异常如下
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1
at com.yuboon.fragment.exception.Sample.hello(Sample.java:15)
at com.yuboon.fragment.exception.Sample.main(Sample.java:10)
对比上面第一点的执行结果,是不是有些相似。
好了,基础知识先铺垫到这。
基于上面的铺垫,下来我们先快速试一把,看看效果。
小试牛刀
场景是这样的,不知到大家是否了解springboot启动时是如何加载嵌入的tomcat的,可能很多人专门看过,但估计这会也忘得差不多了。
下面我们利用异常来快速找到它的启动加载逻辑。
what ? 异常在哪呢,我正常启动也没异常啊。
是滴,正常启动是没有,那我能不能让它不正常启动呢?
一个正常的情况下,异常都是被动出现的,也就是非编码人员的主观意愿出来的。
现在我们要主动让它出来,让它来告诉我们一些真相。
![](https://cdn.nlark.com/yuque/0/2019/gif/285432/1576216445746-2f7cf54e-8ad1-46e7-8b80-6e376c9aacb0.gif)
怎么让springboot启动加载tomcat时出错,都在jar包里,也改不了代码啊,直接调试源码?还是debug。不急。
我来告诉大家一个最简单的方式,利用端口。也就是将tomcat的启动端口改成一个已经被使用的端口,比如说你电脑现在运行着一个mysql服务,那我就让tomcat监听3306端口,这样启动一定会报端口被占用异常。
来,我们试一下。将springboot配置文件中的服务端口改成3306,启动。
![](https://cdn.nlark.com/yuque/0/2019/png/285432/1576206710357-f744cd3e-78d6-4289-bffd-f93fc54e42ef.png#align=left&display=inline&height=35&name=image.png&originHeight=35&originWidth=109&size=1070&status=done&style=none&width=109)
哇哦,想要的异常出来了,多么熟悉的画面。
![](https://cdn.nlark.com/yuque/0/2019/png/285432/1576206904898-c2d28ec4-099d-43b1-9b98-08a872aeccbd.png#align=left&display=inline&height=413&name=image.png&originHeight=413&originWidth=1253&size=112116&status=done&style=none&width=1253)
先大概解释下这个异常信息,总体包含两段异常信息。
第一段是springboot启动时内部的异常栈信息,第二段是Tomcat内部加载的异常栈信息。
两者关系就是,因为Tomcat端口被占用,抛出了端口被占用异常,进而导致springboot启动异常。两段异常的衔接点就在整个异常信息的第一行和最后一行,即Connector.java:1008
Connector.java:1005
处。
图中蓝色标出的类是我们程序的运行起点。点进去看实际上就是run方法处出了异常。
@SpringBootApplication
public class FragmentExceptionApplicatioin {
public static void main(String[] args) {
SpringApplication.run(FragmentExceptionApplicatioin.class, args);
}
}
既然是分析springboot是如何加载tomcat的,那么主要分析第一段就OK了,第二段异常信息暂时就可以忽略。
下面我们仔细分析分析。回想前情铺垫里 [ 1 ][ 3 ] 部分的内容,再加上这个异常堆栈信息,我们就从这个中找到程序的执行顺序,进而分析出核心执行流程。找到源码内部的执行逻辑。
来一步步看下
经过上面的分析,实际上我们找到了程序运行的起点,即springboot的run方法。且称为起始位置
。
下面要找到终点,就是最上面的那一行,且称为终点位置
。
at org.apache.catalina.connector.Connector.startInternal(Connector.java:1008) ~[tomcat-embed-core-9.0.21.jar:9.0.21]
有了起点和终点,我们知道,两点之间,线段最短。哦,跑题了。
是有了起点和终点,执行过程不就在中间吗。
再一点点看,分析类图可以看到AbstractApplicationContext和ServletWebServerApplicationContext是父子类,所以将出现AbstractApplicationContext的地方都替换为为ServletWebServerApplicationContext,最终结合上面的异常栈,我们可以绘制出这么一张时序图。
![](https://cdn.nlark.com/yuque/0/2019/png/285432/1576230450975-69c4a5f3-3c1c-475d-8225-f12f1932577d.png#align=left&display=inline&height=440&name=tomcat.png&originHeight=440&originWidth=710&size=19113&status=done&style=none&width=710)
可以清楚的看到启动时加载的过程。如何?清不清楚。
简单组织语言表述一下主体流程,细节暂不展开描述。
应用启动的run方法调用了SpringApplication的一系列重载run方法之后
调用了SpringApplication的刷新上下文方法和刷新方法
再调用ServletWebServerApplicationContext的刷新方法
ServletWebServerApplicationContext刷新方法再调用内部的finishRefresh方法
finishRefresh调用内部的startWebServer方法
startWebServer内部调用TomcatWebServer的start方法启动
友情提醒
分析一个陌生框架的源码,切勿一头扎进细节,保你进去出来后一脸懵逼。应该先找到程序的执行主线,而找到主线的方法一个是官方文档的相关介绍,一个是debug,而最直接有效的莫过于利用异常栈。
大家可以找一款框架亲自试试看。
从此再也不怕面试官问我某某框架的执行原理了。
分析源码时有了这个主线,再去分析里面的细节就容易得多了。再也不怕debug进去后不知调用深浅,迷失在源码当中。
功法进阶
上面只是小试牛刀,下面再看一个例子,通过异常分析下springmvc的执行过程。
呀,这可怎么搞,上面造个启动异常,端口重用还想了半天,这个异常要怎么造。异常出在哪里才能看到完整的异常栈呢?
不急,根据上面的两点之间线段最短原理,那自然是找到程序执行的起始位置
和终点位置
了。
这个场景控制器起点貌似在调用端呀。比如pc端?移动端发了个请求过来,那里是起点呀,我去那里搞么。
要这么复杂,我也就不写这篇文章了。
妈妈呀,那怎么搞,我好像有点懵逼了呢!
![](https://cdn.nlark.com/yuque/0/2019/jpeg/285432/1576210633875-c92c878c-6d37-4b35-afe5-85eb882eea28.jpeg#align=left&display=inline&height=250&name=e18d20c94006dfe0-9eef65073f0f6be0-335c5fd1b4bae44534eef19e66fb248b.jpg&originHeight=250&originWidth=492&size=28254&status=done&style=none&width=492)
先看张草图
![](https://cdn.nlark.com/yuque/0/2019/png/285432/1576211079645-f5c642ab-33ee-4281-b400-c74a0799319f.png#align=left&display=inline&height=397&name=web%E8%AF%B7%E6%B1%82%E8%8D%89%E5%9B%BE.png&originHeight=397&originWidth=843&size=29258&status=done&style=none&width=843)
不管是nio bio 又或是aio,服务端最终执行请求,必然会分配一个线程去做。
既然分析的是springmvc处理过程,也就是说从浏览器到tomcat这段我们是不用管的,我们只需要分析服务端线程调用springmvc方法后执行的这一段就可以了。
爸爸呀,服务端执行这个在tomcat里面呀,我怎么找。
![](https://cdn.nlark.com/yuque/0/2019/gif/285432/1576211222838-435eb9bc-a811-4773-a2b1-f4f8aea4a753.gif#align=left&display=inline&height=264&name=%E7%88%B8%E7%88%B8%E5%8E%BB%E5%93%AA%E4%BA%86.gif&originHeight=264&originWidth=247&size=12082&status=done&style=none&width=247)
确实这么找,不好找。
上面说了先找到起点和终点,没说两个都要找到呀,既然起点在tomcat里不好找,那终点能找到吗?
我想想,终点难道是controller里的方法吗?
答对了,请求所抵达的终点就是controller里面声明的方法。
好的终点找到了,如何报错,一时脑袋懵逼,哎,还是不习惯主动写个异常,一时不知道代码怎么写。
好吧,那我们就用两行代码来主动造个异常,异常水平的高低不要求,能出错的异常就是好异常。嗯?好像是个病句,不重要。
@RequestMapping("/hello")
public String hello(String name){
String nullObject = null;
nullObject.toString();
return "hello : " + name;
}
OK,写完了,执行时第四行必报空指针错误,启动测试一下呗。
当当当当,看看,异常栈又来了,这次看着异常是否亲切了些。
![](https://cdn.nlark.com/yuque/0/2019/png/285432/1576211794199-70b8f192-5435-4f77-bc33-06583bc3cc56.png#align=left&display=inline&height=515&name=image.png&originHeight=515&originWidth=1169&size=158739&status=done&style=none&width=1169)
来分析一波,上面的草图中可以看到,线程中肯定会调用springmvc的代码,tomcat的一些处理我们可以忽略,直接从异常栈中找org,springframework包开头的类信息。可以看到FrameworkServlet
类是由tomcat进入springmvc框架的第一个类。调用它的是HttpServlet
,再顺着网上看,就可以看到DispatcherServlet
,在未使用springboot之前,我们使用springmvc框架还需要在web.xml中添加配置
<servlet>
<servlet-name>springmvc</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:spring-mvc.xml</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>springmvc</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
通过类关系分析,发现三者是继承关系,DispatcherServlet
为最终子类。所以在随后的异常栈分析中,我们可以使用子类去替换父类。也就是异常栈中出现FrameworkServlet、HttpServlet
均可使用DispatcherServlet
进行替换分析。
![](https://cdn.nlark.com/yuque/0/2019/png/285432/1576214519053-ac922926-b1ca-4339-bf1f-58f00380cd5c.png#align=left&display=inline&height=464&name=image.png&originHeight=464&originWidth=759&size=29141&status=done&style=none&width=759)
如此我们便找到了起始位置
,那接下来的问题就是顺着DispatcherServlet
继续往下分析。
下来需要确定真正的终点位置
,上面不是确定了吗?
上面所确定的终止位置并不是真正的终点位置
,看下面这段异常
![](https://cdn.nlark.com/yuque/0/2019/png/285432/1576217239759-ddfc121c-7820-4058-91e4-76d5d6de68b6.png#align=left&display=inline&height=69&name=image.png&originHeight=69&originWidth=742&size=16599&status=done&style=none&width=742)
发现是个反射调用的异常,那就可以知道Controller的方法是通过反射调用的,我们排除JDK自身存在BUG的这种问题,所以这里其实也可以忽略,那么真正的终点位置就是调用反射代码执行方法的那一行,在哪呢?在这
![](https://cdn.nlark.com/yuque/0/2019/png/285432/1576217255140-64a0fe2f-9306-4321-b36a-e281f4764879.png#align=left&display=inline&height=16&name=image.png&originHeight=16&originWidth=729&size=3775&status=done&style=none&width=729)
至此我们就可以锁定终点位置是InvocableHandlerMethod.doInvoke
。
那么剩下需要具体分析的过程如下图,也就是搞清楚这几个方法间的调用关系,处理逻辑,基本上就搞清楚了springmvc是如何接受处理一个请求的逻辑。
![](https://cdn.nlark.com/yuque/0/2019/png/285432/1576232005514-6c7f52cc-59dc-4a44-8da9-b407c04e8051.png#align=left&display=inline&height=227&name=image.png&originHeight=227&originWidth=1202&size=63737&status=done&style=none&width=1202)
再次分析处理类的类图图发现
RequestMappingHandlerAdapter为AbstractHandlerMethodAdapter的子类。
ServletInvocableHandlerMethod为InvocableHandlerMethod的子类。
同上面一样,存在父子关系,用最终子类替换父类进行分析。
所以异常栈中出现AbstractHandlerMethodAdapter的地方都可使用RequestMappingHandlerAdapter进行替换。
异常栈中出现InvocableHandlerMethod的地方都可使用ServletInvocableHandlerMethod进行替换。
结合起来画个时序图bstractHandlerMethodAdapt
![](https://cdn.nlark.com/yuque/0/2019/png/285432/1576234059199-5adcc4ea-750c-4e20-b323-ddcf3d9a3844.png#align=left&display=inline&height=593&name=springmvc.png&originHeight=593&originWidth=692&size=24827&status=done&style=none&width=692)
这样看执行过程是不清楚了许多。简要语言表述此处就免了。
回过头,在看下起始位置
![](https://cdn.nlark.com/yuque/0/2019/png/285432/1576215621078-15fbf8d6-e65e-4963-98cb-fd45b42f0fbf.png#align=left&display=inline&height=16&name=image.png&originHeight=16&originWidth=262&size=1858&status=done&style=none&width=262)
是个线程,回想前情铺垫里的第 [ 2 ] 点,这就合理的解释了为什么是线程开头,因为在tomcat处理请求时,开启了线程,这个线程它有自己的JVM Stack,而这个请求处理的起点便是该线程的run方法。
具体代码内部细节根据实际情况具体分析,需要注意的是子类上的方法有些继承自父类或直接调用的父类,分析的时候为了结构清晰我们将父类全部换成了子类,所以这个在具体分析代码的时候需要注意,直接看子类可能会找不到一些方法,需要结合父类去看,这里就不带大家一行一行去分析了,不然我该写到天亮去了,此文的关键是提供一种思路。
等等,这只是请求接受到处理,数据是如何组装返回前台的,响应处理呢? 怎么没看到,确实。这个流程里没有,那如何能看到请求响应的处理流程能,很简单,只需要在数据返回时造个异常就行了。怎么造?自己不妨琢磨琢磨先。
收工
希望通过此文能帮你在源码分析的道路上走的容易些,也希望大家在看到异常不光有恨意,还带有一丝丝爱意,那我写这篇文章的目的就达到了。
再送大家修炼此功法的三点关键秘诀
1
此功法法成功的关键是找到正确的异常栈输出位置,通常情况下是程序执行逻辑终点的那个方法。
2
多找几个框架,多找几个场景,去适应这种思路,所谓孰能生巧。
3
注意抽象类和其子类,分析时出现抽象类的地方都可使用子类进行替换
友情提醒
此功法还可用在项目业务场景下,刚接手了新的项目,不知如何下手,找不到执行逻辑?debug半天还是没有头绪,不妨试试此法。
它踩着七彩云走了,留给我们无尽的遐想。不行,我得赶紧找个框架试一波。
此文风,第一次尝试,如果觉得不错不妨动动手指点个小赞,鼓励下作者,我会努力多写几篇。
如果觉得一般,么关系,我还有屌丝系列,少女系列,油腻男系列等风格。
此文结束,然而精彩故事未完……..