OJ判题系统第6期之判题逻辑开发——设计思路、实现步骤、代码实现(策略模式)
在看这期之前,建议先看前五期:
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 来查找对应的提交记录和题目信息。