实战分享:Tomcat打破双亲委派模型,实现Web应用独立与安全隔离的奥秘

目录

一、JVM 类加载机制

二、Tomcat 类加载器

2.2 findClass 介绍

3.2 loadClass 介绍

三、web应用隔离

3.1 Spring 加载问题


在开始文章内容之前,先来看三个问题

  1. 假如在 Tomcat 上运行了两个 Web 应用程序,两个 web 应用中有同名的Servlet,比如都叫UserController,但是功能不同,Tomcat 需要同时加载和管理这两个同名的 Servlet 类,保证他们不会冲突,那怎么才能实现隔离?
  2. 假如两个 web 应用都依赖同一个第三方 jar 包,比如spring,那 spring 的 jar 包被加载到内存后,Tomcat 保证这两个 web 应用能共享,也就是说 spring 的 jar 包只被加载一次,否则随着依赖第三方的增多,JVM的内存会爆炸,这时怎么做到的?
  3. 跟JVM一样,怎样隔离 Tomcat 本身和 web 应用类?

以上三个问题本文会逐一来讲解,下面先来看下 JVM 的类加载机制。

一、JVM 类加载机制

Java 的类加载就是把字节码格式 “.class” 文件加载到 JVM 方法区,并在 JVM 的堆中建立一个 java.lang.class
对象实例,用来封装 Java 类相关的数据和方法。

JVM 并不是在启动时就把所有的 “.class” 文件都加载一遍,而是程序在运行过程中用到了这个类才去加载。JVM 类加载是由类加载器来完成的,JDK
提供一个抽象类 ClassLoader,这个抽象类中定义了三个关键方法理解清楚他们的作用和关系非常重要。

  • JVM 的类加载器是有层次结构的,他们有父子关系,每个类加载器都有一个 parent 字段,指向父类加载器

  • defineClass 是个工具方法,它的职责是调用 native 方法把 Java 类的字节码解析成一个Class 对象,所谓的 native 方法就是由C语言实现的方法,Java通过 JNI 机制调用

  • findClass 方法的主要职责就是找到 “.class” 文件,可能来自文件系统或者网络,找到后把“.class” 文件读到内存得到字节码,然后调用 defineClass 方法获得 Class 对象

  • loadClass 是个 public 方法,说明它才是对外提供服务的接口,具体实现也比较清晰:首先检查这个类是不是已经被加载过了,如果加载过了直接返回,否则交给父加载器去加载。注意,这是一个递归调用,也就是说子加载器持有父加载器的引用,当一个类加载器需要加载一个 Java 类时,会先委托父加载器去加载,然后父加载器在自己的加载路径中搜索 Java 类,当父加载器在自己的加载范围内找不到时,才会交还给子加载器加载,这就是双亲委托机制。

    public abstract class ClassLoader {

    // 每个类加载器都有个父加载器
    private final ClassLoader parent;
    
    public Class<?> loadClass(String name) {
        // 查找一下这个类是不是已经加载过了
        Class<?> c = findLoadedClass(name);
        
        // 如果没有加载过
        if( c == null ){
          // 先委托给父加载器去加载,注意这是个递归调用
          if (parent != null) {
              c = parent.loadClass(name);
          } else {
              // 如果父加载器为空,查找Bootstrap加载器是不是加载过了
              c = findBootstrapClassOrNull(name);
          }
        }
        // 如果父加载器没加载成功,调用自己的findClass去加载
        if (c == null) {
            c = findClass(name);
        }
        
        return c;
    }
    
    protected Class<?> findClass(String name){
       //1. 根据传入的类名name,到在特定目录下去寻找类文件,把.class文件读入内存
          ...
          
       //2. 调用defineClass将字节数组转成Class对象
       return defineClass(buf, off, len);
    }
    
    // 将字节码数组解析成一个Class对象,用native方法实现
    protected final Class<?> defineClass(byte[] b, int off, int len){
       ...
    }
    

    }

JVM 双亲委派如图

  • BootstrapClassLoader 是启动类加载器,由 C 语言实现,用来加载 JVM 启动时所需要的核心类,比如 rt.jar、resource.jar 等。
  • ExtClassLoader 是扩展类加载器,用来接在 \jre\lib\ext 目录下的 jar 包。
  • AppClassLoader 是系统类加载器,用来加载 classpath 下的类,应用程序默认用它来加载类。
  • 自定义类加载器,用来加载自定义路径下的类。

