Java实习模拟面试实录微服务OJ系统架构、JWT安全机制与Redis排行榜深度解析实在智能-Java开发-实习一面关键词Java实习面试 | 微服务OJ系统 | Docker沙箱安全 | JWT令牌管理 | Redis ZSet排行榜 | 线程池原理引言在准备Java后端开发实习岗位的过程中模拟面试是查漏补缺、提升表达能力的重要环节。本文基于一次真实的“实在智能”公司Java开发实习生一面的完整问答记录以结构化对话 专业解析的形式还原面试官连环追问的逻辑并结合专业知识给出高质量回答帮助读者深入理解微服务、安全控制、缓存设计等核心知识点。一、自我介绍面试官提问请先做个简单的自我介绍吧。回答您好我是XX大学计算机专业的大三学生目前主攻Java后端开发方向。在校期间参与过多个项目实践其中最核心的是一个基于Spring Cloud Alibaba的微服务在线判题系统OJ。该项目支持多语言代码提交、Docker沙箱隔离执行、JWT鉴权、Redis实时排行榜等功能。我主要负责后端服务模块的设计与实现包括判题服务、用户服务和排行榜模块。希望通过这次实习机会进一步提升工程能力和对高并发、分布式系统的理解。二、项目深挖微服务OJ系统Q1介绍一下你的项目微服务OJ系统回答我们的OJ系统采用微服务架构整体划分为以下几个核心服务用户服务user-service处理注册、登录、JWT生成题目服务problem-service管理题目信息、测试用例判题服务judge-service核心模块接收代码、调用Docker沙箱执行、比对输出排行榜服务ranking-service基于Redis ZSet实现实时排名网关服务gateway统一入口路由与限流。整个系统通过Nacos做服务注册发现Sentinel做熔断降级使用RabbitMQ解耦判题任务保证高可用性。Q2Docker沙箱是每次提交代码都会创建新的吗还是会复用回答我们采用的是每次提交都创建新容器的策略。虽然启动容器有一定开销但为了强隔离性和安全性必须确保每个用户的代码运行在完全独立的环境中避免状态污染或恶意代码影响其他任务。不过我们也做了优化使用轻量级基础镜像如Alpine预拉取常用语言镜像Java/Python/C设置容器超时自动销毁5秒执行上限。这样在保证安全的前提下尽量降低资源消耗。Q3判题逻辑是怎么样的最后样例输出是直接读取Docker沙箱的输出吗回答是的。判题流程如下用户提交完整代码ACM模式非力扣模板判题服务将代码、输入样例、时间/内存限制打包启动对应语言的Docker容器挂载代码文件容器内执行编译 → 运行 → 重定向标准输出到指定文件容器退出后宿主机读取输出文件内容与预期输出逐行比对忽略末尾空格/换行差异返回判题结果AC/WA/TLE/MLE等。注意Docker内部不包含业务逻辑只负责“黑盒执行”所有判题规则都在宿主机服务中处理。Q4用户提交的代码里如果有恶意代码怎么办回答这是安全设计的重点。我们从多个层面防御资源限制通过Docker的--memory、--cpus、ulimit限制内存、CPU、文件句柄等网络隔离容器默认无网络--network none禁止外联文件系统只读除代码挂载目录外其余路径只读禁用危险系统调用使用seccomp或AppArmor过滤syscall如fork,execve等超时强制终止超过5秒自动kill进程日志审计记录所有提交行为便于事后追溯。即使用户写while(true)或尝试读取/etc/passwd也会被系统拦截或超时终止。Q5项目支持多语言编程是如何实现的回答目前我们采用的是ACM竞赛模式即用户提交完整可运行程序而非函数片段。因此每种语言都有对应的执行脚本模板例如Java编译为.class用java Main运行Python直接python3 code.pyCg -o a.out code.cpp ./a.out。这些脚本预置在Docker镜像中。当用户选择语言后判题服务会调用对应镜像并传入用户代码。没有前端模板填充因为不是力扣那种“补全函数”模式。✅ 补充说明若未来支持力扣模式可在前端提供函数模板后端拼接成完整程序再执行。三、JWT安全机制深度探讨Q6介绍一下JWT回答JWTJSON Web Token是一种无状态的认证令牌由三部分组成Header算法如HS256和类型JWTPayloadClaims用户信息如user_id、role、过期时间exp等Signature用密钥对前两部分签名防止篡改。优点服务端无需存储session适合分布式系统可跨域传递自包含用户信息减少DB查询。缺点无法主动失效除非引入黑名单payload明文需避免敏感信息。Q7客户端A和B同时登录同一用户B修改了用户信息两个JWT会冲突吗如何解决回答这是一个经典的令牌同步问题。传统JWT确实存在这个问题——因为它是无状态的服务端无法感知用户信息是否变更。解决方案可以在JWT的claims中加入一个“版本号”字段比如user_version。每次用户关键信息如密码、权限变更时更新数据库中的version字段。验证JWT时不仅校验签名和过期时间还要比对当前数据库中的user_version是否与token中一致。如果不一致说明用户信息已变更要求重新登录或刷新token。 面试官提示正是这个思路通过claims携带校验标记实现逻辑上的“令牌失效”。四、浏览器Cookie机制澄清Q8浏览器中的Cookie是在什么时候触发携带、保存的回答修正版Cookie的保存和携带是浏览器自动完成的无需手动写JS代码与localStorage不同。保存当服务器响应头包含Set-Cookie: tokenxxx; Path/; HttpOnly时浏览器自动存储携带后续向相同域名Path的请求浏览器会自动在请求头加上Cookie: tokenxxx。❗ 我最初误答成localStorage这是错误的。LocalStorage需要手动setItem/getItem而Cookie是HTTP协议层的自动行为。Q9同一浏览器中不同网站的Cookie会冲突吗回答不会。Cookie的隔离基于域名Domain和路径Path。a.com的 Cookie 不会被b.com访问即使是子域如api.a.com和www.a.com也需显式设置Domain.a.com才能共享浏览器通过同源策略严格隔离不同站点的Cookie。这是Web安全的基础机制之一。五、Redis排行榜设计详解Q10说说Redis一些常见命令回答常用命令包括字符串SET/GET/INCR哈希HSET/HGET/HGETALL列表LPUSH/RPOP/LRANGE集合SADD/SMEMBERS/SINTER有序集合ZSetZADD/ZRANK/ZREVRANGE/ZSCOREQ11ZSet的原理是什么回答Redis的ZSet底层由两种结构实现ziplist元素少、成员短时用压缩列表skiplist hash table元素多时用跳跃表skiplist维护排序哈希表维护成员到分数的映射实现O(logN)的插入、删除、排名查询。跳跃表是一种概率型数据结构通过多层索引加速查找类似“链表的二分查找”。Q12为什么排行榜不用List/Set/Hash而用ZSet回答List无法按分数排序只能按插入顺序Set无序不支持排名Hash可存分数但无法高效获取Top N需全表扫描ZSet天然支持按分数排序 快速范围查询 实时排名完美匹配排行榜场景。Q13日排行榜、周排行榜如何实现回答我们采用多Key策略日榜ranking:day:20260127周榜ranking:week:2026-W04总榜ranking:total每天凌晨通过定时任务原计划用XXL-JOB但因Bug未上线将当日得分聚合到周榜、总榜。也可用Redis的EXPIRE自动过期日榜数据。⚠️ 当前因任务模块出Bug暂时由手动脚本处理后续会修复。Q14排行榜数据有持久化到数据库吗回答核心数据会持久化。Redis作为缓存层提供高性能读写但为防数据丢失用户每次得分变更时异步写入MySQL的user_score_log表每日凌晨将Redis中的最终排名快照存入daily_ranking表系统重启时可从DB重建Redis ZSet。做到缓存持久化双保险。六、微服务架构与多线程Q15项目整体划分为了哪些服务回答如前所述共5个微服务user-service用户problem-service题目judge-service判题ranking-service排行榜gateway网关通过Feign调用Nacos注册中心配置中心统一管理。Q16项目用到多线程了吗回答业务逻辑中未显式使用多线程但在某些工具类中了解过TransmittableThreadLocalTTL。TTL用于解决线程池中ThreadLocal变量传递问题比如在异步任务中传递用户上下文如traceId、userId。普通ThreadLocal在线程复用时会丢失上下文而TTL通过装饰Runnable/Callable实现父子线程间的数据透传。Q17了解线程池吗说一下核心参数回答ThreadPoolExecutor的核心参数有corePoolSize核心线程数即使空闲也不会被回收maximumPoolSize最大线程数keepAliveTime非核心线程空闲超时时间workQueue阻塞队列如ArrayBlockingQueue、LinkedBlockingQueuethreadFactory线程工厂handler拒绝策略如AbortPolicy、CallerRunsPolicy。Q18核心线程和非核心线程的区别回答核心线程常驻线程即使空闲也不销毁除非allowCoreThreadTimeOuttrue非核心线程临时线程空闲超过keepAliveTime会被回收。Q19非核心线程是在阻塞队列满之后才创建的吗回答是的。线程池的执行策略是若当前线程数 corePoolSize → 创建核心线程否则尝试将任务放入workQueue若队列已满且当前线程数 maximumPoolSize → 创建非核心线程若线程数已达上限 → 触发拒绝策略。所以非核心线程只在队列满之后才会创建。结语这次模拟面试覆盖了微服务架构、容器安全、认证授权、缓存设计、并发编程等多个维度既有广度也有深度。尤其在JWT令牌同步、Redis ZSet选型、线程池机制等细节上暴露出知识盲区也明确了后续学习方向。建议实习面试不仅考编码更看重系统设计思维与问题解决逻辑。平时多思考“为什么用这个技术有没有更好的方案”才能在连环追问中游刃有余。欢迎关注我的CSDN主页后续将持续更新Java后端面试实战系列如有疑问欢迎评论区交流