Java安全管理器构建在线评测系统安全沙箱：原理、实战与避坑指南

1. 项目概述：为什么我们需要一个“带笼子”的判题机？

做在线评测系统（Online Judge， OJ）的，最头疼也最核心的问题，就是如何安全、公平地运行用户提交的未知代码。这不像普通的Web服务，你面对的是可控的业务逻辑。在OJ里，你面对的是成千上万、意图各异的代码片段，它们可能来自一个急于通过考试的学生，也可能来自一个试图“黑”掉你系统的“黑客”。这些代码一旦在你的服务器上获得执行权限，就可能做出各种危险行为：读取服务器上的敏感文件（比如数据库密码）、无限创建线程耗尽CPU、执行系统命令删除数据，甚至试图通过网络攻击其他服务器。

所以，判题机的核心使命，不是“能跑代码”，而是“在绝对可控的牢笼里跑代码”。这个“牢笼”就是环境隔离。市面上有很多成熟的方案，比如Docker容器、虚拟机（VM），甚至更底层的沙箱技术（如seccomp, cgroups）。它们都能提供相当强的隔离性。但今天我们要聊的，是一个更轻量、更直接、在某些场景下（尤其是教育机构内部、资源受限或对启动速度要求极高的场景）依然有生命力的方案：使用Java原生的安全管理器（SecurityManager）来实现代码运行环境隔离。

这个方案的核心思想是“权限最小化”。我们不依赖外部容器去构建一个隔离的OS环境，而是在JVM内部，通过一套精细的权限控制策略，告诉JVM：“接下来要运行的这段代码，它只能做这些事，其他的统统禁止”。比如，它只能读写自己临时目录下的文件，不能创建线程，不能访问网络，不能加载本地库，不能执行外部命令。通过这种方式，我们为每一份用户代码构建了一个逻辑上的“沙箱”。

它的优势很明显：极致的轻量与快速。无需启动沉重的Docker守护进程，没有镜像拉取和容器创建的开销，代码加载即执行，特别适合高并发、短生命周期的判题场景。但挑战也同样突出：配置复杂，且隔离强度依赖于JVM沙箱的完备性，一旦策略配置有误，就可能留下安全漏洞。这就像给你的代码套上了一套由规则组成的“紧身衣”，衣服的针脚必须足够密，不能有任何破绽。

接下来，我将拆解如何从零搭建这样一个基于Java安全管理器的判题机核心架构。这套架构曾支撑过一个日均处理数万次提交的中小型OJ系统，稳定运行了多年。我会把其中的设计思路、关键配置、踩过的坑以及那些“教科书上不会写”的实操细节，毫无保留地分享出来。

2. 架构核心：判题机的生命周期与安全边界设计

一个完整的判题任务，从用户点击“提交”到返回“答案正确”或“编译错误”，是一个标准的生命周期。我们的架构设计必须清晰地定义每个阶段的职责和安全边界。

2.1 判题任务的标准化流程

一个判题任务的生命周期通常包含以下几个阶段：

1. 任务获取：判题机作为一个独立进程或线程，从消息队列（如RabbitMQ、Redis List）或数据库中拉取待判题任务。任务信息至少包括：提交ID、题目ID、用户代码（多种语言）、题目的时间/内存限制、测试输入数据。
2. 环境准备：为本次判题任务创建独立的运行时环境。在我们的方案中，这主要就是设置好本次任务专属的SecurityManager策略文件，以及一个临时工作目录。
3. 编译阶段（针对编译型语言）：调用对应的编译器（如javac,gcc）将用户代码编译成可执行文件或字节码。这个阶段本身就在沙箱外进行，因为编译器需要正常的系统权限。但必须严格限制编译器的参数和输入，防止命令注入。
4. 运行阶段（核心隔离阶段）：在一个全新的、受SecurityManager严格控制的线程或类加载器中，加载并运行用户代码。此阶段需要精确计时和监控内存消耗。
5. 资源收集与比对：收集用户程序的标准输出、标准错误，并与题目的预期输出进行比对（通常考虑特殊格式，如忽略行尾空格）。同时，记录运行时间、内存使用峰值以及任何由SecurityManager抛出的安全异常（如试图执行System.exit(0)）。
6. 结果回写与清理：将判题结果（AC, WA, TLE, MLE, RE, CE等）和详细数据写回数据库或消息队列。最后，彻底清理本次任务创建的临时目录和文件，避免磁盘空间泄露。

