在研究tomcat 类加载之前，我们复习一下或者说巩固一下java 默认的类加载器。楼主以前对类加载也是懵懵懂懂，借此机会，也好好复习一下。
楼主翻开了神书《深入理解java虚拟机》第二版，p227, 关于类加载器的部分。请看：
java虚拟机把描述类的数据从class文件加载进内存，并对数据进行校验，转换解析和初始化，最终形成可以呗虚拟机直接使用的java类型，这就是虚拟机的类加载机制。
虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这动作的代码模块成为“类加载器”。
类加载器虽然只用于实现类的加载动作，但它在java程序中起到的作用却远远不限于类加载阶段。对于任意一个类，都需要由加载他的类加载器和这个类本身一同确立其在java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类命名空间。这句话可以表达的更通俗一些：比较两个类是否“相等”，
只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来自同一个class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那这个两个类就必定不相等。
从java虚拟机的角度来说，只存在两种不同类加载器：一种是启动类加载器(bootstrap classloader)，这个类加载器使用c++语言实现（只限hotspot），是虚拟机自身的一部分；另一种就是所有其他的类加载器，这些类加载器都由java语言实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.classloader.
从java开发人员的角度来看，类加载还可以划分的更细致一些，绝大部分java程序员都会使用以下3种系统提供的类加载器：
这些类加载器之间的关系一般如下图所示：
类加载器的双亲委派模型在jdk1.2 期间被引入并被广泛应用于之后的所有java程序中，但他并不是个强制性的约束模型，而是java设计者推荐给开发者的一种类加载器实现方式。
双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，他首先不会自己去尝试加载这个类，而是把这个请求委派父类加载器去完成。每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个请求（他的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
如果没有使用双亲委派模型，由各个类加载器自行加载的话，如果用户自己编写了一个称为java.lang.object的类，并放在程序的classpath中，那系统将会出现多个不同的object类， java类型体系中最基础的行为就无法保证。应用程序也将会变得一片混乱。
非常简单：所有的代码都在java.lang.classloader中的loadclass方法之中，代码如下：
先检查是否已经被加载过，若没有加载则调用父加载器的loadclass方法， 如父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出classnotfoundexception 异常后，再调用自己的findclass方法进行加载。
双亲委任模型不是一个强制性的约束模型，而是一个建议型的类加载器实现方式。在java的世界中大部分的类加载器都遵循者模型，但也有例外，到目前为止，双亲委派模型有过3次大规模的“被破坏”的情况。
第一次：在双亲委派模型出现之前-----即jdk1.2发布之前。
第二次：是这个模型自身的缺陷导致的。我们说，双亲委派模型很好的解决了各个类加载器的基础类的统一问题（越基础的类由越上层的加载器进行加载），基础类之所以称为“基础”，是因为它们总是作为被用户代码调用的api， 但没有绝对，如果基础类调用会用户的代码怎么办呢？
这不是没有可能的。一个典型的例子就是jndi服务，jndi现在已经是java的标准服务，它的代码由启动类加载器去加载（在jdk1.3时就放进去的rt.jar）,但它需要调用由独立厂商实现并部署在应用程序的classpath下的jndi接口提供者（spi， service provider interface）的代码，但启动类加载器不可能“认识“这些代码啊。因为这些类不在rt.jar中，但是启动类加载器又需要加载。怎么办呢？
为了解决这个问题，java设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（thread context classloader）。这个类加载器可以通过java.lang.thread类的setcontextclassloader方法进行设置。如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过多的话，那这个类加载器默认即使应用程序类加载器。
嘿嘿，有了线程上下文加载器，jndi服务使用这个线程上下文加载器去加载所需要的spi代码，也就是父类加载器请求子类加载器去完成类加载的动作，这种行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器，实际上已经违背了双亲委派模型的一般性原则。但这无可奈何，java中所有涉及spi的加载动作基本胜都采用这种方式。例如jndi，jdbc，jce，jaxb，jbi等。
第三次：为了实现热插拔，热部署，模块化，意思是添加一个功能或减去一个功能不用重启，只需要把这模块连同类加载器一起换掉就实现了代码的热替换。
首先，我们来问个问题：
我们思考一下：tomcat是个web容器， 那么它要解决什么问题：
我们看看他们的设计图：
我们在这张图中看到很多类加载器，除了jdk自带的类加载器，我们尤其关心tomcat自身持有的类加载器。仔细一点我们很容易发现：catalina类加载器和shared类加载器，他们并不是父子关系，而是兄弟关系。为啥这样设计，我们得分析一下每个类加载器的用途，才能知晓。
tomcat启动的入口在bootstrap的main()方法。main()方法执行前，必然先执行其static{}块。所以我们首先分析static{}块，然后分析main()方法
我要评论static {
// 获取用户目录
// will always be non-null
string userdir = system.getproperty("user.dir");
// 第一步，从环境变量中获取catalina.home，在没有获取到的时候将执行后面的获取操作
// home first
string home = system.getproperty(globals.catalina_home_prop);
file homefile = null;
if (home != null) {
file f = new file(home);
try {
homefile = f.getcanonicalfile();
} catch (ioexception ioe) {
homefile = f.getabsolutefile();
}
}
// 第二步，在第一步没获取的时候，从bootstrap.jar所在目录的上一级目录获取
if (homefile == null) {
// first fall-back. see if current directory is a bin directory
// in a normal tomcat install
file bootstrapjar = new file(userdir, "bootstrap.jar");
if (bootstrapjar.exists()) {
file f = new file(userdir, "..");
try {
homefile = f.getcanonicalfile();
} catch (ioexception ioe) {
homefile = f.getabsolutefile();
}
}
}
// 第三步，第二步中的bootstrap.jar可能不存在，这时我们直接把user.dir作为我们的home目录
if (homefile == null) {
// second fall-back. use current directory
file f = new file(userdir);
try {
homefile = f.getcanonicalfile();
} catch (ioexception ioe) {
homefile = f.getabsolutefile();
}
}
// 重新设置catalinahome属性
catalinahomefile = homefile;
system.setproperty(
globals.catalina_home_prop, catalinahomefile.getpath());
// 接下来获取catalina_base（从系统变量中获取），若不存在，则将catalina_base保持和catalina_home相同
// then base
string base = system.getproperty(globals.catalina_base_prop);
if (base == null) {
catalinabasefile = catalinahomefile;
} else {
file basefile = new file(base);
try {
basefile = basefile.getcanonicalfile();
} catch (ioexception ioe) {
basefile = basefile.getabsolutefile();
}
catalinabasefile = basefile;
}
// 重新设置catalinabase属性
system.setproperty(
globals.catalina_base_prop, catalinabasefile.getpath());
}
我们把代码中的注释搬下来总结一下：
简单总结一下，就是加载并设置catalinahome和catalinabase相关的信息，以备后续使用。
main方法大体分成两块，一块为init，另一块为load+start。
public static void main(string args[]) {
// 第一块，main方法第一次执行的时候，daemon肯定为null，所以直接new了一个bootstrap对象，然后执行其init()方法
if (daemon == null) {
// don't set daemon until init() has completed
bootstrap bootstrap = new bootstrap();
try {
bootstrap.init();
} catch (throwable t) {
handlethrowable(t);
t.printstacktrace();
return;
}
// daemon守护对象设置为bootstrap
daemon = bootstrap;
} else {
// when running as a service the call to stop will be on a new
// thread so make sure the correct class loader is used to prevent
// a range of class not found exceptions.
thread.currentthread().setcontextclassloader(daemon.catalinaloader);
}
// 第二块，执行守护对象的load方法和start方法
try {
string command = "start";
if (args.length > 0) {
command = args[args.length - 1];
}
if (command.equals("startd")) {
args[args.length - 1] = "start";
daemon.load(args);
daemon.start();
} else if (command.equals("stopd")) {
args[args.length - 1] = "stop";
daemon.stop();
} else if (command.equals("start")) {
daemon.setawait(true);
daemon.load(args);
daemon.start();
if (null == daemon.getserver()) {
system.exit(1);
}
} else if (command.equals("stop")) {
daemon.stopserver(args);
} else if (command.equals("configtest")) {
daemon.load(args);
if (null == daemon.getserver()) {
system.exit(1);
}
system.exit(0);
} else {
log.warn("bootstrap: command \"" + command + "\" does not exist.");
}
} catch (throwable t) {
// unwrap the exception for clearer error reporting
if (t instanceof invocationtargetexception &&
t.getcause() != null) {
t = t.getcause();
}
handlethrowable(t);
t.printstacktrace();
system.exit(1);
}
}
我们点到init()里面去看看~
public void init() throws exception {
// 非常关键的地方，初始化类加载器s，后面我们会详细具体地分析这个方法
initclassloaders();
// 设置上下文类加载器为catalinaloader，这个类加载器负责加载tomcat专用的类
thread.currentthread().setcontextclassloader(catalinaloader);
// 暂时略过，后面会讲
securityclassload.securityclassload(catalinaloader);
// 使用catalinaloader加载我们的catalina类
// load our startup class and call its process() method
if (log.isdebugenabled())
log.debug("loading startup class");
class<?> startupclass = catalinaloader.loadclass("org.apache.catalina.startup.catalina");
object startupinstance = startupclass.getconstructor().newinstance();
// 设置catalina类的parentclassloader属性为sharedloader
// set the shared extensions class loader
if (log.isdebugenabled())
log.debug("setting startup class properties");
string methodname = "setparentclassloader";
class<?> paramtypes[] = new class[1];
paramtypes[0] = class.forname("java.lang.classloader");
object paramvalues[] = new object[1];
paramvalues[0] = sharedloader;
method method =
startupinstance.getclass().getmethod(methodname, paramtypes);
method.invoke(startupinstance, paramvalues);
// catalina守护对象为刚才使用catalinaloader加载类、并初始化出来的catalina对象
catalinadaemon = startupinstance;
}
关键的方法initclassloaders，这个方法负责初始化tomcat的类加载器。通过这个方法，我们很容易验证我们上一小节提到的tomcat类加载图。
private void initclassloaders() {
try {
// 创建commonloader，如果未创建成果的话，则使用应用程序类加载器作为commonloader
commonloader = createclassloader("common", null);
if( commonloader == null ) {
// no config file, default to this loader - we might be in a 'single' env.
commonloader=this.getclass().getclassloader();
}
// 创建catalinaloader，父类加载器为commonloader
catalinaloader = createclassloader("server", commonloader);
// 创建sharedloader，父类加载器为commonloader
sharedloader = createclassloader("shared", commonloader);
} catch (throwable t) {
// 如果创建的过程中出现异常了，日志记录完成之后直接系统退出
handlethrowable(t);
log.error("class loader creation threw exception", t);
system.exit(1);
}
}
createclassloader，所以，我们进一步分析一下这个方法。createclassloader用到了catalinaproperties.getproperty("xxx")方法，这个方法用于从conf/catalina.properties文件获取属性值。private classloader createclassloader(string name, classloader parent)
throws exception {
// 获取类加载器待加载的位置，如果为空，则不需要加载特定的位置，使用父类加载返回回去。
string value = catalinaproperties.getproperty(name + ".loader");
if ((value == null) || (value.equals("")))
return parent;
// 替换属性变量，比如：${catalina.base}、${catalina.home}
value = replace(value);
list<repository> repositories = new arraylist<>();
// 解析属性路径变量为仓库路径数组
string[] repositorypaths = getpaths(value);
// 对每个仓库路径进行repositories设置。我们可以把repositories看成一个个待加载的位置对象，可以是一个classes目录，一个jar文件目录等等
for (string repository : repositorypaths) {
// check for a jar url repository
try {
@suppresswarnings("unused")
url url = new url(repository);
repositories.add(
new repository(repository, repositorytype.url));
continue;
} catch (malformedurlexception e) {
// ignore
}
// local repository
if (repository.endswith("*.jar")) {
repository = repository.substring
(0, repository.length() - "*.jar".length());
repositories.add(
new repository(repository, repositorytype.glob));
} else if (repository.endswith(".jar")) {
repositories.add(
new repository(repository, repositorytype.jar));
} else {
repositories.add(
new repository(repository, repositorytype.dir));
}
}
// 使用类加载器工厂创建一个类加载器
return classloaderfactory.createclassloader(repositories, parent);
}
我们来分析一下classloaderfactory.createclassloader--类加载器工厂创建类加载器。
public static classloader createclassloader(list<repository> repositories,
final classloader parent)
throws exception {
if (log.isdebugenabled())
log.debug("creating new class loader");
// construct the "class path" for this class loader
set<url> set = new linkedhashset<>();
// 遍历repositories，对每个repository进行类型判断，并生成url，每个url我们都要校验其有效性，有效的url我们会放到url集合中
if (repositories != null) {
for (repository repository : repositories) {
if (repository.gettype() == repositorytype.url) {
url url = buildclassloaderurl(repository.getlocation());
if (log.isdebugenabled())
log.debug(" including url " + url);
set.add(url);
} else if (repository.gettype() == repositorytype.dir) {
file directory = new file(repository.getlocation());
directory = directory.getcanonicalfile();
if (!validatefile(directory, repositorytype.dir)) {
continue;
}
url url = buildclassloaderurl(directory);
if (log.isdebugenabled())
log.debug(" including directory " + url);
set.add(url);
} else if (repository.gettype() == repositorytype.jar) {
file file=new file(repository.getlocation());
file = file.getcanonicalfile();
if (!validatefile(file, repositorytype.jar)) {
continue;
}
url url = buildclassloaderurl(file);
if (log.isdebugenabled())
log.debug(" including jar file " + url);
set.add(url);
} else if (repository.gettype() == repositorytype.glob) {
file directory=new file(repository.getlocation());
directory = directory.getcanonicalfile();
if (!validatefile(directory, repositorytype.glob)) {
continue;
}
if (log.isdebugenabled())
log.debug(" including directory glob "
+ directory.getabsolutepath());
string filenames[] = directory.list();
if (filenames == null) {
continue;
}
for (int j = 0; j < filenames.length; j++) {
string filename = filenames[j].tolowercase(locale.english);
if (!filename.endswith(".jar"))
continue;
file file = new file(directory, filenames[j]);
file = file.getcanonicalfile();
if (!validatefile(file, repositorytype.jar)) {
continue;
}
if (log.isdebugenabled())
log.debug(" including glob jar file "
+ file.getabsolutepath());
url url = buildclassloaderurl(file);
set.add(url);
}
}
}
}
// construct the class loader itself
final url[] array = set.toarray(new url[set.size()]);
if (log.isdebugenabled())
for (int i = 0; i < array.length; i++) {
log.debug(" location " + i + " is " + array[i]);
}
// 从这儿看，最终所有的类加载器都是urlclassloader的对象~~
return accesscontroller.doprivileged(
new privilegedaction<urlclassloader>() {
@override
public urlclassloader run() {
if (parent == null)
return new urlclassloader(array);
else
return new urlclassloader(array, parent);
}
});
}
我们已经对initclassloaders分析完了，接下来分析securityclassload.securityclassload，我们看看里面做了什么事情
public static void securityclassload(classloader loader) throws exception {
securityclassload(loader, true);
}
static void securityclassload(classloader loader, boolean requiresecuritymanager) throws exception {
if (requiresecuritymanager && system.getsecuritymanager() == null) {
return;
}
loadcorepackage(loader);
loadcoyotepackage(loader);
loadloaderpackage(loader);
loadrealmpackage(loader);
loadservletspackage(loader);
loadsessionpackage(loader);
loadutilpackage(loader);
loadvalvespackage(loader);
loadjavaxpackage(loader);
loadconnectorpackage(loader);
loadtomcatpackage(loader);
}
private static final void loadcorepackage(classloader loader) throws exception {
final string basepackage = "org.apache.catalina.core.";
loader.loadclass(basepackage + "accesslogadapter");
loader.loadclass(basepackage + "applicationcontextfacade$privilegedexecutemethod");
loader.loadclass(basepackage + "applicationdispatcher$privilegedforward");
loader.loadclass(basepackage + "applicationdispatcher$privilegedinclude");
loader.loadclass(basepackage + "applicationpushbuilder");
loader.loadclass(basepackage + "asynccontextimpl");
loader.loadclass(basepackage + "asynccontextimpl$asyncrunnable");
loader.loadclass(basepackage + "asynccontextimpl$debugexception");
loader.loadclass(basepackage + "asynclistenerwrapper");
loader.loadclass(basepackage + "containerbase$privilegedaddchild");
loadanonymousinnerclasses(loader, basepackage + "defaultinstancemanager");
loader.loadclass(basepackage + "defaultinstancemanager$annotationcacheentry");
loader.loadclass(basepackage + "defaultinstancemanager$annotationcacheentrytype");
loader.loadclass(basepackage + "applicationhttprequest$attributenamesenumerator");
}
这儿其实就是使用catalinaloader加载tomcat源代码里面的各个专用类。我们大致罗列一下待加载的类所在的package：
好了，至此我们已经分析完了init里面涉及到的几个关键方法
到这儿，我们隐隐感觉到少分析了点什么！没错，就是webapp类加载器。整个启动过程分析下来，我们仍然没有看到这个类加载器。它又是在哪儿出现的呢？
我们知道webapp类加载器是web应用私有的，而每个web应用其实算是一个context，那么我们通过context的实现类应该可以发现。在tomcat中，context的默认实现为standardcontext，我们看看这个类的startinternal()方法，在这儿我们发现了我们感兴趣的webapp类加载器。
protected synchronized void startinternal() throws lifecycleexception {
if (getloader() == null) {
webapploader webapploader = new webapploader(getparentclassloader());
webapploader.setdelegate(getdelegate());
setloader(webapploader);
}
}
入口代码非常简单，就是webapploader不存在的时候创建一个，并调用setloader方法。
我们终于完整地分析完了tomcat的整个启动过程+类加载过程。也了解并学习了tomcat不同的类加载机制是为什么要这样设计，带来的附加作用又是怎样的。
如对本文有疑问， 点击进行留言回复！！
ScrollView和RecyclerView的滑动事件处理
配置JAVA环境+安装Android Studio全过程+踩坑记录
Android P Camera2当SD卡被拔出来自动切换到内部存储
android 多个edittext 判空监听 让Button动态是否可点击
Android开源项目滚轮选择器WheelPicker的基本用法总结
网友评论