研究的基本内容

系统架构设计：构建稳定、可扩展的系统架构，支持高并发用户访问和海量数据处理。从普遍的LAMP架构改为LAMJ微服务架构。

1.自主设计判题机模块的架构，定义了代码沙箱的抽象调用接口和多种实现类（比如远程／第三方代码沙箱），并通过静态工厂模式+Spring配置化的方式实现了对多种代码沙箱的灵活调用。

2.使用代理模式对代码沙箱接口进行能力增强，统一实现了对代码沙箱调用前后的日志记录，减少重复代码。

3.由于判题逻辑复杂、且不同题目的判题算法可能不同（比如Java题目额外增加空间限制），选用策略模式代替 if else 独立封装了不同语言的判题算法，提高系统的可维护性。

4.通过编写Java 脚本自测代码沙箱，模拟了多种程序异常情况并针对性解决，如使用黑白名单+字典树的方式实现了对敏感操作的限制。

5.为保证沙箱宿主机的稳定性，选用Docker隔离用户代码，使用DockerJava库创建容器隔离执行代码，并通过tty和Docker进行传参交互，从而实现了更安全的代码沙箱。

6.使用Java安全管理器和自定义的SecurityManager对用户提交的代码进行权限控制，比如关闭写文件、执行文件权限，进一步提升了代码沙箱的安全性。

国内外研究现状

调研市场大部分OJ（online judge）系统，主要问题分布在以下几点：

1. 太过于老旧，与主流技术脱节，不好维护和拓展，效率低下；

2. 功能完善的系统（例如LeetCode，Codeforces）不开源，应用困难。

3. 模块化做的不足，系统之间缺乏解耦。例如，大部分oj系统都将判题系统作为一个模块，但是将代码沙箱独立出来是更好的选择。

4. 用户交互界面过时，不符合大众审美。

5. 功能欠缺，对用户自学需求难以满足。缺乏完善的搜索支持。

历史背景

编程教育需求，传统检测方式的弊端，OJ 系统产生的历史必然性。

技术发展必然变革旧有的学习方式，传统的已纸面方式的学习检验已然过时。

经验表面，纸面考试的形式并不能很好的促进学生对于计算机应用方法有更深入的把控。计算机程序并非只有一个答案。

老师检查程序的效率过低。