整个流程中，第4步“运行阶段”是我们安全防护的重中之重，也是Java安全管理器大显身手的地方。其他步骤虽然不在沙箱内，但也需要通过各种手段（如白名单命令、输入过滤、资源限制）来加固。

2.2 安全边界的多层次防御

不要指望单靠SecurityManager就能解决所有安全问题。一个健壮的判题机应该构建多层次防御：

• 第一层：操作系统级隔离。即使使用SecurityManager，判题机进程也应该以一个低权限的专用系统用户（如judge）运行，并利用ulimit限制其能创建的子进程数、打开文件数等。
• 第二层：运行时环境隔离（核心）。这就是Java SecurityManager提供的沙箱。它定义了代码在JVM内部能做什么，不能做什么。
• 第三层：资源限制。我们需要在运行用户代码时，监控其CPU时间和内存占用。SecurityManager不直接提供此功能，需要结合其他工具，如：
  • CPU时间限制：通过一个独立的监控线程，在用户代码执行线程启动后开始计时，超时则直接中断（Thread.interrupt()）该线程。注意，中断可能无法停止陷入死循环的某些IO阻塞操作。
  • 内存限制：这是一个难点。纯Java方案可以通过-Xmx设置JVM最大堆，但这是全局的。更精细的控制需要借助InstrumentationAPI或Java Attach API来估算单个类加载器或线程的内存使用，但实现复杂且不精确。对于C/C++等通过JNI调用的本地代码，控制内存几乎不可能，这也是此方案的一大局限。因此，此方案更适用于纯Java、Python等解释型/托管型语言的判题。
• 第四层：输入/输出与网络隔离。通过SecurityManager策略，直接禁止网络操作。将用户程序的输入输出重定向到我们准备好的管道或内存流，完全切断其与真实控制台、文件系统的直接交互。

理解了整体架构和防御层次后，我们就可以深入核心，看看如何配置这个关键的“笼子”——SecurityManager策略文件。

3. 核心实战：编写滴水不漏的SecurityManager策略文件

策略文件（.policy文件）是SecurityManager的灵魂。它使用一套声明式的语法来定义权限（Permission）。我们的目标是：给用户代码尽可能少的权限，仅够它完成计算任务。

3.1 策略文件语法精讲

一个基本的权限条目长这样：

grant [codeBase <URL>] { permission <权限类名> [<目标>] [, <操作列表>] [, <异常列表>]; };

• codeBase: 指定哪些代码（来自哪个JAR或目录）拥有这些权限。对于用户提交的代码，我们通常通过自定义的ClassLoader加载，并为其指定一个空的或特定的codeBase。
• permission: 具体的权限类，来自java.security包，如java.io.FilePermission、java.lang.RuntimePermission。

让我们为判题环境编写一个基础策略模板，并逐条解释：

// judge.policy - 判题机核心安全策略 grant { // 1. 允许必要的运行时权限 // 允许设置安全管理器（通常由我们判题机主程序设置） permission java.lang.RuntimePermission "setSecurityManager"; // 允许创建类加载器（我们的沙箱类加载器需要） permission java.lang.RuntimePermission "createClassLoader"; // 允许获取保护域（用于调试和日志） permission java.lang.RuntimePermission "getProtectionDomain"; // 允许线程修改自身（interrupt等操作需要） permission java.lang.RuntimePermission "modifyThread"; // 允许停止线程（超时控制需要） permission java.lang.RuntimePermission "stopThread"; // **关键禁止项**：禁止退出JVM！否则用户一句System.exit(0)就能让整个判题机瘫痪。 // permission java.lang.RuntimePermission "exitVM"; // 绝对不能授权！ // 2. 文件权限 - 这是最需要精细控制的地方 // 授予对临时工作目录的完全控制权 permission java.io.FilePermission "/tmp/judge_workspace/${task_id}/-", "read, write, delete"; // **注意**：${task_id}需要在运行时动态替换为实际的任务ID。 // “-”代表该目录及其下所有文件。 // **关键禁止项**：禁止读取任何其他目录，特别是系统目录、判题机程序目录、题目数据目录（除非只读）。 // 通常，我们会先授予一个极小的权限，再视情况添加。这里采用默认拒绝，显式允许的原则。 // 例如，如果题目需要读取一个固定的输入文件，可以单独授权： // permission java.io.FilePermission "/var/oj/problems/1000/input.txt", "read"; // 3. 网络权限 - 全部禁止 // 用户代码不应有任何网络操作 // permission java.net.SocketPermission "*", "connect,accept,listen,resolve"; // 绝对不能授权！ // 4. 系统属性权限 - 限制访问 // 只允许读取一些无害的属性 permission java.util.PropertyPermission "java.version", "read"; permission java.util.PropertyPermission "os.name", "read"; // 禁止修改任何属性 // permission java.util.PropertyPermission "*", "write"; // 绝对不能授权！ // 5. 反射权限 - 严格限制 // 允许基本的反射（很多框架和正常代码需要），但禁止访问私有成员 permission java.lang.RuntimePermission "accessDeclaredMembers"; // **关键禁止项**：禁止抑制访问检查，否则反射将无视private修饰符。 // permission java.lang.RuntimePermission "suppressAccessChecks"; // 谨慎授权！ // 6. 本地库权限 - 禁止 // 用户代码不能加载动态链接库（DLL/SO） // permission java.lang.RuntimePermission "loadLibrary.*"; // 绝对不能授权！ // permission java.lang.RuntimePermission "loadLibrary.*"; // 绝对不能授权！ };

