25年10月阿里国际 Java开发 实习 二面

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

1. 你在 OJ 项目中使用 Docker 部署时，是如何保证容器启动顺序和服务依赖的？

回答思路：

1. 核心问题锚定：解决「依赖服务未启动完成，当前容器启动失败」的问题，核心是「控制启动顺序+健康检查」；
2. 分层拆解方案：
   • 方案1（基础）：使用 docker-compose 的 depends_on 配置启动顺序（如先启动MySQL、Redis，再启动OJ核心服务），但需补充：depends_on 仅保证启动顺序，不保证服务就绪；
   • 方案2（关键）：在应用启动脚本中增加「健康检查逻辑」（如轮询MySQL端口/执行测试SQL，直到返回成功），确保依赖服务就绪后再启动应用；
   • 方案3（进阶）：结合 docker-compose 的 healthcheck 配置，通过 test 指令检测依赖服务状态，满足条件后再启动当前容器；
3. 结合OJ场景举例：OJ项目中，判题容器依赖数据库（存储题目、提交记录）和Redis（缓存判题队列），先通过 depends_on 指定顺序，再在判题服务启动脚本中轮询Redis PING 命令和MySQL连接，就绪后才加载判题核心逻辑。 核心结论：核心是「启动顺序控制+服务就绪检测」，通过 docker-compose 保证启动顺序，通过健康检查/脚本轮询保证依赖服务真正可用，避免容器启动但服务不可用的问题。

2. RabbitMQ 中如何保证消费端不出现消息重复消费的问题？

回答思路：

1. 核心原因先铺垫：重复消费的本质是「消费端确认消息成功前宕机，MQ重发消息」，核心解决思路是「消费逻辑幂等性」；
2. 核心方案拆解：
   • 方案1（最通用）：为每条消息生成唯一标识（如业务ID+消息ID），消费端先查询该标识是否已处理，未处理则执行消费逻辑，处理完成后记录标识（如写入数据库/Redis）；
   • 方案2（数据库层面）：利用数据库唯一索引/主键约束，消费逻辑中插入数据时，重复插入会触发约束报错，视为消费成功；
   • 方案3（MQ层面优化）：合理设置消费确认机制（如手动ACK，仅在消费逻辑完全执行成功后ACK），减少不必要的重发；
3. 结合场景举例：订单消息消费时，以订单ID为唯一标识，消费前查Redis是否有该订单ID的消费记录，无则执行扣库存、生成订单逻辑，执行完成后将订单ID写入Redis（设置过期时间），重复消费时直接返回成功。 核心结论：核心是保证消费逻辑的「幂等性」，通过唯一标识+状态记录，让重复消费的执行结果与首次一致，从根本上解决重复消费的业务影响。

3. 项目中权限控制模块，你是如何设计数据权限和功能权限的隔离逻辑的？

回答思路：

1. 先明确两类权限定义：
   • 功能权限：控制「能做什么」（如菜单访问、按钮点击、接口调用，如订单查询、新增用户）；
   • 数据权限：控制「能看到什么数据」（如普通销售只能看自己的订单，经理能看全部门的订单）；
2. 隔离设计核心逻辑：
   • 功能权限：基于RBAC模型，用户→角色→权限（接口/菜单/按钮），通过注解（如@PreAuthorize）拦截接口，校验是否有对应功能权限；
   • 数据权限：独立于功能权限，在SQL层面动态拼接数据过滤条件（如WHERE user_id = #{currentUserId} 或 dept_id IN #{deptIds}），通过MyBatis拦截器/自定义注解实现；
   • 隔离点：功能权限校验在接口入口（拦截器/过滤器），数据权限校验在数据查询阶段（SQL拼接），功能权限不通过直接返回，数据权限不影响功能访问但过滤数据；
3. 举例落地：后台管理系统中，用户有「订单查询」功能权限后，再通过数据权限注解@DataPermission，根据用户角色（销售/经理）动态拼接订单表的user_id/dept_id过滤条件，实现功能和数据权限的隔离控制。 核心结论：功能权限控制「是否能访问接口」，数据权限控制「接口返回哪些数据」，通过「入口拦截（功能）+ SQL过滤（数据）」实现隔离，且数据权限不依赖功能权限（有功能权限才会触发数据权限过滤）。

4. TransmittableThreadLocal 相比 InheritableThreadLocal，核心解决了什么问题？

回答思路：

1. 先铺垫基础：
   • InheritableThreadLocal：解决「父线程向子线程传递ThreadLocal数据」的问题，但仅在子线程创建时传递一次，子线程创建后父线程数据修改，子线程无法感知；
   • 核心痛点：线程池场景下，子线程是复用的，InheritableThreadLocal无法传递后续父线程更新的数据，且会导致数据串用；
2. TransmittableThreadLocal（TTL）核心解决点：
   • 解决「线程池复用线程时，ThreadLocal数据无法正确传递」的问题；
   • 底层逻辑：通过修饰线程池（TtlExecutors），在任务提交/执行时，捕获当前线程的TTL数据，传递到复用的线程中，执行完成后清除，保证数据隔离和正确传递；
3. 场景举例：分布式追踪（TraceId）、用户上下文（UserId）在线程池异步任务中传递，InheritableThreadLocal会导致TraceId串用，TTL可保证每个异步任务获取到正确的上下文数据。 核心结论：核心解决了「线程池复用线程时，InheritableThreadLocal数据无法动态传递且易串用」的问题，实现了线程池场景下ThreadLocal数据的正确传递和隔离。

5. MyBatis 一级缓存的作用域是哪里？默认是否开启？

回答思路：

1. 核心答案优先：
   • 作用域：SqlSession（每个SqlSession独享一级缓存，不同SqlSession之间不共享）；
   • 默认状态：默认开启，且无法手动关闭（只能通过配置清除缓存）；
2. 补充逻辑：
   • 缓存触发：同一SqlSession中，多次执行相同的SQL（参数也相同），第一次查询后结果存入一级缓存，后续直接从缓存获取，无需查数据库；
   • 缓存失效场景：执行增删改操作、调用SqlSession.clearCache()、关闭SqlSession，缓存会被清空；
3. 举例理解：同一个SqlSession中，两次执行select * from user where id=1，第一次查库，第二次从一级缓存取；新开一个SqlSession执行相同SQL，仍会查库。 核心结论：MyBatis一级缓存作用域是SqlSession，默认开启，核心是减少同一SqlSession内重复查询的数据库交互，提升性能。

6. Spring 中 @Transactional 注解的 propagation 属性，最常用的传播行为是什么？

回答思路：

1. 核心答案优先：最常用的是 Propagation.REQUIRED（默认值，无需手动指定）；
2. 解释核心逻辑：
   • 含义：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务；
   • 为何常用：符合绝大多数业务场景的事务需求（如订单创建→扣库存→记录日志，所有操作在同一个事务中，要么全成要么全败）；
3. 补充其他常用传播行为（对比）：