沙箱中异常传播失败本质是类加载器隔离导致类型不可见：父加载器无法识别子加载器加载的异常类型，使catch、instanceof及getcause()失效；应统一用系统加载器加载的哑异常包装，以字符串字段传递原始信息。
这个问题本质是沙箱中类加载器隔离与异常传播机制的冲突：父加载器（如 AppClassLoader）加载的通用异常包装器（比如 WrappedException 或框架自定义的 ExecutionFailure），无法识别子加载器（如沙箱专用 SandboxClassLoader）加载的异常类型，导致 catch 失败、instanceof 判定为 false、甚至 Throwable.getCause() 返回 null ——不是因为没设 cause，而是 cause 类型来自不同加载器，JVM 视为“不可见”。
确认是否真被类加载器隔离阻断了异常链
先排除误判：不是所有“捕获不到”都源于加载器隔离。检查以下几点：
- 用
getClass().getClassLoader()分别打印抛出异常对象、包装器类、以及catch块所在类的加载器，三者是否跨加载器；若同属一个加载器，问题大概率在逻辑或反射调用上 - 调用
throwable.getClass().getName()和throwable.getStackTrace()[0].getClassName()，看栈帧里是否混入了沙箱加载的类名（如com.sandbox.UserCode$$Lambda$1） - 不要依赖
isAssignableFrom跨加载器判断——它会返回false即使类名和结构完全一致，因为 JVM 以“加载器+类名”为唯一标识
用统一基类+序列化穿透加载器边界
让异常信息能跨加载器传递，核心是避免直接抛出子加载器定义的异常类型。推荐做法：
- 沙箱内所有异常最终都包装成一个由 Bootstrap 或 AppClassLoader 加载的“哑异常”，例如
java.lang.RuntimeException或预定义的SandboxExecutionError（该类必须放在lib/下，由系统加载器加载） - 真实异常信息不靠类型继承，而用字段承载：
message记原始错误描述，errorCode记枚举码，stackTraceAsString存格式化栈，causeType存全限定名字符串（非 Class 对象） - 若需还原原始异常，接收方解析
causeType字符串后，用Class.forName(name, false, Thread.currentThread().getContextClassLoader())尝试加载——注意第二个参数false表示不初始化，避免触发恶意静态块
禁用异常类型强校验，改用内容特征匹配
父加载器中的包装器不应依赖 instanceof 或 getClass().isAssignableFrom() 来识别异常，而应转向语义识别：
- 在包装器构造逻辑中，检查
throwable.getMessage()是否含关键词（如"sandbox timeout"、"denied: Runtime.exec"） - 扫描
throwable.getStackTrace()，看前几帧是否来自沙箱包路径（如com.example.sandbox.*），这是比类加载器更稳定的上下文信号 - 对已知高危异常（如
SecurityException、IllegalAccessException），即使它们由不同加载器加载，也统一映射为沙箱策略违规事件并记录告警
线程状态异常需绕过 Throwable 体系单独处理
所谓“线程状态异常”（如 Thread.getState() == TIMED_WAITING 但实际卡死、或 Thread.isInterrupted() 失效），往往不是 Throwable，而是运行时可观测指标。这类问题不能靠异常捕获解决：
- 沙箱执行器应在启动用户代码前，用
Thread.currentThread().setUncaughtExceptionHandler注册一个由父加载器提供的处理器，专门收集未被捕获的Throwable - 对线程挂起、超时、CPU 占用等状态，用
ThreadMXBean定期轮询，其 API 由 JVM 提供，不受加载器影响；发现异常状态立即thread.stop()（仅限沙箱内可控环境）或thread.interrupt() - 避免在沙箱代码中调用
Thread.sleep()、Object.wait()等易被阻塞的方法；改用封装后的TimeoutExecutor.submit(runnable, 5, SECONDS)，超时由外部线程强制终止
