Tomcat类加载机制详解与应用隔离实现

Tomcat巧妙地“调整”而非“破坏”Java标准的双亲委派机制，通过为每个Web应用定制独立的WebAppClassLoader，并重写其loadClass()方法，使其优先从/WEB-INF/classes和/WEB-INF/lib中加载类，仅在未找到时才委托父加载器——这一关键设计既保障了多应用间同名类的彻底隔离（JVM中视为不同Class），又通过分层类加载器（Common/Shared/WebApp）实现公共库的高效共享；再加上线程上下文类加载器的动态切换，确保Spring等框架能无缝访问应用代码。这种有策略、有层次、有协同的类加载架构，正是Tomcat在复杂生产环境中支撑高密度、多版本、安全隔离Web应用部署的核心奥秘。

Tomcat不是“随意破坏”双亲委派，而是有目的地**调整加载顺序**，让每个Web应用优先用自己的类加载器加载自身代码，从而实现隔离。核心在于：不放弃委托，但改变“谁先试”的逻辑。

WebAppClassLoader主动抢在父加载器前加载

标准双亲委派要求子加载器必须先把请求交给父加载器；而Tomcat的WebAppClassLoader重写了loadClass()方法，流程变成：

• 先检查本应用的/WEB-INF/classes和/WEB-INF/lib里有没有这个类
• 如果有，直接加载——这一步就绕过了父加载器
• 只有找不到时，才按常规流程委托给父加载器（如SharedClassLoader或CommonClassLoader）

不同应用用不同类加载器，同名类也不冲突

每个Web应用启动时，Tomcat都会创建一个独立的WebAppClassLoader实例。JVM判断两个类是否“相同”，不仅看类名和包名，还看加载它的类加载器。

比如两个应用都定义了com.example.UserController，它们被各自的WebAppClassLoader加载后，在JVM中就是两个完全独立的Class对象，互不影响、不会覆盖。

共享依赖靠父加载器统一提供

虽然Web应用自己优先加载，但像Spring、Jackson这类通用库，并不重复打包进每个应用。Tomcat通过分层类加载器设计解决复用问题：

• CommonClassLoader加载$CATALINA_HOME/lib下的公共jar（如Tomcat自身依赖）
• SharedClassLoader加载$CATALINA_HOME/shared/lib，供所有Web应用共享
• 当WebAppClassLoader在本地找不到Spring类时，自然委托上去，由SharedClassLoader加载一次，所有应用共用同一个Class对象

线程上下文加载器保障框架兼容性

有些第三方框架（如Spring、JDBC）运行时需要动态加载应用级类，但它们的代码是由Tomcat容器加载的，用的是CatalinaClassLoader等高层加载器，无法直接访问Web应用的类路径。

Tomcat在启动每个应用的线程时，会临时把Thread.currentThread().setContextClassLoader()设为该应用的WebAppClassLoader。这样Spring就能通过Thread.currentThread().getContextClassLoader()正确加载用户写的Bean类，而不是报ClassNotFoundException。

好了，本文到此结束，带大家了解了《Tomcat类加载机制详解与应用隔离实现》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！