Java自定义加密类加载器核心是findClass中解密加密的.class字节后交defineClass加载；需闭环处理加密、解密与字节操作，避开双亲委派干扰系统类，并通过外部注入密钥提升安全性。
Java 中自定义加密类加载器的核心在于：不依赖 defineClass 的原始字节，而是在 findClass 中解密已加密的 .class 文件字节，再交给 defineClass 加载。关键不是“重写 findClass 就完事”，而是确保加密、解密、字节处理三者闭环，且避开双亲委派对核心类的干扰。
加密 class 文件（准备阶段）
在编译后对 .class 文件做对称加密（如 AES），生成加密后的文件（例如 MyClass.class.enc）。注意：
- 保留原始类名和包路径结构，便于加载器按约定定位
- 避免加密
java.*、javax.*等系统类，否则会导致启动失败 - 加密时使用固定密钥和初始化向量（IV），解密时严格复用
继承 ClassLoader 并重写 findClass
findClass 是自定义加载逻辑的入口，它不走双亲委派（即不会先委托给父加载器），适合加载非标准来源的类。你需要：
- 根据全限定名（如
com.example.MyClass）构造加密文件路径（如/classes/com/example/MyClass.class.enc） - 读取加密字节数组
- 调用解密方法还原为标准 class 字节
- 将解密后的字节数组传给
defineClass完成加载
示例片段：
立即学习“Java免费学习笔记（深入）”；
protected Class<?> findClass(String name) throws ClassNotFoundException {
byte[] encryptedBytes = loadEncryptedBytes(name); // 自定义读取 .enc 文件
byte[] decryptedBytes = decrypt(encryptedBytes); // AES 解密
return defineClass(name, decryptedBytes, 0, decryptedBytes.length);
}
绕过双亲委派（谨慎使用）
默认情况下，即使重写了 findClass，loadClass 方法仍会先尝试父加载器。若要强制走自定义逻辑（比如加载所有业务类），需同时重写 loadClass，跳过父委托（仅对特定包生效）：
- 检查类名是否属于加密范围（如以
com.myapp.开头） - 是则直接调用
findClass；否则走默认逻辑（super.loadClass） - 切勿跳过
java.lang.Object等启动类，否则 ClassFormatError 或 NoClassDefFoundError 必现
密钥管理与安全性边界
加密类加载器本质是“混淆+运行时解密”，无法真正防止逆向——密钥或解密逻辑若硬编码在加载器中，仍可被反编译获取。提升安全性的实际做法：
- 密钥由外部注入（如启动参数、环境变量、远程配置中心），不在代码中明文出现
- 解密逻辑做简单控制流扁平化或字符串动态拼接，增加静态分析成本
- 配合 Java Agent 或 JNI 实现更底层的字节码解密，但开发和部署复杂度显著上升
它适用于防止直接拖 jar 包篡改，而非对抗专业逆向工程。
