必须通过隔离、校验、限制三重机制控制执行边界：用独立classloader+白名单校验加载字节码，静态扫描敏感符号与方法，运行时启用securitymanager并沙箱化执行，全程构建期与运行时监控。
不能直接加载，必须通过隔离、校验、限制三重机制控制执行边界。核心思路是：不让字节码接触真实运行时环境，也不让它绕过验证逻辑。
用独立类加载器+双亲委派拦截
为第三方字节码创建专用的自定义 ClassLoader，但不重写 defineClass，而是委托给父加载器（如 AppClassLoader）做基础加载；同时在 findClass 中插入白名单校验——只允许加载指定包名（如 com.vendor.plugin.*）下的类，并拒绝 java.*、sun.*、jdk.internal.* 等敏感命名空间。
- 禁用 URLClassLoader，防止通过 file:// 或 http:// 加载远程类
- 覆盖 loadClass 方法，在调用父类前检查类名是否符合签名+白名单规则
- 加载后立即调用 Class.getProtectionDomain().getCodeSource() 验证来源是否可信（如 JAR 文件带有效签名）
加载前做字节码静态扫描
在 defineClass 之前，用 JDK 23+ 的 java.lang.classfile API 解析字节码结构，不执行、不反射，只做安全断言：
- 检查常量池中是否存在
Ljava/lang/Runtime;、Ljava/lang/ProcessBuilder;或Lsun/misc/Unsafe;的符号引用 - 遍历所有 MethodModel，确认没有 invokestatic/invokevirtual 调用敏感方法（如 exec、loadLibrary、setSecurityManager）
- 验证 Signature 和 Descriptor 是否合法，非法泛型或错误描述符会直接抛 IllegalArgumentException，天然阻断构造恶意类型
加载后运行于受限沙箱
即使字节码通过了前两关，也要限制其实际行为能力：
- 启动时启用 SecurityManager（JDK 17+ 仍可手动启用），策略文件中禁止 RuntimePermission “createClassLoader”、“modifyThreadGroup”、“setSecurityManager”
- 在 newInstance 或反射调用前，用 Thread.currentThread().setContextClassLoader() 切换到受限加载器，并清空其上下文中的 System、Runtime、ClassLoader 引用
- 若需执行逻辑，将其包装进受控接口（如 ScriptExecutor.eval(byte[])），内部使用 MethodHandles.Lookup.defineClass() 定义在当前模块内，避免跨加载器污染
配合构建期与运行时监控
防御不是单点动作，而是贯穿生命周期：
- CI 流程中集成 ValidX 类工具，在编译后扫描 .class 文件，拦截硬编码密钥、明文凭证、不安全随机数等模式
- 运行时开启 -XX:+TraceClassLoading，对非系统加载器加载的类记录日志；发现 URLClassLoader 或 ParallelWebappClassLoader 加载敏感类时立即熔断
- 定期调用 Instrumentation.getAllLoadedClasses()，比对类名与已知白名单，异常类触发告警并卸载（需配合 ClassLoader 可回收设计）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
