Java沙箱中findClass是拦截类加载的关键入口，必须重写并严格校验类名前缀、字节码指令（如System.exit）、包名及反射调用，禁用ClassLoader复用以防止策略污染。
findClass 被调用时，类路径和字节码来源必须完全可控
在线沙箱不能依赖 loadClass 的双亲委派默认行为——它会把 java.lang.String 这类核心类一路委托到 BootstrapClassLoader，绕过你的检查逻辑。真正能拦截并自定义加载行为的入口是 findClass，但前提是：你得重写它，且确保父类加载器不提前返回结果。
常见错误是直接继承 URLClassLoader 却没重写 findClass，导致用户提交的 System.exit(0) 仍能执行（因为 SecurityManager 已被废弃，仅靠委派链无法阻断）。正确做法是继承 ClassLoader，在 findClass 中只从白名单目录或内存字节数组加载，彻底切断对系统类路径的访问。
- 构造时不要传入
parent，或显式传入null（让 Bootstrap 作为最终父类，但你自己控制中间层） - 重写
findClass后，loadClass默认会调用它——除非你同时重写了loadClass并跳过了findClass调用 - 务必在
findClass开头校验类名前缀（如拒绝java.、javax.、sun.），否则攻击者可通过defineClass注入恶意类
defineClass 前必须做字节码静态扫描与敏感指令过滤
defineClass 是真正把字节数组变成 Class 对象的关键步骤，也是沙箱最后一道防线。此时不做检查，后续任何运行时防护都晚了——比如 MethodHandle 绕过反射限制、Unsafe 直接操作内存，都在这个阶段已成定局。
不要只依赖正则匹配方法名（如找 "exit"），Java 字节码里没有字符串常量就调用不了 System.exit；要解析 Class 文件结构，扫描 CONSTANT_Methodref_info 指向的类/方法描述符，重点拦截：
-
java/lang/System.exit、java/lang/Runtime.exec、java/io/File.<init></init> -
java/lang/invoke/MethodHandles.privateLookupIn（JDK 9+ 可绕过模块限制） -
sun/misc/Unsafe的静态获取方法（如getUnsafe）
推荐用 ASM 库的 ClassReader + ClassVisitor 实现轻量扫描，避免完整加载类；扫描失败直接抛 ClassFormatError，让 findClass 返回 null 或抛异常，阻止类定义。
类隔离失效的典型场景：静态字段跨沙箱污染
即使每个代码片段用独立 ClassLoader 加载，若用户代码里有 static final String FLAG = "hacked"，而你又允许其反射修改（比如通过 Field.setAccessible(true)），这个值可能被后续其他沙箱实例读取——尤其当它们共享同一个运行时包（package）时，JVM 会合并 static 区域。
这不是 findClass 能解决的问题，而是类加载器设计缺陷。实际方案包括：
- 为每个沙箱实例生成唯一包名前缀（如
sandbox_abc123.java.util.ArrayList），强制打破包级可见性 - 禁用所有反射相关 API：在字节码扫描阶段拦截
java/lang/Class.getDeclaredField等调用 - 使用
--add-opens启动参数关闭 JDK 内部类的反射权限（JDK 17+ 默认严格）
注意：ClassLoader 的 defineClass 不会自动处理包级封装，你得自己在 findClass 解析完字节码后，校验类所属包是否在允许列表中。
ClassLoader 实例复用会导致策略缓存污染
为了性能，有人会缓存 ClassLoader 实例供多次编译使用。这是危险的——第一次加载的类会留在它的 classes 缓存里（ClassLoader 内部的 parallelLockMap 或私有哈希表），第二次提交同名类时，loadClass 可能直接返回旧实例，跳过你重写的 findClass。
解决方案不是加锁同步，而是彻底放弃复用：
- 每次执行都新建
ClassLoader子类实例（哪怕只是空壳） - 确保子类不持有外部引用（尤其不能持有所加载类的
Class对象，否则 GC 不掉） - 用
Thread.setContextClassLoader配合try-finally保证执行期间上下文类加载器准确，避免被框架（如 SLF4J）意外回溯到系统类加载器
最易忽略的是：JVM 对已卸载类的 Class 对象残留引用。如果沙箱内抛出异常并打印堆栈，异常对象可能被日志框架长期持有，间接阻止整个 ClassLoader 被回收。