这些类加载器的工作原理是一样的,区别是他们的加载路径不同,也就是说 findClass 这个方法查找的路径不同。双亲委派机制是为了保证一个 Java 类在
JVM 中是唯一的,假如不小心写了一个与 JRE 核心类同名的类,比如 Object 类,双亲委派机制能保证加载的是 JRE 里的那个Object
类,而不是你自己写的 Object 类。这是因为 AppClassLoader 在加载你的 Object 类时,会委托给 ExtClassLoader
去加载,而 ExtClassLoader 又会委托给 BootstrapClassLoader,BootstrapClassLoader
发现自己已经加载过了 Object 类,会直接返回,不会去加载你写的 Object 类。

注意,类加载器的父子关系不是通过继承来实现的,比如 AppClassLoader 并不是 ExtClassLoader 的子类,而是说
AppClassLoader 的 parent 成员变量指向 ExtClassLoader 对象。

二、Tomcat 类加载器

Tomca t的自定义类加载器 WebAppClassLoader
打破了双亲委派机制,首先自己尝试去加载某个类,如果找不到再代理给父类加载器,其目的是优先加载 Web 应用自己定义的类。具体实现就是重写
ClassLoader 的两个方法:findClass 和 loadClass。看下下面的源码

2.2 findClass 介绍

public Class<?> findClass(String name) throws ClassNotFoundException {
    ...
    
    Class<?> clazz = null;
    try {
            //1. 先在Web应用目录下查找类 
            clazz = findClassInternal(name);
    }  catch (RuntimeException e) {
           throw e;
       }
    
    if (clazz == null) {
    try {
            //2. 如果在本地目录没有找到,交给父加载器去查找
            clazz = super.findClass(name);
    }  catch (RuntimeException e) {
           throw e;
       }
    
    //3. 如果父类也没找到,抛出ClassNotFoundException
    if (clazz == null) {
        throw new ClassNotFoundException(name);
     }

    return clazz;
}

在 findClass 方法里,主要有三个步骤:

  1. 先在 Web 应用本地目录下查找要加载的类。
  2. 如果没有找到,交给父加载器去查找,它的父加载器就是上面提到的系统类加载器 AppClassLoader。
  3. 如果父加载器也没找到这个类,抛出 ClassNotFound 异常。

3.2 loadClass 介绍

public Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        Class<?> clazz = null;

        //1. 先在本地cache查找该类是否已经加载过
        clazz = findLoadedClass0(name);
        if (clazz != null) {
            if (resolve)
                resolveClass(clazz);
            return clazz;
        }

        //2. 从系统类加载器的cache中查找是否加载过
        clazz = findLoadedClass(name);
        if (clazz != null) {
            if (resolve)
                resolveClass(clazz);
            return clazz;
        }

        // 3. 尝试用ExtClassLoader类加载器类加载,为什么?
        ClassLoader javaseLoader = getJavaseClassLoader();
        try {
            clazz = javaseLoader.loadClass(name);
            if (clazz != null) {
                if (resolve)
                    resolveClass(clazz);
                return clazz;
            }
        } catch (ClassNotFoundException e) {
            // Ignore
        }

        // 4. 尝试在本地目录搜索class并加载
        try {
            clazz = findClass(name);
            if (clazz != null) {
                if (resolve)
                    resolveClass(clazz);
                return clazz;
            }
        } catch (ClassNotFoundException e) {
            // Ignore
        }

        // 5. 尝试用系统类加载器(也就是AppClassLoader)来加载
            try {
                clazz = Class.forName(name, false, parent);
                if (clazz != null) {
                    if (resolve)
                        resolveClass(clazz);
                    return clazz;
                }
            } catch (ClassNotFoundException e) {
                // Ignore
            }
       }
    
    //6. 上述过程都加载失败,抛出异常
    throw new ClassNotFoundException(name);
}

