核心是重写loadClass方法以实现本地优先加载，即先调用findClass尝试加载，失败后再委派父加载器；仅重写findClass无法改变加载顺序，因loadClass默认先调父类loadClass；需在loadClass中控制委派时机并结合包名、路径或配置策略实现隔离。
核心是重写 loadClass 方法，让类加载器优先自己找类，而不是先扔给父加载器——这不是删除委派，而是把“委派”变成“按需选择”。
为什么必须动 loadClass，而不是只改 findClass
findClass 只负责从字节码构造 Class 对象，它本身不决定“什么时候调用”。真正控制加载顺序的是 loadClass：默认逻辑是“先调 parent.loadClass，失败再调 findClass”。如果只重写 findClass，双亲委派依然完整执行，你的自定义逻辑根本没机会触发。
所以打破的关键动作只有一个：在 loadClass 里跳过对父加载器的首次调用，改为先执行自己的 findClass。
标准打破写法（带安全兜底）
一个稳妥的 loadClass 实现通常包含三步：
- 调用 findLoadedClass 检查是否已加载，避免重复定义
- 直接调用自身的 findClass 尝试从指定路径（如插件目录、WEB-INF/lib）加载
- 仅当 findClass 抛出 ClassNotFoundException 时，才调 super.loadClass 回退到标准委派链
这样既实现了“本地优先”，又保留了对 java.*、javax.* 等系统类的向上委托能力，不会破坏 JVM 基础稳定性。
类名和路径判断决定隔离边界
真正让隔离生效的，不是“打破”这个动作本身，而是你在 findClass 或 loadClass 中做的判断逻辑。常见策略有：
- 按包名前缀过滤：com.example.*、org.myplugin.* 一律自己加载；java.、javax.*、org.apache.catalina.* 则强制委托
- 按资源存在性判断：先检查 classPath + name.replace('.', '/') + ".class" 文件是否存在，存在才加载
- 结合配置白名单/黑名单：通过外部配置控制哪些包走本地、哪些走父加载器
Tomcat 的 WebappClassLoader 就是靠这类判断，确保每个 WAR 包的 com.yourcompany.User 由自己的加载器加载，而 java.util.ArrayList 仍由 Bootstrap 加载。
注意跨加载器交互的陷阱
隔离带来自由，也带来限制：
- 两个不同 WebappClassLoader 加载的相同类名（如 LogFactory），JVM 视为完全不同的类型，不能强转，也不能共用静态变量
- 若需共享对象（比如 DataSource），必须使用由共享类加载器（如 SharedClassLoader）加载的接口类型，否则运行时报 ClassCastException
- 反射调用、序列化、JNDI 查找等场景，要特别留意当前线程的上下文类加载器（ContextClassLoader）是否匹配预期
这些不是 bug，而是隔离机制的自然结果——类加载器 + 类全限定名，共同构成类的唯一身份。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
