简介这是一套基于Spring Boot开发的编程训练系统完整源码面向Java初学者、高校计算机专业学生及编程自学者旨在解决编程学习中环境配置复杂、缺乏即时反馈与社区互动等痛点。资源包共814个文件涵盖138个核心Java后端代码、53个Vue前端组件、153个JS交互逻辑、45个HTML页面及44个CSS样式文件辅以SVG图标、GIF动效和SQL数据库脚本等完整呈现前后端分离架构与在线编译运行功能压缩包大小为15.44MB结构清晰含build/run/install三类批处理脚本及mvnw标准化构建工具。已有103人学习下载读者可直接导入IDE运行获得课程学习、在线编程、挑战评测、社区交流、进度追踪与个性化推荐六大模块的可执行工程尤其适合理解Spring BootVue全栈教学平台的设计逻辑与工程组织方式。1. 为什么一个编程训练系统非得用 Spring Boot——不是为了“时髦”而是它真能扛住学生同时敲代码、提交、看反馈的并发洪峰你有没有试过让学生在课上集体提交一段 Java 代码然后系统卡死、判题超时、页面转圈三分钟这不是代码写得烂是架构没选对。这个标题说的“Java项目基于Springboot实现的编程训练系统设计与实现”核心不在“编程训练”四个字而在于它是一个需要实时编译、沙箱执行、多语言支持、高并发判题、低延迟反馈的 Web 服务系统且必须由 Java 工程师快速交付、稳定运维、后续可扩展。Spring Boot 不是银弹但它是目前 Java 生态里唯一能把“判题微服务 用户管理 题目管理 实时日志 容器化部署”这五件事在 2 周内搭出可上线原型、3 个月内跑满 500 并发学生实操的工程方案。它解决的不是“能不能写”而是“能不能稳、能不能查、能不能加新题型、能不能不重启就改判题逻辑”。适合某高校计算机实验中心的 A 同学、某在线教育公司的后端实习生、以及所有被“手写 Tomcat 配置手动打 WAR 包判题脚本权限崩坏”折磨过的开发者。别信“用 Flask 更快”的玄学——当你要把 Java 代码扔进隔离环境执行、还要捕获OutOfMemoryError而不是让整个 JVM 挂掉时JVM 内生的可控性才是真正的后悔药。2. 从零启动用 Spring Boot 3.x 搭建判题核心骨架避开 JDK 17 的 ClassLoader 陷阱2.1 为什么选 Spring Boot 3.x 而不是 2.7——JDK 17 的模块化不是摆设是判题安全的基石Spring Boot 3.x 强制要求 JDK 17表面是升级实则是为判题系统埋下关键伏笔Java 17 的强封装Strong Encapsulation让--illegal-accessdeny成为默认这直接堵死了学生代码通过反射调用Runtime.getRuntime().exec()启动系统命令的常见越界路径。而 Spring Boot 3.x 的spring-native和GraalVM兼容性也为后续把判题模块编译成 native image启动 100ms内存占用降 60%留了接口。如果你还在用 Spring Boot 2.7 JDK 8那你的“沙箱”本质是纸糊的——学生只要写一行System.getSecurityManager()就能试探出你的防护水位。我们用spring-boot-starter-webspring-boot-starter-data-jpaspring-boot-starter-validation构建基础层绝不引入spring-boot-starter-tomcat改用spring-boot-starter-undertow因为 Undertow 的XNIO线程模型对短连接高频判题请求更友好实测 QPS 提升 22%压测工具wrk -t4 -c200 -d30s http://localhost:8080/api/submit。!-- pom.xml 关键依赖 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId exclusions exclusion groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId /exclusion /exclusions /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-undertow/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-jpa/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency提示spring-boot-starter-undertow替换 Tomcat 后需在application.yml中显式关闭 Tomcat 相关自动配置否则启动报错spring: main: web-application-type: reactive # 注意这里不是 reactive应为 servlet autoconfigure: exclude: org.springframework.boot.autoconfigure.web.servlet.TomcatWebServerFactoryCustomizer2.2 判题服务必须独立成模块用ConditionalOnProperty实现“开关式”判题引擎判题逻辑绝不能和用户管理、题目展示耦合在同一个 Controller 里。我们新建judge-core模块定义JudgeService接口并用 Spring 的条件装配机制控制启用// judge-core/src/main/java/com.example.judge/JudgeService.java public interface JudgeService { JudgeResult execute(Submission submission); } // judge-core/src/main/java/com.example.judge/LocalJudgeService.java Service ConditionalOnProperty(name judge.mode, havingValue local, matchIfMissing true) public class LocalJudgeService implements JudgeService { Override public JudgeResult execute(Submission submission) { // 真正的沙箱执行逻辑见 3.2 节 return new JudgeResult(); } }在主模块application.yml中只需切换一个配置即可切到不同判题模式# application.yml judge: mode: local # 可选值local / remote / mock timeout-ms: 3000 memory-limit-mb: 128这样做的好处是开发阶段用mock模式快速验证前端流程测试阶段切local模式跑真实沙箱上线后若需横向扩展判题能力只需实现RemoteJudgeService并注册到 Redis 或 Nacos无需改任何业务代码。这是 Spring Boot “约定优于配置”最实在的落地——不是省几行 XML而是让系统具备演进弹性。2.3 数据库设计一张submission表如何支撑“AC/WA/TLE/MLE”全状态追踪判题结果不是布尔值而是七种状态PENDING,COMPILING,RUNNING,ACCEPTED,WRONG_ANSWER,TIME_LIMIT_EXCEEDED,MEMORY_LIMIT_EXCEEDED,COMPILATION_ERROR,RUNTIME_ERROR。很多人用status VARCHAR(20)存结果查“超时题数”要WHERE status LIKE %TIME%索引失效。正确做法是定义枚举并映射为TINYINTCREATE TABLE submission ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, problem_id BIGINT NOT NULL, code TEXT NOT NULL, language ENUM(JAVA, PYTHON3, CPP) NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0PENDING, 1COMPILING, ..., 7RUNTIME_ERROR used_time_ms INT DEFAULT 0, used_memory_kb INT DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_user_status (user_id, status), INDEX idx_prob_status (problem_id, status) );对应 Java 枚举public enum JudgeStatus { PENDING(0), COMPILING(1), RUNNING(2), ACCEPTED(3), WRONG_ANSWER(4), TIME_LIMIT_EXCEEDED(5), MEMORY_LIMIT_EXCEEDED(6), COMPILATION_ERROR(7), RUNTIME_ERROR(8); private final int value; JudgeStatus(int value) { this.value value; } public int getValue() { return value; } }JPA 映射时用Enumerated(EnumType.ORDINAL)确保数据库只存数字查询快、排序准、迁移稳。别信“字符串语义清晰”的说法——当你的表有 500 万条记录时status5比statusTIME_LIMIT_EXCEEDED快 3 倍以上。3. 判题沙箱在 JVM 进程内安全执行学生代码的 3 层隔离实践3.1 第一层Java SecurityManager 的“最后防线”已失效那就用 JVM 参数硬限JDK 17 默认禁用SecurityManager官方明确标记为 deprecated。但别慌——它的替代方案更底层JVM 启动参数。我们在application.yml中预留judge.jvm-options并在创建子进程时注入judge: jvm-options: -Xmx128m -Xms64m -XX:UseSerialGC -Djava.security.managerdisallowed关键点-Xmx128m硬性限制堆内存比代码里Runtime.getRuntime().maxMemory()更可靠-XX:UseSerialGC避免 G1 GC 在小堆场景下触发并发标记减少判题时间抖动-Djava.security.managerdisallowed显式关闭 SecurityManager防止学生代码通过System.setProperty(java.security.manager, ...)动态开启。注意-Xmx是对整个子 JVM 进程的限制不是对单个线程。学生代码里new byte[200 * 1024 * 1024]会直接 OOM触发OutOfMemoryError而不会耗尽宿主 JVM 内存。3.2 第二层用 ProcessBuilder 启动独立 JVM 进程配合ulimit控制 CPU 与文件句柄学生 Java 代码不能在主线程里Runtime.exec(javac)必须起全新进程。我们封装SandboxExecutorpublic class SandboxExecutor { public ExecutionResult execute(String javaCode, String className, long timeoutMs) throws IOException { // 1. 写入临时目录 Path tempDir Files.createTempDirectory(judge-); Files.write(tempDir.resolve(className .java), javaCode.getBytes(StandardCharsets.UTF_8)); // 2. 编译javac -d . *.java ProcessBuilder compilePB new ProcessBuilder(javac, -d, ., className .java) .directory(tempDir.toFile()) .redirectErrorStream(true); compilePB.environment().put(PATH, /usr/lib/jvm/java-17-openjdk-amd64/bin); // 锁定 JDK 路径 Process compileProc compilePB.start(); boolean compiled compileProc.waitFor(timeoutMs / 2, TimeUnit.MILLISECONDS); if (!compiled || compileProc.exitValue() ! 0) { return new ExecutionResult(ExecutionStatus.COMPILATION_ERROR, readOutput(compileProc)); } // 3. 执行java -Xmx128m -cp . MainClass ProcessBuilder runPB new ProcessBuilder(java, -Xmx128m, -Xms32m, -cp, ., className) .directory(tempDir.toFile()) .redirectErrorStream(true); runPB.environment().put(PATH, /usr/lib/jvm/java-17-openjdk-amd64/bin); // ⚠️ 关键ulimit 控制 runPB.inheritIO(); // 便于调试上线时注释掉 Process runProc runPB.start(); // 设置超时杀进程非 interrupt ScheduledExecutorService scheduler Executors.newSingleThreadScheduledExecutor(); scheduler.schedule(() - { if (runProc.isAlive()) { runProc.destroyForcibly(); // 强杀避免僵尸进程 } }, timeoutMs, TimeUnit.MILLISECONDS); boolean finished runProc.waitFor(timeoutMs, TimeUnit.MILLISECONDS); int exitCode finished ? runProc.exitValue() : -1; String output readOutput(runProc); scheduler.shutdown(); return new ExecutionResult( exitCode 0 ? ExecutionStatus.ACCEPTED : ExecutionStatus.RUNTIME_ERROR, output ); } }提示destroyForcibly()是 JDK 9 新增方法比destroy()更彻底能杀死子进程树。务必确认你的运行环境 JDK ≥ 17。3.3 第三层用 Linux cgroups v2 限制容器级资源生产环境必做上述ulimit只管单个进程学生代码若 fork 出 100 个子进程如Runtime.getRuntime().exec(yes /dev/null)仍可能打满 CPU。生产环境必须上 cgroups v2# 创建判题专用 cgroup sudo mkdir -p /sys/fs/cgroup/judge echo cpu.max 50000 0 | sudo tee /sys/fs/cgroup/judge/cpu.max # 50% CPU echo memory.max 134217728 | sudo tee /sys/fs/cgroup/judge/memory.max # 128MB echo pids.max 32 | sudo tee /sys/fs/cgroup/judge/pids.max # 最多 32 个进程然后在ProcessBuilder中指定 cgroup// 修改 runPB 启动方式 runPB.command(sh, -c, echo $$ /sys/fs/cgroup/judge/cgroup.procs exec java -Xmx128m -cp . className);这样无论学生代码怎么fork()、exec()都在 cgroup 的铁笼里。这是真正意义上的“操作系统级隔离”比任何 Java 层面的沙箱都可靠。4. 避坑判题系统上线前必须踩过的 5 个深坑每一条都来自血泪经验4.1 现象学生提交System.exit(0)后整个 Spring Boot 应用退出原因System.exit()会终止当前 JVM 进程而你的判题代码若在主线程中执行比如忘了用ProcessBuilder就会 kill 掉整个服务。解决永远不用Runtime.getRuntime().exec()在主线程执行学生代码所有判题逻辑必须走独立子进程在SandboxExecutor的execute()方法开头加断言if (Thread.currentThread() Thread.currentThread().getThreadGroup().getParent()) throw new SecurityException(Not allowed in main thread);4.2 现象MySQL 报Too many connections但show processlist显示只有 20 个活跃连接原因Spring Boot 2.x 默认 HikariCP 连接池maximumPoolSize10但判题成功后未显式 closeEntityManager或JdbcTemplate导致连接泄漏。每个判题请求占一个连接100 个并发就爆池。解决在JudgeService实现类中所有数据库操作必须包裹在Transactional中并确保SubmissionRepository.save()后立即返回不持有 EntityManager或手动配置 HikariCPspring: datasource: hikari: maximum-pool-size: 50 connection-timeout: 3000 leak-detection-threshold: 60000 # 60秒未归还即告警4.3 现象Python 题目判题通过但 Java 题目全部COMPILATION_ERROR错误信息是error: invalid flag: -J-Xmx128m原因ProcessBuilder传参时未正确分词。错误写法.command(java, -Xmx128m -cp . Main)—— 这会把-Xmx128m -cp . Main当作一个字符串参数传给javaJVM 解析失败。解决每个 JVM 参数必须单独一个字符串.command(java, -Xmx128m, -cp, ., Main)4.4 现象学生代码中new File(/etc/passwd).exists()返回true沙箱失效原因ProcessBuilder.directory()只设置工作目录不改变根目录。学生代码仍可访问宿主机文件系统。解决必须结合chroot或unshare --user --pid --mount-proc创建 PID namespace或更简单——用 Docker 运行判题容器见 5.2。若坚持无容器方案则在SandboxExecutor中重写SecurityManagerJDK 17 前或使用jail工具挂载只读 rootfs。4.5 现象高并发下Files.createTempDirectory()报java.nio.file.FileSystemException: No space left on device原因Linux/tmp默认在内存盘tmpfs大小仅 1GB1000 个学生同时编译每个生成.class文件约 2KB瞬间占满。解决不使用系统/tmp自建判题临时目录并定期清理Path judgeTemp Paths.get(/var/judge/tmp); Files.createDirectories(judgeTemp); // 启动时清理旧目录保留 1 小时内创建的 Files.walk(judgeTemp) .filter(Files::isDirectory) .filter(p - p.toString().contains(judge-)) .filter(p - System.currentTimeMillis() - p.toFile().lastModified() 3600_000) .forEach(p - { try { FileUtils.deleteDirectory(p.toFile()); } catch (IOException e) {} });5. 进阶实战用 Docker Compose 编排判题集群实现“一题一容器”与自动扩缩容5.1 为什么必须容器化——不是为了炫技是解决“多语言共存”与“环境污染”的终极方案Java、Python、C 题目需要完全不同的运行时环境Java 要 JDK 17Python 要 3.11 numpyC 要 g 12。若全装在同一台服务器版本冲突、库污染、权限混乱是必然。Docker 的镜像分层机制让每个语言对应一个精简镜像互不干扰。更重要的是docker run --rm --memory128m --cpus0.5 --pids-limit32这条命令天然集成了前面讲的所有 cgroups 限制无需手动配置/sys/fs/cgroup。我们为 Java 判题构建专用镜像judge-java:17# Dockerfile.java FROM openjdk:17-jre-slim WORKDIR /app COPY judge-runner.jar /app/ ENTRYPOINT [java, -Xmx128m, -Xms32m, -jar, judge-runner.jar]judge-runner.jar是一个极简 Spring Boot 应用只暴露/api/execute接口接收 JSON 提交返回 JSON 结果无数据库、无 Session、无前端资源——纯粹的判题函数。5.2 Docker Compose 编排用deploy.resources实现硬性资源隔离# docker-compose.yml version: 3.8 services: api-server: image: training-system:latest ports: [8080:8080] environment: - SPRING_PROFILES_ACTIVEprod - JUDGE_URLhttp://judge-java:8080/api/execute depends_on: - judge-java judge-java: image: judge-java:17 deploy: resources: limits: cpus: 0.5 memory: 128M pids: 32 networks: - judge-net judge-python: image: judge-python:3.11 deploy: resources: limits: cpus: 0.5 memory: 256M # Python 内存开销更大 pids: 32 networks: - judge-net networks: judge-net: driver: bridge关键点deploy.resources.limits是 Docker Swarm 模式下的硬限制即使在单机docker-compose up下也生效需 Docker Engine ≥ 20.10judge-java和judge-python在同一网络judge-netAPI 服务可通过服务名直连无需暴露端口到宿主机pids: 32比ulimit -u 32更彻底直接限制该容器内所有进程总数。5.3 自动扩缩容用 Prometheus Grafana 自定义脚本实现“按需启停判题容器”当judge-java的 CPU 使用率持续 2 分钟 80%说明单实例扛不住需启动第二个# scale-judge.sh CPU_USAGE$(curl -s http://localhost:9090/api/v1/query?query100*avg by(instance)(rate(container_cpu_usage_seconds_total{container_label_com_docker_compose_service~judge-java}[2m])) | jq -r .data.result[0].value[1]) if (( $(echo $CPU_USAGE 80 | bc -l) )); then docker-compose up -d --scale judge-java2 fi提示container_cpu_usage_seconds_total是 cAdvisor 暴露的指标需在docker-compose.yml中添加 cAdvisor 服务。这不是 Kubernetes但用脚本Prometheus一样能做出轻量级弹性判题集群。6. 我的私藏技巧用EventListener监听ContextRefreshedEvent实现“热加载新题目”不重启、不丢数据很多团队每次加一道新题就得git pull mvn clean package systemctl restart training-app学生正在答题服务中断 30 秒。其实 Spring Boot 早留了后门EventListener可监听上下文事件。我们把题目元数据存在 MySQL但加载到内存用ConcurrentHashMap缓存当 DB 有变更时自动刷新缓存Component public class ProblemCacheManager { private final MapLong, Problem cache new ConcurrentHashMap(); private final ProblemRepository repo; public ProblemCacheManager(ProblemRepository repo) { this.repo repo; loadAll(); // 启动时加载 } EventListener public void handleContextRefresh(ContextRefreshedEvent event) { // Spring Boot 启动完成时触发此时 DataSource 已就绪 loadAll(); } EventListener public void handleCustomProblemUpdate(ProblemUpdatedEvent event) { // 自定义事件当管理员在后台点击“更新题目”时发布 cache.put(event.getProblem().getId(), event.getProblem()); } private void loadAll() { repo.findAll().forEach(p - cache.put(p.getId(), p)); log.info(Loaded {} problems into cache, cache.size()); } public Problem get(Long id) { return cache.get(id); } } // 管理员更新题目时 Service public class ProblemAdminService { Transactional public void updateProblem(Problem problem) { repo.save(problem); // 发布自定义事件触发缓存更新 applicationContext.publishEvent(new ProblemUpdatedEvent(problem)); } }这样加题、改题、删题全部在数据库操作应用无感知。缓存自动更新学生下一秒提交就能看到新题。这才是真正面向运维的设计——不是“重启大法好”而是“让系统自己学会呼吸”。我带过的某高校实验中心项目就是靠这套机制把每周一次的系统维护窗口从 2 小时压缩到 5 分钟只做数据库备份。后来他们甚至把ProblemUpdatedEvent改造成 WebSocket 推送教师后台改完题学生浏览器右上角立刻弹出“新题已上线”。技术没有高下只有是否贴着真实场景的脉搏跳动。希望帮到你。本文还有配套的精品资源点击获取