tomcat通过调整双亲委派顺序实现类隔离：webappclassloader优先加载本应用/web-inf/classes与lib中的类，未找到才委托父加载器；各应用独享类加载器，同名类因加载器不同而互不冲突；共享类由common/sharedclassloader统一加载；线程上下文类加载器确保框架可访问应用类。
Tomcat 通过调整类加载顺序而非彻底抛弃双亲委派，来实现多 Web 应用之间的变量与类隔离。关键不在“破坏”，而在“控制加载优先级”和“划分命名空间”。只要理解清楚 WebAppClassLoader 的行为边界和几个核心控制点，就能在实际部署中规避常见冲突。
每个应用独享一个 WebAppClassLoader 实例
Tomcat 启动每个 Web 应用（如 app1、app2）时，都会创建独立的 WebAppClassLoader 实例。JVM 判定两个 Class 是否为同一类型，不仅看全限定名（如 com.example.User），还必须类加载器相同。这意味着：
- app1 中的
com.example.User由其 WebAppClassLoader 加载 → 是 Class A - app2 中同名类由另一个 WebAppClassLoader 加载 → 是 Class B
- 两者互不可见，静态变量、类初始化块、
Class.forName()结果均完全隔离
本地优先加载：绕过父委托的关键动作
WebAppClassLoader 重写了 loadClass(String, boolean) 方法，执行逻辑是：
- 先查本应用缓存（
findLoadedClass） - 再查
WEB-INF/classes目录（.class 文件） - 再查
WEB-INF/lib/*.jar（含所有依赖 jar） - 仅当以上都失败，才调用
super.loadClass委托给父加载器
这个“先本地、后委托”的顺序，让应用能自带自己的 Spring、Jackson、甚至自定义工具类，不同版本并行不悖。比如 app1 打包了 slf4j-api-1.7.30.jar，app2 打包了 slf4j-api-2.0.9.jar，它们各自加载，互不影响。
共享类库靠父加载器统一供给
不是所有类都要隔离——像 javax.servlet.Servlet、org.apache.catalina.Lifecycle 这类容器契约类，必须由 Tomcat 统一提供，否则会出 LinkageError。Tomcat 用分层设计解决复用与隔离的矛盾：
-
CommonClassLoader：加载
$CATALINA_HOME/lib，供 Tomcat 内核 + 所有 Web 应用共用（如 tomcat-juli.jar） -
SharedClassLoader（可选）：加载
$CATALINA_HOME/shared/lib，供所有 Web 应用共享（如通用工具包） -
CatalinaClassLoader：加载
$CATALINA_HOME/server/lib，仅 Tomcat 内部使用，对 Web 应用不可见
这些父加载器加载的类，子加载器不会重复加载，也禁止覆盖（例如所有 java.*、javax.* 除 servlet 外，都强制委托）。
线程上下文类加载器保障框架可访问应用类
很多框架（Spring、JDBC 驱动、JAX-RS 实现）运行在容器线程中，但它们本身由 CatalinaClassLoader 加载，无法直接看到 Web 应用里的类。Tomcat 在处理每个请求前，会执行：
Thread.currentThread().setContextClassLoader(webAppClassLoader);
这样 Spring 的 BeanFactory、JDBC 的 DriverManager 就能通过 Thread.currentThread().getContextClassLoader().loadClass(...) 正确加载用户写的 @Service 或 DataSource 实现类，避免 ClassNotFoundException。
