Tomcat类加载器采用五层结构实现应用隔离与资源共享：Bootstrap加载JVM核心类，System加载系统类，Common加载$CATALINA_HOME/lib共享库，Shared加载$CATALINA_BASE/shared/lib共用类，WebappClassLoader为每个应用独有，优先加载/WEB-INF/classes和/WEB-INF/lib中的类，再委派给上层，打破双亲委派以保障版本隔离与资源可控。
直接看结构，重点是分层逻辑和加载顺序，不是背名字。
核心五层结构及其职责
Tomcat 类加载器不是简单的父子继承关系，而是按作用域划分的委派链：
-
Bootstrap ClassLoader：JVM 自带，加载
$JAVA_HOME/jre/lib下的核心类（如java.lang.*），C++ 实现，Java 中表现为null -
System ClassLoader（AppClassLoader）：加载
-classpath或java.class.path指定的类，比如启动脚本里加的 jar -
Common ClassLoader：Tomcat 自定义，加载
$CATALINA_HOME/lib下的通用库（如catalina.jar、tomcat-util.jar），被容器自身和所有 Web 应用共享 -
Shared ClassLoader（可选）：加载
$CATALINA_BASE/shared/lib，供多个 Web 应用共用，但对 Tomcat 容器不可见 -
Webapp ClassLoader：每个应用独有，加载自己
/WEB-INF/classes和/WEB-INF/lib中的类，实现应用间彻底隔离
关键区别：它不守“双亲委派”的老规矩
标准 Java 的类加载是“先问爹、再问爷、最后自己干”；Tomcat 的 Webapp 类加载器反过来了：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 收到类加载请求，先查自己目录（
WEB-INF/classes → WEB-INF/lib） - 找不到，才依次委派给 Shared → Common → System → Bootstrap
- 这个“本地优先”策略由
WebappClassLoaderBase.findClass()实现，可通过conf/context.xml中的delegate="true"强制改回传统顺序（极少用）
怎么验证当前结构
写个简单 Servlet 或 Filter，打印几行日志就能看清：
立即学习“Java免费学习笔记（深入）”；
-
getClass().getClassLoader()→ 当前 Web 应用的WebappClassLoader -
getClass().getClassLoader().getParent()→ 通常是Shared或Common（取决于配置） -
String.class.getClassLoader()→ 输出null，说明由 Bootstrap 加载 - 在
WEB-INF/lib放一个自定义 jar，确认能否被该应用加载而其他应用无法访问
为什么这样设计
根本目标就两个：
- 隔离：A 应用用 Spring 5，B 应用用 Spring 6，互不干扰
- 可控：容器核心类（如 Servlet 接口）由 Common 加载，确保统一；应用私有类由 Webapp 加载，避免污染全局
