【编程底层原理】Tomcat为何要打破双亲委派模式
Tomcat作为一款流行的Java Web应用服务器，它在设计上需要处理一些特殊的场景，这些场景要求它对Java的默认类加载机制进行扩展，尤其是打破了Java的双亲委派模型。下面我将结合Tomcat的特点和需求来解释这一设计决策。
一、Java的双亲委派模型
首先，简要回顾一下Java的双亲委派模型。在标准的Java类加载机制中，当一个类加载器接收到类加载请求时，它首先不会自己尝试加载这个类，而是将这个请求委托给父类加载器去完成。只有当父类加载器无法加载（即找不到对应的类）时，子加载器才会尝试自己加载。这种机制保证了类的唯一性，避免了基础类被随意篡改。
二、Tomcat的需求与挑战
- 隔离性需求：Tomcat需要支持部署多个Web应用，每个应用可能依赖不同版本的库，比如不同版本的Spring框架。如果遵循双亲委派模型，所有应用将共享同一份库文件，这会导致版本冲突，无法满足应用的独立性和隔离性需求。
- 热部署和重载：Tomcat支持Web应用的热部署和重载，即在不重启服务器的情况下部署新应用或更新现有应用。这要求能够动态地加载和卸载类，而标准的双亲委派模型并不直接支持这种动态性。
- **类版本控制：应用可能需要使用特定版本的第三方库，而这个版本可能与服务器其他部分使用的版本不同。Tomcat通过使用Webapp ClassLoader，允许每个应用加载其特定版本的类库，从而避免版本冲突。
- **安全性：安全是Web应用中的一个关键考虑因素。通过使用独立的类加载器，Tomcat可以限制应用只能访问自己的类，从而防止一个应用访问或影响另一个应用的运行。
- **性能优化：在双亲委派模型中，如果多个应用加载相同的类，可能会导致不必要的重复加载。Tomcat通过使用独立的类加载器，可以避免这种重复加载，从而提高性能。
三、Tomcat的类加载器结构
为了应对上述挑战，Tomcat设计了自己的类加载器体系，打破了双亲委派模型：
- Common ClassLoader：负责加载Tomcat自身的类和所有Web应用共享的类库（如Servlet API）。这是所有Web应用的共同基础。
- Catalina ClassLoader：负责加载Tomcat服务器运行所需的额外类，比如Catalina容器相关的类。它通常继承自Common ClassLoader。
- Shared ClassLoader（可选）：某些场景下，可以配置一个额外的类加载器来加载多个Web应用之间共享但又不是Tomcat核心库的类。
- Webapp ClassLoader：每个Web应用都有自己的Webapp ClassLoader，负责加载该应用特有的类和库。这是打破双亲委派的关键点，因为Webapp ClassLoader会优先加载本应用下的类，而不是直接委托给父加载器，这样就可以实现不同应用间的类隔离。
四、打破双亲委派的意义
通过这样的设计，Tomcat实现了：
- 类隔离：确保每个Web应用的类库相互独立，避免了版本冲突。
- 灵活的类加载策略：允许Web应用覆盖或替换Tomcat提供的基础类库中的类，这对于某些特定的应用定制非常有用。
- 热部署支持：通过控制类加载器的生命周期，可以实现应用的动态加载和卸载，支持热部署。
综上所述，Tomcat打破Java的双亲委派模型是出于对Web应用服务器特有需求的考虑，旨在提供更好的应用隔离性、灵活性以及热部署能力。