直接继承ClassLoader并重写findClass是最稳妥的自研类加载器方式；loadClass负责双亲委派流程控制，findClass专注字节码读取与defineClass调用，二者解耦且各司其职。
直接继承 ClassLoader 并重写 findClass，是设计自研类加载器最稳妥、最符合 JVM 规范的方式。loadClass 负责流程控制与安全边界，findClass 专注字节码来源，二者天然解耦——你只需管“从哪读”，不用操心“先找谁”。
明确分工：让 loadClass 做调度，findClass 做执行
loadClass 是公开的入口方法，自带双亲委派逻辑：检查缓存 → 委托父加载器 → 父失败后才调用 findClass。这个流程不能也不该由你手动重写，除非你要刻意打破委派（如热部署、模块隔离等特殊场景）。绝大多数自定义需求，只需把字节码来源逻辑塞进 findClass 即可。
- loadClass 默认实现已完整保障类加载的安全性、唯一性和一致性
- findClass 是 protected 的空方法，必须重写，且只做三件事：定位字节码 → 读成 byte[] → 传给 defineClass
- defineClass 是父类提供的关键工具，它把原始字节数组校验并转为 JVM 可识别的 Class 对象
重写 findClass 的标准写法
核心是将类全限定名（如 com.example.Hello）映射为物理路径，再读取 .class 文件内容：
- 把 . 替换为文件分隔符（如 /），拼上 .class 后缀
- 从指定目录、JAR 包、网络 URL 或加密资源中读取该路径对应的字节流
- 用 try-with-resources 确保流正确关闭，避免内存泄漏
- 调用 defineClass(name, bytes, 0, bytes.length) 完成加载
- 若路径不存在或读取出错，直接抛出 ClassNotFoundException
避开常见陷阱
很多自研加载器出问题，不是因为逻辑复杂，而是踩了几个低级但关键的坑：
- 不要重写 loadClass 来“绕过父加载器”——除非你清楚后果（比如导致 String 类被重复加载报错）
- 不要在 findClass 中调用 getClassLoader() 或 this.getClass().getClassLoader()，可能引发循环委托
- 确保 defineClass 的 name 参数与传入的全限定名严格一致，否则类链接会失败
- 如果类依赖其他类，这些依赖仍走标准双亲委派；如需全部走自定义路径，得配合设置线程上下文类加载器（ContextClassLoader）
典型应用场景适配
不同目标，对 findClass 的实现侧重点不同：
- 热部署：每次调用 findClass 都从最新字节码加载，配合新实例化类加载器，实现类版本隔离
- 插件化：从独立 JAR 包中读取字节码，路径基于插件 ID 构建，避免与主程序类冲突
- 加密类加载：读取后先解密 byte[]，再交给 defineClass，保护核心逻辑不被反编译
- 远程类加载：通过 HTTP 请求获取字节码，适合灰度发布或动态策略下发
