在看这期之前，建议先看前五期：
Java 原生实现代码沙箱（OJ判题系统第1期）——设计思路、实现步骤、代码实现-CSDN博客
Java 原生实现代码沙箱之Java 程序安全控制（OJ判题系统第2期）——设计思路、实现步骤、代码实现-CSDN博客
Java 原生实现代码沙箱之代码沙箱 Docker 实现（OJ判题系统第3期）——设计思路、实现步骤、代码实现-CSDN博客
OJ判题系统第4期之判题机模块架构——设计思路、实现步骤、代码实现（工厂模式、代理模式的实践）-CSDN博客
OJ判题系统第5期之判题服务开发——设计思路、实现步骤、代码实现-CSDN博客
判题逻辑的主要指责
定义
- 判题逻辑 是具体判断用户提交的代码是否正确的核心算法或规则集。它专注于解析沙箱返回的结果，并根据预定义的标准（如测试用例、时间限制、内存限制等）判断代码的正确性。
- 这是一个低层次的模块，主要关注具体的判题细节。
主要职责
- 解析沙箱输出：从沙箱返回的结果中提取关键信息（如输出、错误信息、耗时、内存占用等）。
- 比对测试用例：将沙箱的输出与题目提供的标准答案进行比对，判断每个测试用例是否通过。
- 生成判题报告：根据比对结果生成详细的判题报告（如哪些测试用例通过了，哪些失败了，失败的原因是什么）。
- 性能评估：根据资源消耗情况（如时间、内存）评估代码的效率。
策略模式优化
什么是策略模式（Strategy Pattern）？
策略模式是一种行为型设计模式，它定义了一系列算法或策略，并将每一个算法封装起来，使它们可以互相替换，独立于使用它们的客户端。
简单理解：
- 把不同的“处理方式”封装成一个个独立的类。
- 客户端在运行时决定使用哪一种策略。
- 这样可以让程序更灵活、更易扩展、更易维护。
问题背景：判题逻辑复杂，存在多种判断方式
在你的在线判题系统中，可能会遇到以下几种情况：
情况 描述 Java 执行较慢 Java 程序启动沙箱需要额外耗时（如 10 秒），总执行时间不能只看用户代码运行时间 Python 内存限制宽松 不同语言对内存的消耗不同，判题标准也要变化 C++ 要求输出完全一致 对输出格式要求严格，必须完全匹配才算通过 时间/内存限制动态调整 根据题目难度、语言类型等自动调整阈值 ❌ 如果不用策略模式，会出现什么问题？
- 判题逻辑中会充斥大量
if...else或switch...case- 新增一个语言或规则时，要修改原有逻辑，违反开闭原则
- 各种语言规则混在一起，可读性差，容易出错
- 难以复用、难以测试、难以维护
解决方案：使用策略模式统一管理判题规则
🔧 设计思路
我们将“如何根据沙箱执行结果和语言特性来判定是否通过”的逻辑抽象为一个接口，然后为每种语言提供一个具体的实现类。
这样做的好处是：
- 每个语言的判题规则彼此隔离，互不干扰
- 可以随时新增、修改某种语言的判题规则，不影响其他逻辑
- 在运行时可以根据提交的语言类型动态选择对应的策略
总结一句话
策略模式就像给系统装上了一个“可插拔的大脑”，你可以根据不同情况（比如语言类型）自动选择最合适的判题规则，而无需改动主流程代码。
策略模式的优势总结
优势 描述 ✅ 解耦 将判题逻辑与业务流程分离 ✅ 易扩展 新增语言只需添加策略类，符合开闭原则 ✅ 易维护 每种语言的规则独立，便于阅读和调试 ✅ 动态切换 支持运行时根据条件选择不同策略 ✅ 清晰结构 每个策略职责单一，符合单一职责原则
实现步骤
定义判题策略接口，让代码更加通用化：
/*** 判题策略*/
public interface JudgeStrategy {/*** 执行判题* @param judgeContext* @return*/JudgeInfo doJudge(JudgeContext judgeContext);
}定义判题上下文对象，用于定义在策略中传递的参数（可以理解为一种 DTO）：
/*** 上下文类（Context Class）** JudgeContext 用于封装和传递在不同判题策略中需要用到的所有参数。* 它作为数据容器，确保各个判题策略能够访问到所需的信息，而不必直接依赖外部对象。*/
@Data // Lombok 注解，自动生成 getter 和 setter 方法
public class JudgeContext {/*** 沙箱执行结果信息** 包含了用户提交代码在沙箱中运行时的各项指标，如耗时、内存占用等。* 这些信息对于判断代码的正确性和性能至关重要。*/private JudgeInfo judgeInfo;/*** 测试用例输入列表** 包含了题目定义的所有测试用例的输入数据。* 在判题过程中，这些输入将被传入用户提交的代码，并与输出结果进行比对。*/private List<String> inputList;/*** 用户代码的实际输出列表** 当用户提交的代码在沙箱中运行时，根据不同的测试用例输入，会生成相应的输出结果。* 这些输出结果会被收集起来，用于后续的比对和判断。*/private List<String> outputList;/*** 题目定义的标准测试用例列表** 每个标准测试用例包含了输入和期望的输出。* 判题逻辑需要将用户的实际输出与这些期望输出进行比对，以确定是否通过该测试用例。*/private List<JudgeCase> judgeCaseList;/*** 当前题目对象** 包含了题目的所有相关信息，如题目描述、难度等级、附加说明等。* 虽然在大多数情况下，具体的判题逻辑可能不会直接使用这些信息，但它们可能会在某些特定场景下有用。*/private Question question;/*** 用户提交记录对象** 包含了用户提交的详细信息，如提交时间、编程语言、用户代码等。* 这些信息对于跟踪和记录用户的提交历史非常重要。*/private QuestionSubmit questionSubmit;
}实现默认判题策略
DefaultJudgeStrategy.java
/*** 默认判题策略实现类** 该策略用于处理通用语言（如 C++、JavaScript 等）的标准判题逻辑。* 包括：* - 判断输出数量是否匹配* - 判断每个测试用例的输出是否与预期一致* - 检查内存和时间是否超出题目限制*/
public class DefaultJudgeStrategy implements JudgeStrategy {/*** 执行判题逻辑的核心方法** @param judgeContext 判题上下文对象，包含所有需要的数据* @return 返回最终的判题结果信息（是否通过、错误类型、耗时、内存等）*/@Overridepublic JudgeInfo doJudge(JudgeContext judgeContext) {从上下文中提取关键数据
// 从上下文中获取沙箱返回的执行信息（如时间、内存）JudgeInfo judgeInfo = judgeContext.getJudgeInfo();Long memory = judgeInfo.getMemory(); // 用户程序使用的内存大小（单位：字节）Long time = judgeInfo.getTime(); // 用户程序运行的时间（单位：毫秒）// 获取输入列表和输出列表List<String> inputList = judgeContext.getInputList(); // 测试用例的输入数据List<String> outputList = judgeContext.getOutputList(); // 用户程序的实际输出结果// 获取题目信息和测试用例列表Question question = judgeContext.getQuestion(); // 当前题目对象List<JudgeCase> judgeCaseList = judgeContext.getJudgeCaseList(); // 题目定义的标准测试用例// 初始化判题结果为“接受”状态JudgeInfoMessageEnum judgeInfoMessageEnum = JudgeInfoMessageEnum.ACCEPTED;// 创建一个新的 JudgeInfo 对象用于封装最终的判题结果JudgeInfo judgeInfoResponse = new JudgeInfo();judgeInfoResponse.setMemory(memory); // 设置实际使用内存judgeInfoResponse.setTime(time); // 设置实际运行时间初步校验输出数量是否与输入一致
// 如果输出数量不等于输入数量，说明至少有一个测试用例没有正确输出if (outputList.size() != inputList.size()) {// 设置为“答案错误”judgeInfoMessageEnum = JudgeInfoMessageEnum.WRONG_ANSWER;judgeInfoResponse.setMessage(judgeInfoMessageEnum.getValue());return judgeInfoResponse; // 直接返回错误结果}举例说明：
假设题目有 3 个测试用例，但用户只输出了 2 条结果，说明至少有一个用例未通过，无需继续比对。
逐条比对输出与预期是否一致
// 遍历所有测试用例，检查每一条输出是否与期望输出相等for (int i = 0; i < judgeCaseList.size(); i++) {JudgeCase judgeCase = judgeCaseList.get(i); // 获取第 i 个标准测试用例String expectedOutput = judgeCase.getOutput(); // 期望输出String actualOutput = outputList.get(i); // 实际输出// 如果两者不一致，则判定为“答案错误”if (!expectedOutput.equals(actualOutput)) {judgeInfoMessageEnum = JudgeInfoMessageEnum.WRONG_ANSWER;judgeInfoResponse.setMessage(judgeInfoMessageEnum.getValue());return judgeInfoResponse; // 只要有一个测试用例失败，就直接返回错误}}检查是否超过题目设定的资源限制
// 从题目对象中获取判题配置（例如内存限制、时间限制）String judgeConfigStr = question.getJudgeConfig(); // JSON 字符串格式的配置JudgeConfig judgeConfig = JSONUtil.toBean(judgeConfigStr, JudgeConfig.class);// 获取题目要求的最大内存和最大运行时间Long needMemoryLimit = judgeConfig.getMemoryLimit(); // 内存限制（单位：MB）Long needTimeLimit = judgeConfig.getTimeLimit(); // 时间限制（单位：毫秒）// 将 MB 转换为字节进行比较（注意单位一致性）if (memory > needMemoryLimit * 1024L * 1024L) { // 1 MB = 1024 KB = 1024*1024 bytesjudgeInfoMessageEnum = JudgeInfoMessageEnum.MEMORY_LIMIT_EXCEEDED;judgeInfoResponse.setMessage(judgeInfoMessageEnum.getValue());return judgeInfoResponse;}// 检查是否超时if (time > needTimeLimit) {judgeInfoMessageEnum = JudgeInfoMessageEnum.TIME_LIMIT_EXCEEDED;judgeInfoResponse.setMessage(judgeInfoMessageEnum.getValue());return judgeInfoResponse;}全部通过，返回成功结果
// 所有条件都满足，设置最终消息为“接受”judgeInfoResponse.setMessage(judgeInfoMessageEnum.getValue());// 返回完整的判题结果return judgeInfoResponse;}
}总结一下这个类的职责：
步骤 功能 1️⃣ 提取参数 从 JudgeContext中提取所有判题所需的信息2️⃣ 输出数量校验 判断输出数量是否与输入数量一致 3️⃣ 输出内容比对 比较每个测试用例的实际输出与期望输出是否一致 4️⃣ 资源限制判断 判断是否超出内存或时间限制 5️⃣ 返回结果 构建并返回最终的判题结果
定义 JudgeManager
为什么要定义 JudgeManager
1. 集中管理判题逻辑
- 问题背景: 在没有
JudgeManager的情况下，每个地方调用判题逻辑时都需要手动判断使用哪种策略，这会导致大量的重复代码，增加维护成本。- 解决方案:
JudgeManager将所有的判题逻辑集中管理，使得外部调用者只需传递JudgeContext对象即可完成判题操作，无需关心具体的实现细节。2. 提高代码的可维护性和扩展性
- 问题背景: 如果未来需要支持更多的编程语言或引入新的判题规则，直接修改现有代码容易引发潜在的风险。
- 解决方案: 使用
JudgeManager和策略模式，可以轻松地添加新的策略类而不需要修改原有代码，符合开闭原则（对扩展开放，对修改封闭）。3. 简化客户端调用
- 问题背景: 客户端代码如果直接与各种判题策略打交道，会显得非常复杂且不易于理解。
- 解决方案:
JudgeManager提供了一个统一的接口，客户端只需要知道如何构建JudgeContext并调用doJudge方法，极大地简化了调用过程。4. 增强系统的灵活性
- 问题背景: 不同编程语言可能有不同的运行环境要求（如启动时间、内存限制等），这些差异需要在判题时特别处理。
- 解决方案:
JudgeManager可以根据编程语言动态选择最适合的判题策略，确保每种语言都能得到公平准确的评判。
/*** 判题管理器** JudgeManager 是整个判题系统的核心组件之一，负责根据用户提交的编程语言，* 动态选择并调用相应的判题策略（JudgeStrategy）。这有助于将复杂的判题逻辑* 进行模块化封装，便于后续维护和扩展。*/
@Service // Spring 注解，标识该类为一个服务层组件
public class JudgeManager {/*** 执行判题操作** 该方法接收一个包含所有必要信息的上下文对象（JudgeContext），* 根据用户提交的编程语言动态选择合适的判题策略，并返回最终的判题结果。** @param judgeContext 包含了题目、用户提交、沙箱执行结果等信息的对象* @return 判题结果信息（如是否通过、错误类型、耗时、内存等）*/public JudgeInfo doJudge(JudgeContext judgeContext) {// 从上下文中获取用户提交的信息QuestionSubmit questionSubmit = judgeContext.getQuestionSubmit();// 获取用户提交的编程语言类型String language = questionSubmit.getLanguage();// 初始化默认的判题策略JudgeStrategy judgeStrategy = new DefaultJudgeStrategy();// 根据编程语言选择不同的判题策略if ("java".equals(language)) {judgeStrategy = new JavaLanguageJudgeStrategy(); // Java 特有的判题策略}// 调用选定的策略执行判题操作return judgeStrategy.doJudge(judgeContext);}
}执行判题：
整体流程图
用户点击提交按钮
│
├─→ 校验编程语言是否合法
│
├─→ 校验题目是否存在
│
├─→ 构造提交记录对象（包含代码、语言、用户ID、题目ID）
│
├─→ 插入数据库，设置初始状态为 WAITING
│
├─→ 获取提交记录 ID
│
├─→ 异步调用 judgeService.doJudge(questionSubmitId)
│
└─→ 返回 questionSubmitId 给前端具体实现
方法签名与基本说明
/*** 提交题目** 用户提交代码进行判题的核心方法。* 主要流程包括：* 1. 参数校验（语言合法性、题目是否存在）* 2. 构建提交记录对象并保存到数据库* 3. 异步调用判题服务进行判题** @param questionSubmitAddRequest 提交请求参数封装类* @param loginUser 当前登录用户信息* @return 返回提交记录的 ID，用于后续查询判题结果*/
@Override
public long doQuestionSubmit(QuestionSubmitAddRequest questionSubmitAddRequest, User loginUser) {获取并校验编程语言是否合法
// 从请求中获取用户提交的编程语言String language = questionSubmitAddRequest.getLanguage();// 使用枚举工具类判断该语言是否在支持的语言列表中QuestionSubmitLanguageEnum languageEnum = QuestionSubmitLanguageEnum.getEnumByValue(language);// 如果语言不合法，抛出异常if (languageEnum == null) {throw new BusinessException(ErrorCode.PARAMS_ERROR, "编程语言错误");}为什么需要这一步？
- 防止用户输入非法或不受支持的编程语言（如 Python3、PHP 等非白名单语言）。
- 增强系统安全性，避免后续处理出现不可控问题。
检查题目是否存在
// 获取题目 IDlong questionId = questionSubmitAddRequest.getQuestionId();// 查询题目实体是否存在Question question = questionService.getById(questionId);if (question == null) {throw new BusinessException(ErrorCode.NOT_FOUND_ERROR);}为什么需要这一步？
- 确保用户提交的是一个真实存在的题目，防止攻击者通过伪造 ID 操作不存在的数据。
- 同时也为后续判题逻辑提供必要的题目信息（如测试用例、限制条件等）。
构造提交记录对象，并设置默认状态
// 获取当前用户的 IDlong userId = loginUser.getId();// 创建一个新的提交记录对象QuestionSubmit questionSubmit = new QuestionSubmit();questionSubmit.setUserId(userId); // 设置用户 IDquestionSubmit.setQuestionId(questionId); // 设置题目 IDquestionSubmit.setCode(questionSubmitAddRequest.getCode()); // 设置用户提交的代码内容questionSubmit.setLanguage(language); // 设置编程语言// 设置初始状态为“等待中”questionSubmit.setStatus(QuestionSubmitStatusEnum.WAITING.getValue());// 初始 judgeInfo 字段为空 JSON，表示还未判题questionSubmit.setJudgeInfo("{}");为什么设置初始状态？
- 表示当前提交正在排队等待判题，前端或其他模块可以根据此状态判断是否已开始执行。
- 判题完成后会异步更新状态为“成功”或“失败”。
将提交记录保存到数据库
// 尝试将提交记录插入数据库boolean save = this.save(questionSubmit);if (!save){throw new BusinessException(ErrorCode.SYSTEM_ERROR, "数据插入失败");}为什么需要持久化？
- 记录每一次提交的历史，便于后续查询、统计、审计。
- 即使系统重启或发生异常，也可以根据数据库恢复状态。
获取提交记录 ID 并异步触发判题服务
// 获取刚刚插入的提交记录 IDLong questionSubmitId = questionSubmit.getId();// 异步执行判题逻辑，避免阻塞主线程CompletableFuture.runAsync(() -> {judgeService.doJudge(questionSubmitId);});为什么要异步执行？
- 判题是一个耗时操作（可能涉及启动沙箱、运行代码、比对输出等），如果同步执行会影响接口响应速度。
- 使用
CompletableFuture实现异步处理，提高系统吞吐量和用户体验。
返回提交记录 ID
// 返回提交记录 ID，供前端或其他服务使用return questionSubmitId;
}这个 ID 的用途是什么？
- 前端可以通过这个 ID 轮询或 WebSocket 监听判题结果。
- 判题服务也依赖这个 ID 来查找对应的提交记录和题目信息。
】使用Feign实现接口调用（八）)