loadClass 方法稍微复杂一点,主要有六个步骤:

  1. 先在本地 Cache 查找该类是否已经加载过,也就是说 Tomcat 的类加载器是否已经加载过这个类。
  2. 如果 Tomcat 类加载器没有加载过这个类,再看看系统类加载器是否加载过。
  3. 如果都没有,就让 ExtClassLoader 去加载,这一步比较关键,目的防止 Web 应用自己的类覆盖 JRE 的核心类。因为 Tomcat 需要打破双亲委派机制,假如 Web 应用里自定义了一个叫 Object 的类,如果先加载这个 Object 类,就会覆盖 JRE 里面的那个 Object 类,这就是为什么 Tomcat 的类加载器会优先尝试用 ExtClassLoader 去加载,因为 ExtClassLoader 会委托给 BootstrapClassLoader 去加载,BootstrapClassLoader 发现自己已经加载了 Object 类,直接返回给 Tomcat 的类加载器,这样 Tomcat 的类加载器就不会去加载 Web 应用下的 Object 类了,也就避免了覆盖 JRE 核心类的问题。
  4. 如果 ExtClassLoader 加载器加载失败,也就是说 JRE 核心类中没有这类,那么就在本地 Web 应用目录下查找并加载。
  5. 如果本地目录下没有这个类,说明不是 Web 应用自己定义的类,那么由系统类加载器去加载。这里请你注意,Web 应用是通过Class.forName调用交给系统类加载器的,因为Class.forName的默认加载器就是系统类加载器。
  6. 如果上述加载过程全部失败,抛出 ClassNotFound 异常。

Tomcat 的类加载器打破了双亲委派机制,没有一上来就直接委托给父加载器,而是先在本地目录下加载,为了避免本地目录下的类覆盖 JRE 的核心类,先尝试用
JVM 扩展类加载器 ExtClassLoader 去加载。

三、web应用隔离

先回答开头提到的 第一个问题 ,如果我们使用 JVM 的 AppClassLoader 来加载 web 应用,AppClassLoader
只能加载一个 Servlet,再加载第二个同名的 Servlet 时,会返回第一个加载的
Servlet,同名的只被加载一次。Tomcat的解决方案是自定义一个类加载器 WebAppClassLoader,并且给每个 web
应用创建一个类加载器。不同的类加载器加载的类被认为是不同的类,即使名称相同,web 应用通过各自的类加载器来实现隔离。

在来看 第二个问题 ,多个 web
应用之间需要共享类库,并且不能重复加载相同的类。在双亲委派机制里,各个子加载器都可以通过父加载器去加载类,那么把需要共享的类放到父加载器的加载路径下不就行了吗,应用程序也是通过这种方式共享
JRE 核心类。因此 Tomcat 的设计者又加了一个类加载器 SharedClassLoader,作为 WebAppClassLoader
的父加载器,专门来加载web 应用之间共享的类。如果 WebAppClassLoader
自己没有加载到某个类,就会委托父加载器SharedClassLoader 去加载这个类,SharedClassLoader
会在指定目录下加载共享类,之后返回给 WebAppClassLoader,这样共享的问题就结局了。

第三个问题 ,如何隔离 Tomcat 本身的类和 web
应用的类?要共享可以通过父子关系,要隔离那就需要兄弟关系了。兄弟关系就是指两个类加载器是平行的,他们可能拥有同一个父加载器,但是两个兄弟类加载器加载的类是隔离的。因此
Tomcat 又设计了一个类加载器CatalinaClassLoader,专门来加载 Tomcat 自身的类,这样设计有个问题,那 Tomcat 和 web
需要共享一些类时怎么办呢?

还是再增加一个 CommonClassLoader,作为 CatalinaClassLoader 和 SharedClassLoader
的父加载器。CommonClassLoader 能加载的类都可以被 CatalinaClassLoader 和 SharedClassLoader 使用,而
CatalinaClassLoader 和 SharedClassLoader 能加载的类则与对方相互隔离。WebAppClassLoader 可以使用
SharedClassLoader 加载到的类,但各个 WebAppClassLoader 实例之间相互隔离。

3.1 Spring 加载问题

在 JVM 的实现中有一条规则,如果一个类由类加载器 A 加载,那么这个类的依赖类也由相同的类加载器完成。Spring 作为一个 bean
工厂,需要创建业务实体类,并且在创业业务类之前只要创建依赖类。

前面提到,web 应用之间共享的 JAR 包可以交给 SharedClassLoader 来加载,从而避免了重复,Spring 作为共享的三方 JAR
包,它自己是由 SharedClassLoader 加载的,但是Spring又要去加载业务类,但是业务类不在 SharedClassLoader
对应的目录下,那该怎么办呢?

Tomcat
使用了线程上下文加载器,它其实是一种类加载传递机制。这个类加载器保存在线程私有数据里,只要是同一个线程,一旦设置了线程上下文加载器,在线程后续执行过程中,就能把这个加载器取出来用。

