企业官网建设流程全解析

1. 项目概述：一个在线Java动态编译器的核心价值

最近在做一个内部工具平台，经常需要快速验证一些Java代码片段，比如某个新API的用法、一个算法逻辑是否正确，或者给团队新人演示一个概念。每次都要打开IDE、新建项目、写个main方法、运行，一套流程下来，几分钟就过去了，效率很低。我就想，能不能有一个像LeetCode或者某些在线文档里那种，可以直接在网页里写Java代码，点一下就能看到运行结果的工具？这个想法，就是“在线Java动态运行Java源代码-编译器”项目的起点。

简单来说，这个项目就是一个Web应用，它允许用户在浏览器里输入一段完整的Java源代码（比如一个包含main方法的类），然后后端服务会动态地将这段代码编译成字节码，并在一个受控的、安全的环境里执行它，最后将标准输出、标准错误甚至编译错误信息，实时地返回给前端页面展示。它解决的痛点非常明确：为开发、教学、面试、快速原型验证等场景，提供一个零环境依赖、即时反馈的Java代码运行沙箱。

听起来好像就是把本地的javac和java命令搬到了网上？其实远不止如此。真正的挑战在于如何安全、高效、隔离地执行用户提交的任意代码。用户可能写一个死循环，可能尝试读写服务器文件，甚至可能执行危险的系统命令。如何构建一个既开放又安全的“沙盒”，是这类项目的技术核心。这个项目适合任何需要频繁验证Java代码片段的开发者、技术讲师、面试官，或者单纯想有个地方随手跑段代码的编程爱好者。接下来，我就结合自己的实现过程，拆解一下这里面的门道。

2. 核心架构设计与技术选型考量

要实现一个在线的Java代码运行器，我们不能简单地在服务器上起一个线程就去执行Runtime.getRuntime().exec("java ...")，那无异于敞开大门让黑客随意操作服务器。一个健壮的架构必须围绕安全隔离和资源管控来设计。

2.1 整体架构思路

我设计的核心架构分为三层：Web层、调度与编译层、沙箱执行层。

1. Web层：负责提供代码编辑界面（通常是一个支持语法高亮的编辑器，如CodeMirror或Monaco Editor），接收用户代码和输入，并展示执行结果。这部分可以用任何你熟悉的前端框架，比如Vue或React。
2. 调度与编译层：这是后端服务的核心。它接收前端发来的代码，首先进行一些基本的合法性检查（比如代码长度、是否包含危险关键词的初级过滤）。然后，它需要调用Java编译器API将源代码编译成字节码。这里不能直接用javac命令，而是使用JavaCompiler接口。
3. 沙箱执行层：这是最复杂也最关键的一层。编译好的字节码必须在一个完全隔离的环境中运行。这个环境需要限制代码的权限，包括文件读写、网络访问、反射、执行外部进程、创建线程等。同时，还需要严格限制其运行时间和内存消耗，防止恶意代码耗尽服务器资源。

2.2 关键技术选型与原因

1. 编译工具：Java Compiler API vs. 第三方编译器Java标准库中自带了javax.tools.JavaCompiler，我们可以直接用它来编译内存中的字符串代码，无需生成中间的.java文件。这是最标准、最轻量的选择。也有像Eclipse JDT Core这样的第三方编译器库，功能更强大，但对于我们这个场景，标准API完全够用，且依赖最少。

2. 执行沙箱：Java SecurityManager vs. 容器化隔离这是技术选型的重中之重。传统上，Java使用SecurityManager配合策略文件（Policy File）来构建沙箱。我们可以自定义一个严格的SecurityManager，禁止所有文件权限、网络权限、退出JVM等。但是，SecurityManager在JDK 17及以上版本中已被标记为废弃，并在后续版本中计划移除。这意味着依赖它不是一个面向未来的方案。

因此，更现代、更彻底的隔离方案是容器化。我们可以为每一次代码执行启动一个全新的、资源受限的Docker容器。容器内部运行一个极简的JRE，只加载我们编译好的类文件。容器本身提供了内核级别的隔离，安全性远高于SecurityManager。同时，Docker可以方便地限制CPU时间、内存大小、进程数等。我最终选择了基于Docker的方案，虽然复杂度更高，但它是目前业界实现代码沙箱的主流和推荐做法。

