Tomcat源码阅读之Bootstrap启动流程与classLoader设计

嗯，以前大体上看过jetty6.0的源码，算是对java EE应用容器有了一定的了解，但是在实际的线上环境中应用的最多的应该还是tomcat，而且据说性能方面tomcat也略好一些。。。那么就趁着现在还比较闲就看看它的源码吧。。。

首先在实际开始之前先来说说tomcat对ClassLoader方面的处理。。。当然这部分是参考了网络上其他的人的博客。。。

一般情况下java应用程序的classLoader父子关系大概如下：

具体他们之间的关系以及作用我前面的博客都有说过。。。 那么作为应用容器，因为可能要同时容纳多个应用，为了实现各个应用之间的隔离，那么就需要由专门的classLoader来加载个个应用自己的代码，这部分jetty的处理方式是为每一个web应用程序都创建一个自己的classLoader，这个web应用程序需要用到的所有代码都有这个classLoader来处理。。。其实还蛮简单的。。。但是有一个缺点就是一些公有的代码每个web应用程序都会重复加载，会造成一些浪费吧。。。。例如defaultservlet啥的。。。但是优点就是简单。。。

在这方面，tomcat的设计就稍微复杂了一点点。。。父子关系如下图：

这里可以每个web应用程序也有自己专属的classLoader，也就是最下层的AppClassLoader。。。

这里可以看到总的来说classLoader分成了两条线，左边那条线是tomcat服务器用的，右边的则是web应用程序用的。。。。。嗯，其实也不复杂。。。。

好了，上面的内容算是对tomcat的classLoader有了比较简单的了解。。那么接下来来看看整个tomcat服务器的启动类Bootstrap类型是怎么工作的吧。。。。

先来看看它的几个静态属性的定义：

    private static Bootstrap daemon = null;   //当前类型的一个引用

    //这两个其实一般都被赋值为tomcat的根路径
    private static final File catalinaBaseFile;  
    private static final File catalinaHomeFile;

    private static final Pattern PATH_PATTERN = Pattern.compile("(\".*?\")|(([^,])*)");  //正则表达式验证

前面其实就是一个本身类型对象的一个引用，后面两个