Tomcat 为每个 Web 应用创建一个 WebAppClassLoader 类加载器,并在启动 Web 应用的线程里设置线程上下文加载器,这样
Spring 在启动时就将线程上下文加载器取出来,用来加载 Bean。这样就完成了 SharedClassLoader 创建的 Spring 可以创建
WebAppClassLoader 下的业务类,是不是设计的很精妙呢?

好了本期内容就介绍到这里。

往期经典推荐:

Tomcat架构究竟是什么?灵魂原来在这里-
CSDN博客

你真的了解Tomcat一键启停吗?-CSDN博客

你所不知的Tomcat网络通信的玄机-
CSDN博客

决胜高并发战场:Redis并发访问控制与实战解析-
CSDN博客

TiDB内核解密:揭秘其底层KV存储引擎如何玩转键值对-
CSDN博客

接下来我将给各位同学划分一张学习计划表!

学习计划

那么问题又来了,作为萌新小白,我应该先学什么,再学什么?
既然你都问的这么直白了,我就告诉你,零基础应该从什么开始学起:

阶段一:初级网络安全工程师

接下来我将给大家安排一个为期1个月的网络安全初级计划,当你学完后,你基本可以从事一份网络安全相关的工作,比如渗透测试、Web渗透、安全服务、安全分析等岗位;其中,如果你等保模块学的好,还可以从事等保工程师。

综合薪资区间6k~15k

1、网络安全理论知识(2天)
①了解行业相关背景,前景,确定发展方向。
②学习网络安全相关法律法规。
③网络安全运营的概念。
④等保简介、等保规定、流程和规范。(非常重要)

2、渗透测试基础(1周)
①渗透测试的流程、分类、标准
②信息收集技术:主动/被动信息搜集、Nmap工具、Google Hacking
③漏洞扫描、漏洞利用、原理,利用方法、工具(MSF)、绕过IDS和反病毒侦察
④主机攻防演练:MS17-010、MS08-067、MS10-046、MS12-20等

3、操作系统基础(1周)
①Windows系统常见功能和命令
②Kali Linux系统常见功能和命令
③操作系统安全(系统入侵排查/系统加固基础)

4、计算机网络基础(1周)
①计算机网络基础、协议和架构
②网络通信原理、OSI模型、数据转发流程
③常见协议解析(HTTP、TCP/IP、ARP等)
④网络攻击技术与网络安全防御技术
⑤Web漏洞原理与防御:主动/被动攻击、DDOS攻击、CVE漏洞复现

5、数据库基础操作(2天)
①数据库基础
②SQL语言基础
③数据库安全加固

6、Web渗透(1周)
①HTML、CSS和JavaScript简介
②OWASP Top10
③Web漏洞扫描工具
④Web渗透工具:Nmap、BurpSuite、SQLMap、其他(菜刀、漏扫等)

那么,到此为止,已经耗时1个月左右。你已经成功成为了一名“脚本小子”。那么你还想接着往下探索吗?

阶段二:中级or高级网络安全工程师(看自己能力)

综合薪资区间15k~30k

7、脚本编程学习(4周)
在网络安全领域。是否具备编程能力是“脚本小子”和真正网络安全工程师的本质区别。在实际的渗透测试过程中,面对复杂多变的网络环境,当常用工具不能满足实际需求的时候,往往需要对现有工具进行扩展,或者编写符合我们要求的工具、自动化脚本,这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中,想要高效地使用自制的脚本工具来实现各种目的,更是需要拥有编程能力。

零基础入门的同学,我建议选择脚本语言Python/PHP/Go/Java中的一种,对常用库进行编程学习
搭建开发环境和选择IDE,PHP环境推荐Wamp和XAMPP,IDE强烈推荐Sublime;

Python编程学习,学习内容包含:语法、正则、文件、 网络、多线程等常用库,推荐《Python核心编程》,没必要看完

用Python编写漏洞的exp,然后写一个简单的网络爬虫

PHP基本语法学习并书写一个简单的博客系统

熟悉MVC架构,并试着学习一个PHP框架或者Python框架 (可选)

了解Bootstrap的布局或者CSS。

阶段三:顶级网络安全工程师

如果你对网络安全入门感兴趣,那么你需要的话可以点击这里👉网络安全重磅福利:入门&进阶全套282G学习资源包免费分享!

学习资料分享

当然,只给予计划不给予学习资料的行为无异于耍流氓,这里给大家整理了一份【282G】的网络安全工程师从入门到精通的学习资料包,可点击下方二维码链接领取哦。

  • 9
    点赞
  • 12
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值