tomcat 使用自定义类加载器需通过 loader 机制集成，即继承 webappclassloaderbase 并配置 context.xml 或编程式注入 standardloader；delegate 属性控制双亲委派，false 表示先本地加载再委托，确保 web 应用隔离与热部署。

Tomcat 容器使用自定义类加载器，核心在于替换或扩展默认的 WebAppClassLoader，并控制其加载行为（尤其是是否打破双亲委派）。它不是简单写个 ClassLoader 就能生效，而是要通过 Tomcat 的载入器（Loader）机制集成进去。

明确 Tomcat 中的 Loader 与 ClassLoader 关系

Tomcat 并不直接管理 ClassLoader 实例，而是通过 org.apache.catalina.Loader 接口 的实现类（如 StandardLoader）来持有和调度类加载器。每个 Web 应用（Context）都关联一个 Loader，该 Loader 内部封装了真正的 ClassLoader（默认是 WebappClassLoaderBase）。所以，要使用自定义类加载器，本质是：
– 提供你自己的 ClassLoader 实现；
– 让 Tomcat 的 Loader 使用它，而不是默认的 WebappClassLoaderBase。

两种主流接入方式

方式一：通过 context.xml 配置自定义 Loader 类
在应用的 META-INF/context.xml 中指定 Loader 实现类：

  

你的 MyWebappClassLoader 必须继承 WebappClassLoaderBase（不能从头继承 ClassLoader），重写 findClass() 或 loadClass() 来定制逻辑，例如优先从某个 JAR 或网络路径加载。

Java Maven Secondary Analysis

分析ZIP压缩包或GitLab仓库中的Java Maven项目，确定二次开发范围、类数量、模块分布及生产相关指标。

下载

方式二：编程式注入（适合嵌入式 Tomcat 或启动时干预）
在 Tomcat 启动前，为 Context 设置自定义 Loader：

Context context = tomcat.addWebapp("/myapp", appDir.getAbsolutePath());
Loader loader = new StandardLoader();
loader.setClassLoader(new MyWebappClassLoader(context));
context.setLoader(loader);

关键行为控制：delegate 属性决定是否打破双亲委派

Tomcat 的 Loader 提供 delegate 属性，默认为 false，即先自己加载，失败再委托父类加载器——这正是 Web 应用隔离和热部署的基础。如果你的自定义类加载器需要兼容此行为，必须确保：
– 在 findClass(String name) 中优先搜索应用私有路径（如 /WEB-INF/classes、/WEB-INF/lib/*.jar）；
– 仅当本地找不到时，才调用 super.findClass(name) 委托给父加载器（通常是 SystemClassLoader）；
– 不要直接在 loadClass() 中绕过整个委托链，否则可能破坏 Servlet API 等基础类的可见性。

加载外部 JAR 中的类（常见需求）

若需动态加载独立 JAR 包里的类（如插件机制），推荐在自定义 ClassLoader 中复用 URLClassLoader 逻辑：
– 构造时传入 JAR 的 URL[]；
– 重写 findClass()，先尝试从这些 URL 加载；
– 注意避免类重复定义（ClassNotFoundException 或 LinkageError），尤其当 JAR 中含与 Tomcat 系统同名但不同版本的类时；
– 生产环境建议配合 getResources() 和资源过滤，防止意外加载了 javax.servlet.* 等容器级 API。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南