25年11月合创经纬（深圳） Java开发 实习 一面

#JAVA##JAVA面经##JAVA内推#

1. 请做一个自我介绍

思路

• 核心逻辑：基本信息（学校/工作年限）→ 核心技术栈（Java、SpringBoot、RabbitMQ、JWT、Redis等）→ 项目亮点（贴合面试提问的RabbitMQ、JWT、定时任务）→ 求职意向（匹配岗位需求）。
• 重点：突出与面试高频提问技术相关的项目经验，简洁聚焦，控制1-2分钟。

回答示例

面试官您好，我是XXX，XX大学计算机专业在读/有X年Java开发经验。熟练掌握Java基础、SpringBoot、MySQL、RabbitMQ、Redis等核心技术，熟悉JWT认证、分布式锁、SQL优化、定时任务等落地场景。曾参与竞赛管理类项目开发，负责用户认证、消息异步处理、数据同步等核心模块，解决过RabbitMQ消息丢失、Redis与MySQL数据一致性等问题，具备独立设计和落地业务功能的能力。我希望能加入团队，将技术积累应用到实际开发中，同时持续学习提升。

2. 详细介绍你的项目

思路

• 逻辑：项目背景→核心目标→技术栈→负责模块（重点提RabbitMQ、JWT、定时任务、Redis/MySQL）→技术难点与解决方案（贴合后续提问方向）→项目成果。
• 重点：提前预埋后续提问的技术点（如RabbitMQ消息可靠性、JWT认证、数据一致性），为后续回答铺垫。

回答示例

我参与的是竞赛管理系统开发，核心目标是实现竞赛报名、评审、结果公示全流程管理，技术栈为SpringBoot+MySQL+Redis+RabbitMQ+JWT。我主要负责三个核心模块：一是用户认证模块，基于JWT+Filter实现登录认证和权限控制；二是竞赛信息异步通知模块，通过RabbitMQ将报名成功、评审结果等消息异步推送给用户；三是数据同步模块，用定时任务实现Redis缓存与MySQL竞赛数据的同步，保证数据一致性。开发中解决了RabbitMQ消息丢失、分布式锁竞争、SQL查询慢等问题，最终系统支撑了上千人同时报名，接口响应时间优化30%以上。

3. 项目中使用RabbitMQ时，如何解决消息丢失和重复消费问题？

思路

• 消息丢失：分三个环节（生产者→MQ→消费者）逐一解决，覆盖确认机制、持久化、ACK机制。
• 重复消费：核心是消费幂等性，结合业务场景（如唯一ID、状态机、防重表）实现。
• 逻辑：先讲丢失的原因，再对应解决方案；重复消费重点讲幂等实现细节。

回答示例

一、解决消息丢失（覆盖三个核心环节）

1. 生产者端：开启Confirm确认机制，消息发送后等待MQ的确认回执，未确认则重试；同时避免使用事务模式（性能低），用异步Confirm保证消息投递到MQ；
2. MQ服务端：开启交换机、队列、消息的持久化（durable=true），即使MQ宕机，重启后消息不丢失；部署集群（主从/镜像队列），避免单点故障；
3. 消费者端：关闭自动ACK，采用手动ACK（basicAck），只有业务处理完成后才确认消息；若处理失败，触发重试（避免直接丢弃），重试多次失败则进入死信队列。

二、解决重复消费（核心是消费幂等）

项目中通过“唯一消息ID+防重表”实现：

1. 生产者发送消息时，为每条消息生成唯一ID（如UUID），存入消息属性；
2. 消费者接收消息后，先查询防重表（MySQL），若该消息ID已存在则直接返回；若不存在，执行业务逻辑，再将消息ID写入防重表（结合事务）；
3. 补充：对于无需持久化的场景（如通知），也可基于Redis的SETNX存储消息ID，过期时间设为消息有效期，减少数据库压力。

4. JWT令牌被窃取后该如何处理？了解重放攻击吗？

思路

• JWT被窃取：核心是“无法主动失效”的痛点，解决方案分短期、长期，结合黑名单、刷新token、权限控制。
• 重放攻击：定义（窃取token重复使用）+ 解决方案（时间戳+nonce随机数、token有效期、签名验证）。

回答示例

一、JWT令牌被窃取的处理方案

JWT的核心痛点是生成后无法主动失效，我从三个层面解决：

1. 短期应急：将被盗取token的用户ID加入Redis黑名单，Filter认证时先校验黑名单，命中则拒绝访问；黑名单设置与token过期时间一致的过期时间，避免内存堆积；
2. 长期优化：缩短token有效期（如30分钟），同时实现刷新token机制（refresh token，有效期7天），用户登录后返回access token和refresh token，access token过期后用refresh token获取新token，减少token被盗用的窗口期；
3. 权限兜底：即使token被盗，结合接口级权限控制（如敏感操作需二次验证），避免攻击者获取核心权限。

二、重放攻击及解决

重放攻击是攻击者窃取合法token后，重复发送请求冒充合法用户。解决方案：

1. 在JWT的payload中加入时间戳（iat）和随机nonce值（一次性随机数），服务端验证时间戳是否在有效期（如5分钟），同时校验nonce值是否已使用（Redis存储已使用nonce，过期删除）；
2. 结合HTTPS传输，防止token在传输过程中被窃取；
3. 核心接口（如修改密码、提现）增加验证码/短信验证，即使token被重放也无法执行敏感操作。

5. 为什么选择JWT+Filter实现用户登录认证，而非拦截器？有哪些考量？

思路

• 核心差异：Filter基于Servlet规范（请求进入Servlet前执行）、Interceptor基于SpringMVC（控制器方法执行前后），从执行时机、功能范围、性能、适配场景对比。
• 选择考量：认证需早拦截、