TOMCAT源码调试入口是Bootstrap类的main方法，我的启动参数VM：
-Dcatalina.home=E:/Tomcat_Source_Code/apache-tomcat-8.0.53-src/catalina-home
-Dcatalina.base=E:/Tomcat_Source_Code/apache-tomcat-8.0.53-src/catalina-home
-Djava.endorsed.dirs=E:/Tomcat_Source_Code/apache-tomcat-8.0.53-src/catalina-home/endorsed
-Djava.io.tmpdir=E:/Tomcat_Source_Code/apache-tomcat-8.0.53-src/catalina-home/temp
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=E:/Tomcat_Source_Code/apache-tomcat-8.0.53-src/catalina-home/conf/logging.properties
Bootstrap执行main方法之前，先来看下static静态代码块做了哪些：
从当前系统变量、VM参数中获取 catalina.home作为 Bootstrap的 catalinaHomeFile，从系统变量、VM参数中获取catalina.base作为Bootstrap的catalinaBaseFile ， 一般catalina.home和catalina.base 都指向同一个目录
main方法作为Bootstrap的入口，做了以下几个操作：实例化一个Bootstrap，并且调用Bootstrap的init，将Bootstrap实例赋给daemon属性；Bootstrap实例分别调用setAwait(true)、load、start方法；
Bootstrap实例初始化
简单描述下Boostrap初始化完成工作： 初始化类加载器、实例化Catalina、反射调用Catalina实例setParentClassLoader、Bootstrap持有Catalina实例。
一.初始化类加载器
这是Tomcat8.0官网中对ClassLoader的描述 Tomcat ClassLoader官网 ，Common就是此处的commonLoader, 至于下面还有两个 catalinaLoader 以及sharedLoader，为什么在8.0的源码中还存在呢？历史遗留问题，在Tomcat6.0以前的版本，类加载器结构是这样的 Tomcat5.5官网 。 所以在Tomcat6.0后仍然保留catalinaLoader、sharedLoader，只不过会发现他们指向commonLoader而已。
创建commonLoader类加载器
CatalinaProperties类静态代码块按照一下顺序尝试加载properties文件：从环境变量中读取catalina.config 、 或者catalina-home/conf/catalina.properties、或包org/apache/catalina/startup下catalina.properties，读取key-value并且通过System.setProperty保存在内存中，默认catalina-home/conf/catalina.properties文件中common.loader内容如下
common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar"
使用replace方法将${catalina.base}替换成之前系统变量、VM参数中读取的catalina.base，将${catalina.home}替换成读取到的catalina.home；
getPaths方法再讲上面拆分成字符数组，catalina.home/lib 、catalina.home/lib/*.jar ，因为catalina.home和catalina.base是一样的；
将上面得到路径实例化成Repository，仓库的意思，比如catalina.home/lib 就是RepositoryType.DIR目录类型仓库，catalina.home/lib/*.jar就是RepositoryType.GLOB全局类型仓库，
利用仓库实例化URLClassLoader，比如DIR目录类型的仓库，校验catalina.home/lib是否存在、是否可读、是不是目录，之后通过file://路径构件URL统一资源定位符；比如GLOB类型仓库，遍历
catalina.home/lib下所有jar,每一个jar文件构造一个URL，最后得到new URLClassLoader(URL[] urls).
总结commonLoader：就是加载catalina.home下lib包中所有jar文件，而catalinaLoader、sharedLoader在Tomca6.0就都指向commonLoader了！
二.Catalina实例化
setSecurityProtection方法给Catalina的package.definition以及package.access属性赋值，这两个包定义、包访问属性来自于catalina.home/conf/catalina.propreties
实例化完成之后，通过反射调用Catalina的setParentClassLoader方法，参数为sharedLoader,沿用了Tomcat6.0之前，但是Tomcat6之后取消了sharedLoader以及catalinaLoader, 都是CommonLoader. 接着让Bootstrap关联Catalina实例，放在Bootstrap实例daemon的catalinaDaemon属性里。
Bootstrap加载、启动
Bootstrap实例加载之前，会调用setAwait方法， 上面Boostrap实例daemon持有catalinaDaemon，这里通过反射调用catalinaDaemon的setAwait为true，目的是为了让Tomcat程序处于运行状态，接收HTTP请求，一旦设置为false，Tomcat容器只是启动运行一遍就停止，所以说这一步不得不设置标志位！
Bootstrap加载load
bootstrap实例daemon只是作为一个辅助启动类，load方法也是如此，通过反射调用catalinaDaemon的load方法。Catalina实例的load篇幅比较长，下一篇博文记录。
Bootstrap启动start
Bootstrap作为辅助类，可以说相当尽心尽力了，启动Tomcat也是通过反射交给Catalina实例的start方法来完成。
总结
Tomcat的加载配置文件、启动过程都不是在Bootstrap中完成，都是通过Bootstrap反射调用Catalina实例的load、start方法，来完成Tomcat容器的启动。
而我觉得Bootstrap到这一步最大的作用，在于实例化commonLoader,通过加载catalina.properties文件中的的common.loader;创建了一个CommonLoader，赋给Catalina作为parentClassLoader。