3. 类加载机制：自定义ClassLoader即使用Docker隔离，在容器内部，我们仍然需要动态加载编译好的字节码。这里需要使用自定义的ClassLoader。为什么？因为用户提交的类名可能是任意的（如Test、Solution、Main），我们需要一个ClassLoader能够从我们指定的地方（比如一个字节数组，或者一个临时目录下的.class文件）去加载这个类，而不是从系统的classpath中加载。自定义ClassLoader给了我们这种灵活性。

4. 超时与资源控制即使用户代码没有恶意，一个不经意的死循环也会挂起执行线程。我们必须有能力中断长时间运行的任务。在容器外，我们可以用Future和线程池来管理执行任务，并设置超时。在容器内，除了Docker本身的--cpu-time和--memory限制，我们还需要在Java层面监控执行时间，必要时中断它。这可以通过在独立线程中运行用户代码，并使用Thread.stop()（不推荐，已废弃）或更优雅地，通过一个监控线程来中断目标线程（前提是用户代码要能响应中断）来实现。更粗暴但有效的方法是：如果超时，直接销毁整个Docker容器。

3. 核心模块实现细节与实操要点

明确了架构和技术栈，我们来深入每个核心模块的实现细节。我会以Spring Boot作为后端框架来举例，因为它生态完善，能简化很多配置。

3.1 动态编译模块实现

我们使用JavaCompiler进行编译。关键点在于，我们需要在内存中完成编译，避免磁盘I/O。

