Tomcat打破双亲委派机制执行顺序底层代码原理JVM04_Tomcat JDBC破坏双亲委派机制带来的面试

Posted Java长源小智

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Tomcat打破双亲委派机制执行顺序底层代码原理JVM04_Tomcat JDBC破坏双亲委派机制带来的面试相关的知识,希望对你有一定的参考价值。

如果本篇文章对你有用,点赞支持,我是小智!感谢支持!

此次我们主要是针对双亲委派机制的打破,追溯Tomcat和JDBC是如何打破双亲委派机制的。

①. Tomcat类加载机制

  • ①. 可以看到,在原来的 JVM 的类加载机制上面,Tomcat 新增了几个类加载器,包括 3 个基础类加载器和每个 Web 应用的类加载器。3个基础类加载器在 conf/catalina.properties 中进行配置:

common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar"
server.loader=
shared.loader=
  • ②.Common:以应用类加载器为父类,是Tomcat顶层的公用类加载器,其路径由conf/catalina.pr operties中的common.loader指定,默认指向${catalina.home}/lib下的包

  • ③. Catalina:Tomcat容器私有的类加载器,加载路径中的class对于Webapp不 可见,其路径由server.loader指定,默认为空,此时Tomcat使用Common类加载器加载应用服务器

  • ④. Shared:以Common类加载器为父类,是所有Web应用的父类加载器,其路径由shared.loader指定,默认为空,此时Tomcat使用Common类加载器作为Web应用的父加载器

  • ⑤. Web应用:以Shared类加载器为父类,加载/WEB-INF/classes目录下的未压缩的Class和资源文件以及/WEB-INF/lib目录下的jar包,该类加载器只对当前Web应用可见,对其他Web应用均不可见

  • ⑥. Tomcat8 和 Tomcat6比较大的区别是:Tomcat8可以通过配置 <Loader delegate="true"/>表示遵循双亲委派机制

②. Tomcat执行顺序

  • ①. 使用bootstrap引导类加载器加载

  • ②. 使用system系统类加载器加载

  • ③. 使用应用类加载器在WEB-INF/classes中加载

  • ④. 使用应用类加载器在WEB-INF/lib中加载

  • ⑤. 使用common类加载器在CATALINA_HOME/lib中加载

  • ⑥.我们已经知道了tomcat为什么要这么设计,以及是如何设计的,那么,tomcat违背了java推荐的双亲委派模型了吗?答案是:违背了。我们前面说过:双亲委派模型要求除了顶层的启动类加载器之外,其余的类加载器都应当由自己的父类加载器加载。很显然,tomcat不是这样实现,tomcat为了实现隔离性,没有遵守这个约定,每个webappClassLoad er加载自己的目录下的class文件,不会传递给父类加载器。

③. ClassLoader的创建

  • ①. 加载器类图:

  • ②. 先从 BootStrap 的main方法看起:可以看到这里先判断了bootstrap是否为null,如果不为null直接把CatalinaClassLoader设置到了当前线程,如果为null下面是走到了init()方法

public static void main(String args[]) {
   synchronized (daemonLock) {
       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;
      } 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);
      }
       // 省略其余代码...
  }
}
  • ③. 接着这里看到了会调用 initClassLoaders() 方法进行类加载器的初始化,初始化完成后,同样会设置 Catalina ClassLoader到当前线程

public void init() throws Exception {
   // 初始化类加载器
   initClassLoaders();
   // 设置线程类加载器,将容器的加载器传入
   Thread.currentThread().setContextClassLoader(catalinaLoader);
   // 设置区安全类加载器
   SecurityClassLoad.securityClassLoad(catalinaLoader);
   // 省略其余代码...
}
  • ④ .看到这里应该就清楚了,会创建三个ClassLoader:CommClassLoader,CatalinaClassLoader,SharedCla ssLoader,正好对应前面介绍的三个基础类加载器

private void initClassLoaders() {
   try {
       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 = createClassLoader("server", commonLoader);
       sharedLoader = createClassLoader("shared", commonLoader);
  } catch (Throwable t) {
       handleThrowable(t);
       log.error("Class loader creation threw exception", t);
       System.exit(1);
  }
}
  • ⑤. 接着进入createClassLoader() 查看代码:可以看到,这里加载的资源正好是我们刚才看到的配置文件conf/catalina.properties 中的 common.loader ,server.loader 和 shared.loader

private ClassLoader createClassLoader(String name, ClassLoader parent)
   throws Exception {

   String value = CatalinaProperties.getProperty(name + ".loader");
   if ((value == null) || (value.equals("")))
       return parent;
   value = replace(value);
   List<Repository> repositories = new ArrayList<>();
   String[] repositoryPaths = getPaths(value);
   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);
}

④. ClassLoader加载过程

  • ①. 接打开 ParallelWebappClassLoader ,至于为啥不是看 WebappClassLoader ,从名字上就知道 ParallelW ebappClassLoader 是一个并行的 WebappClassLoader然后看下 ParallelWebappClassLoader 的 loadclass 方法是在它的父类 WebappClassLoaderBase 中实现的

 1 public Class loadClass(String name, boolean resolve)