注意：上面的策略只是一个模板。在实际部署中，/tmp/judge_workspace/${task_id}这个路径必须确保唯一且每次判任务后都能被清理。更安全的做法是使用Java的java.nio.file.Files.createTempDirectory方法创建临时目录，并将该目录路径动态地插入到策略中。

3.2 动态策略生成与加载

静态的策略文件不够灵活，因为每个任务的工作目录都不同。我们需要在运行时动态生成策略内容。这里有一个实用的技巧：使用Policy的子类或工具类来动态添加权限。

import java.security.*; import java.util.PropertyPermission; public class DynamicPolicy extends Policy { private final PermissionCollection permissions = new Permissions(); private final String workspacePath; public DynamicPolicy(String workspacePath) { this.workspacePath = workspacePath; // 添加基础权限 addBasePermissions(); } private void addBasePermissions() { // 允许必要的运行时权限 permissions.add(new RuntimePermission("setSecurityManager")); permissions.add(new RuntimePermission("createClassLoader")); permissions.add(new RuntimePermission("modifyThread")); permissions.add(new RuntimePermission("stopThread")); // 注意：没有 exitVM // 允许读写临时工作目录 permissions.add(new FilePermission(workspacePath + File.separator + "-", "read,write,delete")); // 允许读取部分系统属性 permissions.add(new PropertyPermission("java.version", "read")); permissions.add(new PropertyPermission("os.name", "read")); // 允许基础反射 permissions.add(new RuntimePermission("accessDeclaredMembers")); // 注意：没有 suppressAccessChecks } @Override public PermissionCollection getPermissions(CodeSource codesource) { // 返回一个权限集合的副本，防止被修改 Permissions result = new Permissions(); for (Permission perm : permissions.elements()) { result.add(perm); } return result; } @Override public PermissionCollection getPermissions(ProtectionDomain domain) { return getPermissions(domain.getCodeSource()); } @Override public boolean implies(ProtectionDomain domain, Permission permission) { PermissionCollection pc = getPermissions(domain.getCodeSource()); return pc.implies(permission); } }

在判题任务开始时，我们可以这样设置安全管理器：

public class JudgeTaskRunner { public JudgeResult runTask(Task task) { // 1. 创建唯一临时目录 Path workspace = Files.createTempDirectory("judge_" + task.getId()); try { // 2. 创建动态策略 Policy dynamicPolicy = new DynamicPolicy(workspace.toString()); // 3. 备份旧策略，设置新策略 Policy oldPolicy = Policy.getPolicy(); Policy.setPolicy(dynamicPolicy); // 4. 创建并设置安全管理器 SecurityManager oldSm = System.getSecurityManager(); System.setSecurityManager(new SecurityManager()); // 5. 在这里执行用户代码（需要放在独立的线程和类加载器中） // ... (具体执行逻辑见下一节) } finally { // 6. 无论如何，恢复原有的安全管理器和策略 System.setSecurityManager(oldSm); Policy.setPolicy(oldPolicy); // 7. 清理临时目录 deleteDirectoryRecursively(workspace); } } }

这种动态方式给了我们极大的灵活性，可以为每个任务量身定制安全策略。

4. 沙箱执行引擎：类加载器与线程的协同作战

设置了SecurityManager，只是立好了规矩。如何让用户代码在这个规矩下运行，而不影响判题机本身？这就需要用到自定义类加载器和受控的执行线程。

4.1 使用自定义类加载器实现代码隔离

判题机自身的类（如JudgeTaskRunner）和用户提交的类必须被隔离开。如果用户代码和判题机使用同一个类加载器，用户代码就有可能通过反射等方式访问到判题机的内部对象，造成严重安全问题。自定义类加载器可以创建独立的命名空间。

public class JudgeClassLoader extends SecureClassLoader { private final Path classFilePath; // 用户编译后的.class文件路径 public JudgeClassLoader(Path classFilePath) { super(); // 父类加载器通常为系统类加载器 this.classFilePath = classFilePath; } @Override protected Class<?> findClass(String name) throws ClassNotFoundException { // 我们只加载指定的用户主类 if (!name.equals(task.getMainClassName())) { throw new ClassNotFoundException(name); } try { byte[] classBytes = Files.readAllBytes(classFilePath); // defineClass 是继承自 ClassLoader 的关键方法，将字节数组转换为 Class 对象 // 第二个参数是保护域，可以关联我们之前定义的策略 return defineClass(name, classBytes, 0, classBytes.length, getDomain()); } catch (IOException e) { throw new ClassNotFoundException("Failed to load class: " + name, e); } } private ProtectionDomain getDomain() { CodeSource codeSource = new CodeSource(null, (Certificate[]) null); // 获取当前线程上下文的安全策略，它会关联到我们设置的 DynamicPolicy PermissionCollection permissions = Policy.getPolicy().getPermissions(codeSource); return new ProtectionDomain(codeSource, permissions); } }

这个自定义类加载器只负责加载用户的主类。用户主类所依赖的其他类（如java.lang.String）会通过双亲委托机制，由父加载器（系统类加载器）加载，但这些系统类在用户代码中调用时，依然会受到SecurityManager的管制。

4.2 在独立线程中运行与资源监控

用户代码必须在独立的线程中运行，这样我们才能控制它的生命周期（超时中断），并且即使它崩溃也不会影响判题机主线程。

public class SandboxRunner { public RunResult runInSandbox(String mainClassName, JudgeClassLoader classLoader, long timeLimitMillis, long memoryLimitBytes) { final RunResult result = new RunResult(); final Thread userThread = new Thread(() -> { try { // 设置当前线程的上下文类加载器为我们自定义的 Thread.currentThread().setContextClassLoader(classLoader); // 加载用户主类 Class<?> userClass = classLoader.loadClass(mainClassName); // 获取main方法 Method mainMethod = userClass.getMethod("main", String[].class); // 准备参数（这里假设没有命令行参数） String[] args = new String[0]; // 执行用户代码 mainMethod.invoke(null, (Object) args); result.setExitType(ExitType.NORMAL); } catch (InvocationTargetException e) { // 用户代码抛出的异常会被包装在这里 Throwable target = e.getTargetException(); result.setExitType(ExitType.EXCEPTION); result.setException(target); } catch (Throwable t) { // 其他错误，如类找不到、方法找不到等，算作运行时错误 result.setExitType(ExitType.ERROR); result.setException(t); } }); userThread.setName("Judge-Thread-" + mainClassName); // 设置一个较低的优先级，避免过度占用CPU（效果有限，更多是礼貌） userThread.setPriority(Thread.MIN_PRIORITY); // 启动监控线程 Thread monitorThread = new Thread(() -> { long startTime = System.currentTimeMillis(); long startMemory = getCurrentThreadMemory(); // 这是一个需要自己实现的方法，估算线程内存 while (userThread.isAlive()) { long currentTime = System.currentTimeMillis(); long currentMemory = getCurrentThreadMemory(); // 检查时间限制 if (currentTime - startTime > timeLimitMillis) { result.setExitType(ExitType.TIME_LIMIT_EXCEEDED); userThread.interrupt(); // 尝试中断 // 如果中断无效，可能需要调用 stop()，但该方法已废弃且危险 break; } // 检查内存限制（这里的内存监控非常不精确，是此方案的重大短板） if (currentMemory - startMemory > memoryLimitBytes) { result.setExitType(ExitType.MEMORY_LIMIT_EXCEEDED); userThread.interrupt(); break; } try { Thread.sleep(10); // 每10毫秒检查一次 } catch (InterruptedException ignored) {} } }); monitorThread.setName("Judge-Monitor-" + mainClassName); // 启动用户线程和监控线程 userThread.start(); monitorThread.start(); try { userThread.join(); // 等待用户线程结束 monitorThread.interrupt(); // 停止监控线程 monitorThread.join(); } catch (InterruptedException e) { // 判题机本身被中断 userThread.interrupt(); result.setExitType(ExitType.SYSTEM_ERROR); } return result; } }

重要提示：上面代码中的getCurrentThreadMemory()函数在标准的Java API中并不存在。准确监控单个线程的堆内存使用在Java中是非常困难的。通常的变通方法是：为每个判题任务启动一个独立的JVM进程，通过-Xmx限制其最大堆，然后通过进程的退出码或输出判断是否内存超限。这引出了我们方案的局限性，也解释了为什么对于内存限制要求严格的场景，Docker是更好的选择。

5. 输入输出重定向与结果比对

用户程序不应该直接读写控制台或文件。我们需要将标准输入（System.in）、标准输出（System.out）和标准错误（System.err）重定向到我们控制的流中。

5.1 重定向标准流

在启动用户线程前，我们可以替换掉这些流：

public class IORedirector { public static RedirectedIO setupIO(String inputData) { // 备份原流 PrintStream originalOut = System.out; PrintStream originalErr = System.err; InputStream originalIn = System.in; // 创建我们控制的流 PipedOutputStream userOutPipe = new PipedOutputStream(); PipedInputStream judgeInPipe = new PipedInputStream(userOutPipe); ByteArrayOutputStream userOutput = new ByteArrayOutputStream(); PrintStream userOut = new PrintStream(userOutput); PipedOutputStream userErrPipe = new PipedOutputStream(); PipedInputStream judgeErrPipe = new PipedInputStream(userErrPipe); ByteArrayOutputStream userError = new ByteArrayOutputStream(); PrintStream userErr = new PrintStream(userError); ByteArrayInputStream userInput = new ByteArrayInputStream(inputData.getBytes()); // 重定向 System.setOut(userOut); System.setErr(userErr); System.setIn(userInput); return new RedirectedIO(originalOut, originalErr, originalIn, judgeInPipe, judgeErrPipe, userOutput, userError); } public static void restoreIO(RedirectedIO io) { System.setOut(io.originalOut); System.setErr(io.originalErr); System.setIn(io.originalIn); } static class RedirectedIO { // ... 保存各个流的引用 } }

在用户线程的Runnable中，我们先调用setupIO，执行完用户代码后再调用restoreIO。这样，用户代码中对System.out.println()的调用，其输出就会被捕获到userOutput这个ByteArrayOutputStream中。

5.2 灵活的比对逻辑

比对用户输出和期望输出不是简单的字符串相等。OJ通常需要处理一些常见的格式宽容。

public class OutputComparator { public enum CompareResult { ACCEPTED, WRONG_ANSWER, PRESENTATION_ERROR } public CompareResult compare(String userOutput, String expectedOutput) { if (userOutput == null) userOutput = ""; if (expectedOutput == null) expectedOutput = ""; // 1. 完全一致 if (userOutput.equals(expectedOutput)) { return CompareResult.ACCEPTED; } // 2. 忽略行尾空格比较 String[] userLines = userOutput.split("\n"); String[] expectedLines = expectedOutput.split("\n"); if (userLines.length != expectedLines.length) { return CompareResult.WRONG_ANSWER; } for (int i = 0; i < userLines.length; i++) { // 去除每行末尾的空格和制表符 if (!userLines[i].trim().equals(expectedLines[i].trim())) { // 3. 进一步，可以尝试忽略所有空白字符（空格、制表符、换行）比较 // 这通常用于“Presentation Error”的判断 String userCompact = userOutput.replaceAll("\\s+", ""); String expectedCompact = expectedOutput.replaceAll("\\s+", ""); if (userCompact.equals(expectedCompact)) { return CompareResult.PRESENTATION_ERROR; } else { return CompareResult.WRONG_ANSWER; } } } return CompareResult.ACCEPTED; // 所有行去尾空格后一致 } }

你可以根据OJ的需求调整比对策略，比如是否忽略文末空行、是否区分大小写等。

6. 避坑指南与进阶优化

在实际搭建和运营过程中，你会遇到各种各样的问题。下面是我踩过的一些坑和对应的解决方案。

6.1 常见安全漏洞与加固措施

1. 线程池耗尽：用户代码创建大量线程。加固：在策略文件中拒绝“modifyThreadGroup”和“stopThread”以外的线程相关权限，并在执行前通过反射或Agent手段限制线程创建。更彻底的方法是，在运行用户代码的线程中，替换掉Thread和ThreadGroup的默认实现。
2. 反射攻击：通过setAccessible(true)访问私有字段修改判题机状态。加固：策略中绝对不能授予“suppressAccessChecks”权限。同时，确保判题机核心类（如JudgeTaskRunner）由启动类加载器（Bootstrap ClassLoader）或独立的、用户代码无法访问的类加载器加载。
3. 本地方法调用：用户代码通过System.loadLibrary加载恶意本地库。加固：策略中拒绝所有“loadLibrary.*”权限。这是底线。
4. 死循环与超时中断失效：Thread.interrupt()无法中断某些阻塞IO或死循环。加固：超时监控线程在中断无效后，可以尝试调用已废弃的Thread.stop()作为最后手段（会抛出ThreadDeath异常，可能破坏对象状态，但能保证停止）。更好的做法是，将用户代码放在一个独立的进程里运行，超时后直接终止进程。这引向了“混合架构”的思路。
5. 内存限制形同虚设：如前所述，纯Java方案很难精确限制内存。终极方案：对于Java判题，为每个任务启动一个独立的JVM子进程，使用-Xmx限制堆内存，使用操作系统工具（如ulimit -v）限制虚拟内存。判题机主进程通过进程的退出码和资源使用统计来判断是否超限。

6.2 性能优化与稳定性提升

1. 类加载器缓存：频繁创建销毁自定义类加载器开销大。可以为每个语言或每个题目建立一个可复用的类加载器池，但要注意隔离，避免不同任务间的类污染。
2. 策略文件预编译：动态生成策略对象仍有开销。可以预编译几种基础策略模板（如“完全封闭”、“允许文件IO”、“允许网络”等），根据题目需求快速选择。
3. 进程池模式（推荐用于生产）：这是兼顾安全和资源限制的稳健方案。判题机主进程作为调度器，维护一个“判题工作进程”池。每个工作进程是一个独立的、配置好低权限和资源限制的JVM。主进程通过Socket或标准输入输出与工作进程通信，下发代码和输入，获取输出和结果。工作进程负责具体的编译、安全运行和资源监控。这样，单个工作进程崩溃不会影响主进程，资源限制也由操作系统保证。
4. 完善的日志与监控：记录每一次判题的详细日志：任务ID、使用的策略、运行时间、内存峰值、安全异常等。这有助于事后审计和排查奇葩的提交代码。

6.3 针对不同语言的适配

• Java：本方案最直接的应用对象。编译用javac，运行用我们搭建的沙箱。
• Python：不能直接用SecurityManager。但思路类似：使用subprocess以低权限用户启动Python解释器，并通过resource模块设置CPU时间、内存限制，通过sys.settrace或faulthandler监控。或者，使用pypy的沙箱功能（如果版本支持）。
• C/C++：强烈不建议使用此方案。应使用Docker或更底层的沙箱（如seccomp-bpf+cgroups）。编译后用ptrace或seccomp严格限制系统调用，并用setrlimit限制资源。

7. 总结与选型建议

通过原生Java安全管理器搭建判题机，是一个深刻理解JVM安全模型和沙箱技术的好方法。它轻量、快速，适合作为教学项目或对隔离强度要求不极端（如内部竞赛、作业提交）的场景。

但是，对于面向公众、高安全要求的在线评测平台，纯SecurityManager方案的风险和局限性是显而易见的，尤其是在内存限制和针对本地代码的防御方面。

我的个人建议是：

• 学习与原型：采用本文的SecurityManager方案。它能让你快速搭建一个可工作的OJ核心，并透彻理解安全判题的所有关键环节。
• 小规模内部使用：可以采用“进程隔离为主，SecurityManager为辅”的混合模式。每个任务一个独立JVM进程（严格限制资源），在该进程内部再启用SecurityManager作为第二道防线。
• 生产级公开服务：毫不犹豫地选择Docker。Docker容器提供了操作系统级别的、经过充分测试的隔离，能完美解决资源限制（CPU、内存、磁盘、网络）、文件系统隔离、用户隔离等问题。你可以为每种语言准备一个包含编译和运行环境的Docker镜像，判题机只需要docker run即可。虽然启动开销稍大，但为了安全和省心，这点开销是完全值得的。

技术选型没有银弹。从最原始的SecurityManager沙箱到成熟的容器化方案，这条演进路径本身，就是一个在线评测系统架构师需要思考和权衡的过程。希望这篇详尽的拆解，能为你搭建自己的OJ判题机提供扎实的起点和清晰的路线图。