import javax.tools.*; import java.util.Arrays; import java.util.List; import java.util.ArrayList; public class InMemoryJavaCompiler { private JavaCompiler compiler; private StandardJavaFileManager fileManager; private List<ByteArrayJavaClass> compiledClasses; // 用于存放编译后字节码的容器 public static class ByteArrayJavaClass extends SimpleJavaFileObject { private ByteArrayOutputStream outputStream; protected ByteArrayJavaClass(String className) { super(URI.create("bytes:///" + className.replace('.', '/') + ".class"), Kind.CLASS); this.outputStream = new ByteArrayOutputStream(); } @Override public OutputStream openOutputStream() { return outputStream; } public byte[] getBytes() { return outputStream.toByteArray(); } } // 代表源代码的容器 public static class JavaSourceFromString extends SimpleJavaFileObject { final String code; protected JavaSourceFromString(String name, String code) { super(URI.create("string:///" + name.replace('.', '/') + Kind.SOURCE.extension), Kind.SOURCE); this.code = code; } @Override public CharSequence getCharContent(boolean ignoreEncodingErrors) { return code; } } public InMemoryJavaCompiler() { this.compiler = ToolProvider.getSystemJavaCompiler(); if (this.compiler == null) { throw new RuntimeException("无法获取系统Java编译器。请确保在JDK环境下运行，而不是JRE。"); } this.fileManager = compiler.getStandardFileManager(null, null, null); this.compiledClasses = new ArrayList<>(); } public Map<String, byte[]> compile(String className, String sourceCode) throws Exception { // 准备编译单元 JavaSourceFromString src = new JavaSourceFromString(className, sourceCode); Iterable<? extends JavaFileObject> compilationUnits = Arrays.asList(src); // 设置编译目标，将输出重定向到我们的ByteArrayJavaClass DiagnosticCollector<JavaFileObject> diagnostics = new DiagnosticCollector<>(); fileManager = new ForwardingJavaFileManager<StandardJavaFileManager>(fileManager) { @Override public JavaFileObject getJavaFileForOutput(Location location, String className, JavaFileObject.Kind kind, FileObject sibling) { ByteArrayJavaClass cls = new ByteArrayJavaClass(className); compiledClasses.add(cls); return cls; } }; // 执行编译 JavaCompiler.CompilationTask task = compiler.getTask(null, fileManager, diagnostics, null, null, compilationUnits); boolean success = task.call(); // 处理编译结果 if (!success) { StringBuilder errorMsg = new StringBuilder("编译失败:\n"); for (Diagnostic<? extends JavaFileObject> diagnostic : diagnostics.getDiagnostics()) { errorMsg.append(String.format("行 %d: %s%n", diagnostic.getLineNumber(), diagnostic.getMessage(null))); } throw new CompilationException(errorMsg.toString()); } // 返回类名到字节码的映射 Map<String, byte[]> result = new HashMap<>(); for (ByteArrayJavaClass cls : compiledClasses) { // 从URI中解析出类名 String name = cls.getName(); result.put(name, cls.getBytes()); } compiledClasses.clear(); return result; } }

实操要点与避坑指南：

• JDK vs JRE：ToolProvider.getSystemJavaCompiler()在标准的JRE环境中是null，因为tools.jar（包含编译器）通常只在JDK中。部署时务必确保运行环境是JDK，或者将tools.jar显式添加到类路径。在Docker镜像构建时，要选择JDK基础镜像（如openjdk:17-jdk-slim），而不是JRE镜像。
• 类名匹配：用户提交的源代码中的public class名称必须与我们在编译时传入的className参数一致，否则编译会失败。通常我们可以从源代码字符串中正则匹配出类名，或者强制要求用户主类必须命名为Main。
• 内存管理：InMemoryJavaCompiler实例和编译产生的字节码可能会占用不少内存，尤其是在高并发下。建议将其设计为无状态工具类，或者使用对象池，并及时清理compiledClasses这样的容器，防止内存泄漏。
• 依赖问题：这个简单的编译器只能处理不依赖第三方库的代码。如果用户想用import com.google.gson...，我们需要更复杂的机制来管理依赖的classpath，这通常需要结合Maven或Gradle，复杂度会指数级上升。对于初级版本，明确声明不支持外部库。

3.2 Docker沙箱执行模块实现

这是安全性的基石。我们的目标是：为每一次执行请求，启动一个全新的容器，在容器内运行用户代码，获取输出，然后无论成功与否，都销毁容器。

第一步：准备Docker镜像我们需要一个包含Java运行环境的轻量级Docker镜像。Dockerfile示例如下：

FROM openjdk:17-jdk-slim AS builder # 这个阶段可以预先准备一些东西，比如安全策略文件（如果还用SecurityManager的话） FROM openjdk:17-jre-slim # 使用JRE足以运行编译好的字节码，更轻量。 WORKDIR /app # 创建一个非root用户运行Java程序，增加安全性 RUN useradd -m -u 1000 runner USER runner # 不需要暴露端口，因为通过标准输入输出和文件与宿主机通信

构建并推送镜像到仓库：docker build -t my-java-sandbox:latest .

第二步：在Java服务中调用Docker API我们可以使用Docker的Java客户端库，如docker-java，或者更简单地，通过Runtime.getRuntime().exec执行docker run命令。为了更好的控制，我推荐使用docker-java。

首先添加依赖（Maven）：

<dependency> <groupId>com.github.docker-java</groupId> <artifactId>docker-java</artifactId> <version>3.3.0</version> </dependency>

核心执行服务代码如下：

import com.github.dockerjava.api.DockerClient; import com.github.dockerjava.api.command.CreateContainerCmd; import com.github.dockerjava.api.command.CreateContainerResponse; import com.github.dockerjava.api.command.WaitContainerResultCallback; import com.github.dockerjava.core.DockerClientBuilder; import com.github.dockerjava.api.model.HostConfig; @Service public class DockerSandboxService { private final DockerClient dockerClient; private final String sandboxImage = "my-java-sandbox:latest"; public DockerSandboxService() { // 连接到本地Docker守护进程。生产环境可能需要配置TCP或SSH连接。 this.dockerClient = DockerClientBuilder.getInstance().build(); } public ExecutionResult executeInContainer(byte[] classBytes, String className, String input, long timeoutMillis) { ExecutionResult result = new ExecutionResult(); String containerId = null; try { // 1. 创建容器，并严格限制资源 CreateContainerCmd createCmd = dockerClient.createContainerCmd(sandboxImage) .withCmd("java", "-cp", "/app", className) // 运行命令 .withHostConfig(HostConfig.newHostConfig() .withMemory(100 * 1024 * 1024L) // 限制内存为100MB .withMemorySwap(0L) // 禁止使用交换分区，内存限制更严格 .withCpuCount(1L) // 限制CPU核数 .withCpuQuota(50000L) // 限制CPU时间片，单位微秒 .withPidsLimit(50L) // 限制最大进程数 .withReadonlyRootfs(true) // 根文件系统只读，防止写文件 .withNetworkMode("none") // 禁用网络访问 ) .withAttachStdin(true) .withAttachStdout(true) .withAttachStderr(true) .withTty(false); // 必须为false才能正确捕获输出 CreateContainerResponse container = createCmd.exec(); containerId = container.getId(); // 2. 将编译好的字节码复制到容器内 try (ByteArrayInputStream bis = new ByteArrayInputStream(classBytes)) { dockerClient.copyArchiveToContainerCmd(containerId) .withTarInputStream(bis) // 需要将字节码打包成tar流 .withRemotePath("/app") .exec(); } // 3. 启动容器 dockerClient.startContainerCmd(containerId).exec(); // 4. 附加到容器，获取输出流（用于发送输入）和读取输出 // 这里逻辑较复杂，需要异步处理标准输入、输出和错误的流。 // 通常使用 `dockerClient.attachContainerCmd(...)` 和 `ExecStartResultCallback`。 // 同时，需要启动一个超时监控线程。 // 由于代码较长，此处省略具体的流处理逻辑，其核心是： // - 将用户输入（input）写入容器的标准输入。 // - 从容器的标准输出和标准错误流中读取数据。 // - 设置一个Timer或CompletableFuture，在超时后强制停止容器。 // 5. 等待容器结束（或超时被终止） Integer exitCode = dockerClient.waitContainerCmd(containerId) .exec(new WaitContainerResultCallback()).awaitStatusCode(); result.setExitCode(exitCode); // ... 将从流中读取到的stdout和stderr设置到result中 } catch (Exception e) { result.setError("执行过程中发生异常: " + e.getMessage()); } finally { // 6. 无论如何，尝试清理容器 if (containerId != null) { try { dockerClient.removeContainerCmd(containerId).withForce(true).exec(); } catch (Exception e) { // 记录日志，但不要影响主流程 } } } return result; } }

实操要点与避坑指南：

• Docker守护进程连接：确保运行后端服务的机器有Docker守护进程，并且运行服务的用户有权限执行docker命令（通常在docker用户组内）。生产环境考虑更安全的连接方式。
• 资源限制是硬约束：withMemory()和withCpuQuota()等设置是防止恶意代码拖垮服务器的关键。需要根据服务器配置和并发量仔细调优。内存限制过小可能导致正常程序也无法运行。
• 流处理的复杂性：与容器进行输入输出交互的异步流处理是代码中最易出错的部分。需要妥善处理缓冲区、编码（UTF-8）、以及流关闭逻辑。强烈建议将这部分逻辑封装成一个独立的、经过充分测试的工具类。
• 容器清理：finally块中的容器清理至关重要，否则会导致大量“僵尸”容器占用资源。即使执行失败，也必须强制移除容器。
• 性能开销：每次执行都创建和销毁容器，开销巨大。对于高并发场景，可以考虑容器池化技术（预热一批容器，执行完后不销毁，只重置状态），但这会显著增加安全管理的复杂度（需要确保容器在复用前是完全干净的）。

3.3 类加载与反射执行模块

在Docker容器内，我们通过java -cp /app Main来运行程序，这其实是由容器内的系统类加载器完成的。但在某些架构下（比如不使用Docker，或者想在宿主机JVM内做更深度的集成测试），我们可能需要在服务端JVM内直接加载并执行字节码。这时，自定义类加载器和反射就派上用场了。

public class SandboxClassLoader extends ClassLoader { private Map<String, byte[]> classBytesMap; public SandboxClassLoader(Map<String, byte[]> classBytesMap) { this.classBytesMap = classBytesMap; } @Override protected Class<?> findClass(String name) throws ClassNotFoundException { byte[] bytes = classBytesMap.get(name); if (bytes == null) { throw new ClassNotFoundException(name); } // defineClass 是核心，它将字节数组转换为Class对象 return defineClass(name, bytes, 0, bytes.length); } } public class InJvmExecutor { public ExecutionResult execute(byte[] mainClassBytes, String mainClassName, String[] args) { ExecutionResult result = new ExecutionResult(); Thread runThread = Thread.currentThread(); // 注意，这里只是示意 SecurityManager oldSm = System.getSecurityManager(); try { // 1. 安装一个严格的安全管理器（如果JDK版本允许） // System.setSecurityManager(new MyStrictSecurityManager()); // 2. 使用自定义类加载器加载类 Map<String, byte[]> map = new HashMap<>(); map.put(mainClassName, mainClassBytes); SandboxClassLoader loader = new SandboxClassLoader(map); Class<?> loadedClass = loader.loadClass(mainClassName); // 3. 找到main方法 Method mainMethod = loadedClass.getMethod("main", String[].class); mainMethod.setAccessible(true); // main方法是public的，这步通常不需要，但保持习惯 // 4. 重定向标准输出和错误，以捕获用户程序的打印内容 ByteArrayOutputStream baosOut = new ByteArrayOutputStream(); ByteArrayOutputStream baosErr = new ByteArrayOutputStream(); PrintStream originalOut = System.out; PrintStream originalErr = System.err; System.setOut(new PrintStream(baosOut)); System.setErr(new PrintStream(baosErr)); // 5. 在独立线程中执行，以便控制超时 ExecutorService executor = Executors.newSingleThreadExecutor(); Future<?> future = executor.submit(() -> { try { mainMethod.invoke(null, (Object) args); } catch (Exception e) { throw new RuntimeException(e); } }); try { future.get(5, TimeUnit.SECONDS); // 设置超时时间 result.setStdout(baosOut.toString(StandardCharsets.UTF_8.name())); result.setStderr(baosErr.toString(StandardCharsets.UTF_8.name())); } catch (TimeoutException e) { future.cancel(true); // 尝试中断 result.setError("执行超时"); } catch (ExecutionException e) { result.setError("执行异常: " + e.getCause().getMessage()); result.setStderr(baosErr.toString(StandardCharsets.UTF_8.name())); } finally { executor.shutdownNow(); } // 6. 恢复标准流 System.setOut(originalOut); System.setErr(originalErr); } catch (Exception e) { result.setError("加载或执行类时出错: " + e.getMessage()); } finally { // 恢复原来的安全管理器 System.setSecurityManager(oldSm); } return result; } }

实操要点与避坑指南：

• 类加载器隔离：使用自定义的SandboxClassLoader加载用户代码，可以实现与服务器自身类路径的隔离。用户代码无法访问到服务器类路径上的其他类（除非是父加载器委托加载的系统类，如java.lang.String）。这提供了一层基本的保护。
• SecurityManager的局限性：如上文所述，它正在被淘汰。而且，一个配置不当的SecurityManager很容易被绕过（例如通过反射修改其本身）。它只能作为防御的一环，而非唯一手段。
• 线程中断不总是有效：future.cancel(true)会尝试中断执行线程。但如果用户代码中没有检查中断状态（Thread.interrupted()）或者正阻塞在不可中断的I/O上，线程将无法停止。这是纯Java沙箱的一个重大缺陷。Docker容器级别的终止（docker stop）则更为强力可靠。
• 资源限制困难：在同一个JVM内，很难精确限制用户代码的内存使用和CPU时间。虽然可以通过Thread监控，但控制力远不如操作系统或容器层面。
• 标准流重定向的线程安全：System.setOut是全局操作。在高并发环境下，多个请求同时重定向会导致输出混乱。必须确保这段代码是线程隔离的，或者使用更高级的、每个线程独立的输出捕获机制。

4. 前端交互与完整工作流整合

后端核心搞定后，我们需要一个简单的前端界面和一套完整的API来串联整个流程。

4.1 前端界面设计要点

前端不需要太复杂，核心是一个代码编辑器、一个运行按钮、以及输出显示区域。

• 编辑器：推荐使用Monaco Editor（VS Code使用的编辑器），它功能强大，支持Java语法高亮、智能提示、错误检查等。可以通过monaco-editornpm包集成到Vue/React项目中。
• 交互：提供基本的运行、停止、清空按钮。可以考虑增加选择JDK版本、输入参数、执行时间限制等高级选项。
• 输出展示：最好将标准输出、标准错误、编译错误分标签页或不同颜色区域显示，方便用户区分。对于运行时间、内存消耗等指标也可以展示出来。

4.2 后端API与工作流

设计一个简单的REST API端点，例如POST /api/execute/java。

请求体：

{ "sourceCode": "public class Main {\n public static void main(String[] args) {\n System.out.println(\"Hello, World!\");\n }\n}", "input": "", "timeout": 10000 }

响应体：

{ "success": true, "compileOutput": null, "stdout": "Hello, World!\n", "stderr": "", "error": null, "executionTime": 125, "memoryUsed": 20480 }

完整工作流如下：

1. 用户在前端编写代码，点击“运行”。
2. 前端将代码和参数通过AJAX发送到后端/api/execute/java。
3. 后端控制器（Controller）接收请求，进行基础验证（如代码非空、长度限制）。
4. 控制器调用InMemoryJavaCompiler.compile()进行编译。
   • 如果编译失败，直接返回编译错误信息。
5. 编译成功，获得字节码。控制器调用DockerSandboxService.executeInContainer()。
   • 该方法负责创建容器、复制字节码、执行、监控、获取输出、清理容器。
6. DockerSandboxService返回ExecutionResult。
7. 控制器将结果封装成API响应格式，返回给前端。
8. 前端解析响应，将输出内容渲染到界面上。

性能与并发考量：

• 异步处理：代码执行可能耗时较长（几秒到几十秒），HTTP请求不能同步阻塞。应该采用异步任务处理。用户提交后，立即返回一个任务ID（如taskId）。后端通过消息队列或线程池异步执行，并将结果存入缓存（如Redis）。前端轮询另一个API（如GET /api/task/{taskId}）来获取执行结果。
• 限流与队列：为了防止资源被耗尽，必须对执行请求进行限流。可以使用令牌桶或漏桶算法，或者简单的队列机制，控制同时运行的容器数量。
• 结果缓存：对于完全相同的代码和输入，可以考虑缓存执行结果一段时间，避免重复编译和运行，提升响应速度。但要注意缓存键需要包含代码、输入、环境参数（JDK版本）等。

5. 高级特性拓展与安全加固思考

一个基础版本完成后，可以考虑增加更多实用和安全的特性。

5.1 支持基础输入（stdin）

很多算法题需要从标准输入读取数据。在我们的架构中，这很容易实现。在DockerSandboxService.executeInContainer方法里，我们在启动容器后，通过附加到容器的标准输入流（stdin），将用户提供的输入字符串写入即可。前端需要增加一个“输入”文本框。

5.2 支持多文件与简单依赖

现实中的Java代码往往由多个类组成。我们可以约定一种格式，比如用户提交一个ZIP文件，或者在前端通过项目树管理多个.java文件。后端编译时，需要处理多个编译单元。对于依赖，初级方案是预装一些常用库（如JUnit, Apache Commons Lang）到Docker镜像中，并告知用户可用的依赖列表。高级方案则需要集成Maven，动态解析pom.xml并下载依赖，这复杂度极高。

5.3 更深入的安全加固

Docker提供了很好的隔离，但并非绝对安全。恶意代码仍可能尝试进行Docker逃逸攻击。以下是一些加固思路：

• 使用更安全的容器运行时：考虑使用gVisor或Kata Containers，它们提供了更强的内核隔离。
• Seccomp BPF配置：为Docker容器配置定制的Seccomp配置文件，严格限制可用的系统调用，进一步减少攻击面。
• AppArmor/SELinux：为容器启用强制访问控制策略。
• 无Root运行：如Dockerfile所示，在容器内使用非root用户运行Java进程。
• 禁用能力：在HostConfig中，使用.withCapDrop("ALL")丢弃所有Linux能力，然后按需添加极少数必需的能力。
• 文件系统白名单：虽然设置了readonlyRootfs，如果必须允许写文件，可以挂载一个临时tmpfs卷到特定目录（如/tmp），并确保只有该目录可写。

5.4 监控与日志

记录每一次代码执行的元数据：执行时间、内存峰值、是否成功、代码片段哈希（用于去重统计）、IP地址（用于风控）等。这有助于分析使用情况，并识别潜在的攻击模式（如有人频繁提交死循环代码）。日志要避免记录完整的用户代码，以防泄露用户隐私。

6. 常见问题、故障排查与优化实录

在实际开发和运维中，肯定会遇到各种问题。这里记录一些我踩过的坑和解决方案。

问题1：编译时报错“找不到符号”或“程序包xxx不存在”

• 原因：用户代码中引用了不存在的类或未提供的库。
• 排查：检查编译错误信息。如果是标准Java库（如java.util.*），没问题。如果是第三方库，则当前环境不支持。
• 解决：在前端界面明确提示“不支持外部依赖”，或提供一份预装库的列表。对于多文件项目，确保所有关联的.java文件都被正确提交和编译。

问题2：Docker容器启动失败，报“Driver failed programming external connectivity”或端口冲突

• 原因：通常是因为容器配置了端口映射，但宿主机端口已被占用。我们的沙箱容器不需要映射端口。
• 排查：检查docker run命令或docker-java的HostConfig中是否误设置了端口绑定（-p）。
• 解决：确保创建容器时，网络模式设置为none或bridge但不进行端口映射。我们的场景下，容器与外界通过标准流和文件系统交互，无需网络。

问题3：用户程序输出包含乱码

• 原因：字符编码不一致。用户程序输出可能是系统默认编码，而我们在读取流时可能用了UTF-8或其他编码。
• 排查：检查容器内JVM的默认编码（file.encoding），以及服务端读取流时指定的编码。
• 解决：在启动容器时，显式设置JVM参数-Dfile.encoding=UTF-8。在服务端读取容器输出流时，也明确使用UTF-8编码进行解码。

问题4：执行简单程序很快，但高并发下服务响应变慢甚至崩溃

• 原因：容器创建/销毁、镜像拉取、网络开销累积。同时，大量编译任务和类加载也可能导致服务端JVM内存压力大。
• 排查：监控服务器CPU、内存、磁盘I/O，以及Docker守护进程的资源使用情况。查看服务日志是否有OutOfMemoryError。
• 优化：
  • 容器池化：预先创建一批处于“就绪”状态的容器池。收到请求时，从池中分配一个容器，执行完毕后再放回池中并清理内部状态（如删除临时文件）。这避免了每次创建容器的开销。需要自己实现池的管理和状态重置逻辑。
  • 编译结果缓存：对源代码进行哈希（如MD5），将编译后的字节码缓存起来。同一段代码的多次执行，只需编译一次。
  • 异步与非阻塞：确保整个处理链路是异步的，避免阻塞HTTP线程。使用响应式编程（如WebFlux）或更高效的线程池模型。
  • 资源配额与排队：实现一个带优先级的任务队列，并严格限制同时执行的容器数量，超出限制的请求排队或直接拒绝（返回“系统繁忙”）。

问题5：如何防止用户代码进行恶意系统调用？

• 原因：即使用了Docker，如果容器内的用户以root身份运行，且容器配置不当，仍有可能进行危险操作。
• 加固：
  • 非Root用户：如Dockerfile示例，在容器内创建并使用非root用户。
  • 移除Linux能力：--cap-drop=ALL移除所有权限，这是最严格的。
  • 只读根文件系统：--read-only防止写入任何文件。
  • 禁用网络：--network=none。
  • 使用安全计算模式（seccomp）：加载一个限制严格的seccomp配置文件，只允许白名单内的系统调用。

问题6：用户代码包含System.exit(0)怎么办？

• 在Docker容器内：这会导致容器内的Java进程退出，容器状态变为“Exited”。我们的执行服务会检测到容器退出，并读取退出前的输出。这属于正常行为，只需在结果中标记“程序正常退出”即可。
• 在共享JVM沙箱内（不推荐）：这会直接导致承载沙箱的JVM进程退出，造成服务崩溃！这就是为什么必须使用SecurityManager来禁止exitVM权限，或者更根本地，必须使用容器进行隔离。

实现一个在线Java代码运行器，就像搭建一个数字化的“编程操场”，技术难点集中在对“未知代码”的管控上。从最初简单的编译执行，到引入Docker实现强隔离，再到考虑并发、缓存、安全加固，整个过程是对后端开发者综合能力的一次考验。这个项目最有价值的部分，不在于功能多么炫酷，而在于它在开放性和安全性之间寻找平衡点的设计思路。每增加一个功能（比如文件操作、网络访问），都要重新评估其带来的安全风险。我个人在实践中最大的体会是：对于执行不可信代码，隔离层的选择决定了安全性的下限。基于容器的方案虽然重，但给了我们一个相对可靠的底线。在这个基础上，再去优化性能、丰富功能，心里会踏实很多。如果你也想动手做一个，建议从最简化的版本开始：一个编译接口，一个固定参数的docker run命令。先跑通流程，再逐步迭代安全和性能特性，这样更容易把握全局。