2             throws ClassNotFoundException {
3         Class clazz = null;
4         // (0) 先从自己的缓存中查找,有则返回,无则继续
5         clazz = findLoadedClass0(name);
6         if (clazz != null) {
7             if (resolve) resolveClass(clazz);            
8             return (clazz);
9         }
10         // (0.1) 再从parent的缓存中查找
11         clazz = findLoadedClass(name);
12         if (clazz != null) {
13             if (resolve) resolveClass(clazz);
14             return (clazz);
15         }
16         // (0.2) 缓存中没有,则首先使用system类加载器来加载
17         clazz = system.loadClass(name);
18          if (clazz != null) {
19              if (resolve) resolveClass(clazz);
20              return (clazz);
21         }
22         //判断是否需要先让parent代理
23         boolean delegateLoad = delegate || filter(name);
24         // (1) 先让parent加载,通常delegateLoad == false,即这一步不会执行
25
26         if (delegateLoad) {
27             ClassLoader loader = parent;
28             if (loader == null)
29                 loader = system;
30             clazz = loader.loadClass(name);
31             if (clazz != null) {
32                 if (resolve) resolveClass(clazz);
33                 return (clazz);
34             }
35         }
36         // (2) delegateLoad == false 或者 parent加载失败,调用自身的加载机制
37         clazz = findClass(name);
38         if (clazz != null) {
39             if (resolve) resolveClass(clazz);
40             return (clazz);
41         }
42         // (3) 自己加载失败,则请求parent代理加载
43
44         if (!delegateLoad) {
45             ClassLoader loader = parent;
46             if (loader == null)
47                 loader = system;
48             clazz = loader.loadClass(name);
49             if (clazz != null) {
50                 return (clazz);
51             }
52         }
53         throw new ClassNotFoundException(name);
54     }
  •  ②. 总结如上源码:

  1. 先从缓存中加载(自己的缓存和父类中的缓存)

  2. 如果没有,则从JVM的Bootstrap类加载器加载;

  3. 如果没有,则从当前类加载器加载(按照 WEB-INF/classes 、 WEB-INF/lib 的顺序)

  4. 如果没有,则从父类加载器加载,由于父类加载器采用默认的委派模式,所以加载顺序是 AppClassLoader 、 Common 、 Shared 

⑤. Tomcat破坏双亲委派机制带来的面试题

  • ①. 既然Tomcat不遵循双亲委派机制,那么如果我自己定义一个恶意的HashMap,会不会有风险呢?(阿里面试问题)显然不会有风险,如果有,Tomcat都运行这么多年了,那能不改进吗? tomcat不遵循双亲委派机制,只是自定义的classLoader顺序不同,但顶层还是相同的,还是要去顶层请求classloader

  • ②. 我们思考一下:Tomcat是个web容器,那么它要解决什么问题?

  1. 一个web容器可能需要部署两个应用程序,不同的应用程序可能会依赖同一个第三方类库的不同版本,不能要求同一个类库在同一个服务器只有一份,因此要保证每个应用程序的类库都是独立的,保证相互隔离。

  2. 部署在同一个web容器中相同的类库相同的版本可以共享。否则,如果服务器有10个应用程序,那么要有10份相同的类库加载进虚拟机,这是扯淡的。

  3.  web容器也有自己依赖的类库,不能于应用程序的类库混淆。基于安全考虑,应该让容器的类库和程序的类库隔离开来。

  4. web容器要支持jsp的修改,我们知道,jsp文件最终也是要编译成class文件才能在虚拟机中运行,但程序运行后修改jsp已经是司空见惯的事情,否则要你何用?所以,web容器需要支持jsp修改后不用重启。

  • ③. Tomcat如果使用默认的类加载机制行不行?答案是不行的。为什么?我们看:第一个问题,如果使用默认的类加载器机制,那么是无法加载两个相同类库的不同版本的,默认的类加器是不管你是什么版本的,只在乎你的全限定类名,并且只有一份。第二个问题,默认的类加载器是能够实现的,因为他的职责就是保证唯一性。第三个问题和第一个问题一样。第四个问题,我们想我们要怎么实现jsp文件的热替换,jsp文件其实也就是class文件,那么如果修改了,但类名还是一样,类加载器会直接取方法区中已经存在的,修改后的jsp是不会重新加载的。那么怎么办呢?我们可以直接卸载掉这jsp文件的类加载器,所以你应该想到了,每个jsp文件对应一个唯一的类加载器,当一个jsp文件修改了,就直接卸载这个jsp类加载器。重新创建类加载器,重新加载jsp文件。

  • ④. 如果tomcat的CommonClassLoader想加载WebAppClassLoader中的类,该怎么办?看了前面的关于破坏双亲委派模型的内容,我们心里有数了,我们可以使用线程上下文类加载器实现,使用线程上下文加载器,可以让父类加载器请求子类加载器去完成类加载的动作。

  • ⑤. 为什么java文件放在Eclipse/IDEA中的src文件夹下会优先jar包中的class?tomcat类加载机制的理解,就不难明白。因为Eclipse/IDEA中的src文件夹中的文件java以及webContent中的JSP都会在tomcat启动时,被编译成class文件放在WEB-INF/class中。 而Eclipse/IDEA外部引用的jar包,则相当于放在WEB-INF/lib中。 因此肯定是java文件或者JSP文件编译出的class优先加载。

  • ⑥. 为什么JDBC需要打破双亲委派机制JDBC的Driver接口定义在JDK中,其实现由各个数据库的服务商来提供,比如mysql驱动包,DriverManager类中要加载各个实现了Driver接口的类,然后进行管理,也就是说BootStrap类加载器还要去加载jar包中的Driver接口的实现类,这就打破了双亲委派机制


以上是关于Tomcat打破双亲委派机制执行顺序底层代码原理JVM04_Tomcat JDBC破坏双亲委派机制带来的面试的主要内容,如果未能解决你的问题,请参考以下文章

Java双亲委派模型:为什么要双亲委派?如何打破它?破在哪里?

Java双亲委派模型:为什么要双亲委派?如何打破它?破在哪里?

Code皮皮虾带你盘点双亲委派机制原理优缺点,以及如何打破它?

Code皮皮虾带你盘点双亲委派机制原理优缺点,以及如何打破它?

从源码理解双亲委派机制,原来如此简单

tomcat打破双亲委派机制