亲宝软件园·资讯

展开

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

风象南 人气:1

前言

异常一个神奇的东西,让广大程序员对它人又爱又恨。
爱它,通过它能快速定位错误,经过层层磨难能学到很多逼坑大法。
恨他,快下班的时刻,周末的早晨,它踏着七彩云毫无征兆的来了。

今天,要聊的是它的一项神技 : 辅助源码分析
对的,没有听错,它有此功效,只不过我们被恨冲昏了头脑,没看到它的美。

前情铺垫

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

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方法。

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

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

收工

希望通过此文能帮你在源码分析的道路上走的容易些,也希望大家在看到异常不光有恨意,还带有一丝丝爱意,那我写这篇文章的目的就达到了。

再送大家修炼此功法的三点关键秘诀

1

此功法法成功的关键是找到正确的异常栈输出位置,通常情况下是程序执行逻辑终点的那个方法。

2

多找几个框架,多找几个场景,去适应这种思路,所谓孰能生巧。

3

注意抽象类和其子类,分析时出现抽象类的地方都可使用子类进行替换

友情提醒
此功法还可用在项目业务场景下,刚接手了新的项目,不知如何下手,找不到执行逻辑?debug半天还是没有头绪,不妨试试此法。

它踩着七彩云走了,留给我们无尽的遐想。不行,我得赶紧找个框架试一波。

此文风,第一次尝试,如果觉得不错不妨动动手指点个小赞,鼓励下作者,我会努力多写几篇。

如果觉得一般,么关系,我还有屌丝系列,少女系列,油腻男系列等风格。

此文结束,然而精彩故事未完……..

加载全部内容

相关教程
猜你喜欢
用户评论