直接继承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 请求获取字节码，适合灰度发布或动态策略下发