转载

[ Coding七十二绝技 ] 如何利用Java异常快速分析源码

前言

异常一个神奇的东西，让广大程序员对它人又爱又恨。

爱它，通过它能快速定位错误，经过层层磨难能学到很多逼坑大法。

恨他，快下班的时刻，周末的早晨，它踏着七彩云毫无征兆的来了。

今天，要聊的是它的一项神技 : 辅助源码分析 。

对的，没有听错，它有此功效，只不过我们被恨冲昏了头脑，没看到它的美。

前情铺垫

讲之前，先简要铺垫下需要用到的相关知识。

1

了解点jvm知识都应该知道每个线程有自己的JVM Stack，程序运行时，会将方法一个一个压入栈，即栈帧，执行完再弹出栈。如下图。不知道也没关系，现在你也知道了，这是第一点。

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 ? 异常在哪呢，我正常启动也没异常啊。

是滴，正常启动是没有，那我能不能让它不正常启动呢？

一个正常的情况下，异常都是被动出现的，也就是非编码人员的主观意愿出来的。

现在我们要主动让它出来，让它来告诉我们一些真相。

怎么让springboot启动加载tomcat时出错，都在jar包里，也改不了代码啊，直接调试源码？还是debug。不急。

我来告诉大家一个最简单的方式，利用端口。也就是将tomcat的启动端口改成一个已经被使用的端口，比如说你电脑现在运行着一个mysql服务，那我就让tomcat监听3306端口，这样启动一定会报端口被占用异常。

来，我们试一下。将springboot配置文件中的服务端口改成3306，启动。

哇哦，想要的异常出来了，多么熟悉的画面。

先大概解释下这个异常信息，总体包含两段异常信息。

第一段是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，最终结合上面的异常栈，我们可以绘制出这么一张时序图。

可以清楚的看到启动时加载的过程。如何？清不清楚。

简单组织语言表述一下主体流程，细节暂不展开描述。

应用启动的run方法调用了SpringApplication的一系列重载run方法之后
调用了SpringApplication的刷新上下文方法和刷新方法
再调用ServletWebServerApplicationContext的刷新方法
ServletWebServerApplicationContext刷新方法再调用内部的finishRefresh方法
finishRefresh调用内部的startWebServer方法
startWebServer内部调用TomcatWebServer的start方法启动

友情提醒

分析一个陌生框架的源码，切勿一头扎进细节，保你进去出来后一脸懵逼。应该先找到程序的执行主线，而找到主线的方法一个是官方文档的相关介绍，一个是debug，而最直接有效的莫过于利用异常栈。

大家可以找一款框架亲自试试看。

从此再也不怕面试官问我某某框架的执行原理了。

分析源码时有了这个主线，再去分析里面的细节就容易得多了。再也不怕debug进去后不知调用深浅，迷失在源码当中。

功法进阶

上面只是小试牛刀，下面再看一个例子，通过异常分析下springmvc的执行过程。

呀，这可怎么搞，上面造个启动异常，端口重用还想了半天，这个异常要怎么造。异常出在哪里才能看到完整的异常栈呢？

不急，根据上面的两点之间线段最短原理，那自然是找到程序执行的 起始位置 和 终点位置 了。

这个场景控制器起点貌似在调用端呀。比如pc端？移动端发了个请求过来，那里是起点呀，我去那里搞么。

要这么复杂，我也就不写这篇文章了。

妈妈呀，那怎么搞，我好像有点懵逼了呢！

先看张草图

不管是nio bio 又或是aio，服务端最终执行请求，必然会分配一个线程去做。

既然分析的是springmvc处理过程，也就是说从浏览器到tomcat这段我们是不用管的，我们只需要分析服务端线程调用springmvc方法后执行的这一段就可以了。

爸爸呀，服务端执行这个在tomcat里面呀，我怎么找。

确实这么找，不好找。

上面说了先找到起点和终点，没说两个都要找到呀，既然起点在tomcat里不好找，那终点能找到吗？

我想想，终点难道是controller里的方法吗？

答对了，请求所抵达的终点就是controller里面声明的方法。

好的终点找到了，如何报错，一时脑袋懵逼，哎，还是不习惯主动写个异常，一时不知道代码怎么写。

好吧，那我们就用两行代码来主动造个异常，异常水平的高低不要求，能出错的异常就是好异常。嗯？好像是个病句，不重要。

@RequestMapping("/hello")
public String hello(String name){
        String nullObject = null;
        nullObject.toString();
        return "hello : " + name;
}

OK，写完了，执行时第四行必报空指针错误，启动测试一下呗。

当当当当，看看，异常栈又来了，这次看着异常是否亲切了些。

来分析一波，上面的草图中可以看到，线程中肯定会调用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 进行替换分析。

如此我们便找到了 起始位置 ，那接下来的问题就是顺着 DispatcherServlet 继续往下分析。

下来需要确定真正的 终点位置 ，上面不是确定了吗？

上面所确定的终止位置并不是真正的 终点位置 ，看下面这段异常

发现是个反射调用的异常，那就可以知道Controller的方法是通过反射调用的，我们排除JDK自身存在BUG的这种问题，所以这里其实也可以忽略，那么真正的终点位置就是调用反射代码执行方法的那一行，在哪呢？在这

至此我们就可以锁定终点位置是 InvocableHandlerMethod.doInvoke 。

那么剩下需要具体分析的过程如下图，也就是搞清楚这几个方法间的调用关系，处理逻辑，基本上就搞清楚了springmvc是如何接受处理一个请求的逻辑。

再次分析处理类的类图图发现

RequestMappingHandlerAdapter为AbstractHandlerMethodAdapter的子类。

ServletInvocableHandlerMethod为InvocableHandlerMethod的子类。

同上面一样，存在父子关系，用最终子类替换父类进行分析。

所以异常栈中出现AbstractHandlerMethodAdapter的地方都可使用RequestMappingHandlerAdapter进行替换。

异常栈中出现InvocableHandlerMethod的地方都可使用ServletInvocableHandlerMethod进行替换。

结合起来画个时序图bstractHandlerMethodAdapt

这样看执行过程是不清楚了许多。简要语言表述此处就免了。

回过头，在看下起始位置

是个线程，回想前情铺垫里的第 [ 2 ] 点，这就合理的解释了为什么是线程开头，因为在tomcat处理请求时，开启了线程，这个线程它有自己的JVM Stack，而这个请求处理的起点便是该线程的run方法。

具体代码内部细节根据实际情况具体分析，需要注意的是子类上的方法有些继承自父类或直接调用的父类，分析的时候为了结构清晰我们将父类全部换成了子类，所以这个在具体分析代码的时候需要注意， 直接看子类可能会找不到一些方法，需要结合父类去看 ，这里就不带大家一行一行去分析了，不然我该写到天亮去了，此文的关键是提供一种思路。

等等，这只是请求接受到处理，数据是如何组装返回前台的，响应处理呢？怎么没看到，确实。这个流程里没有，那如何能看到请求响应的处理流程能，很简单，只需要在数据返回时造个异常就行了。怎么造？自己不妨琢磨琢磨先。