Java实习面试记录

R cddddd2025-08-01 14:20

JMM 中的三大特性

可见性

多个线程访问同一变量时，一个线程修改的值，其他线程能否及时看到？

  • volatile 能保证可见性：

    volatile boolean flag = false;

    public void stopThread() {
    flag = true;
    }

    public void run() {
    while (!flag) {
    // do something
    }
    }

原子性

一个操作是否不可中断？

  • i++ 不是原子操作，需要使用 AtomicInteger 或 synchronized 保证原子性。

有序性

编译器/CPU 可能会指令重排 。volatile 禁止重排序，synchronized 同样具有顺序性保障。

ReentrantLock vs synchronized

对比项 synchronized ReentrantLock
可重入性 ✅ ✅
公平锁 ❌ ✅ 可选
可中断 ❌ ✅
读写锁支持 ❌ ✅ 可搭配 ReadWriteLock
性能 JDK1.6后优化较好 控制更灵活但稍复杂

场景：当需要响应中断 、超时控制 或公平锁机制 时，优先使用 ReentrantLock。

高并发线程安全计数器设计

场景：库存扣减、秒杀扣量

  • 方案：AtomicInteger 或 LongAdder（高并发推荐）配合 Redis + Lua 保证分布式原子性。
  • 如果涉及分布式系统：
    • Redis 原子扣减 + 库存回滚
    • DB乐观锁（version字段）+ 唯一索引幂等性 + 异步 MQ 补偿机制

2. Spring框架与设计模式

三级缓存解决循环依赖

三级缓存结构：

复制代码 
1. 一级缓存：singletonObjects （成品）
2. 二级缓存：earlySingletonObjects（提前暴露的半成品）
3. 三级缓存：singletonFactories（用于生成早期代理对象）

// 如果构造函数注入（如 @Autowired 构造器）发生循环依赖，无法提前暴露半成品对象，三级缓存失效。

解决方案：推荐使用字段注入或 @PostConstruct 避免构造器注入的循环依赖。

🔹 JDK动态代理 vs CGLIB

特性 JDK Proxy CGLIB
是否需要接口 ✅ ❌
代理机制 基于接口，反射生成代理类 继承目标类，字节码增强
性能 接口多时快 复杂类时略慢
Spring选择 有接口 → JDK，否则 → CGLIB

责任链模式优惠券参数校验（伪代码）

复制代码 
public interface Handler {
    void setNext(Handler handler);
    void handle(Request request);
}

public class AmountCheckHandler implements Handler {
    public void handle(Request req) {
        if (req.amount < 0) throw new IllegalArgumentException();
        next.handle(req);
    }
}

优势：

  • 将每个校验逻辑解耦
  • 动态组合校验链（更灵活）
  • 新增规则无需修改原有代码，符合开放封闭原则

3. MySQL优化与高并发设计

SQL慢查优化流程

  1. 确认慢SQL
  2. EXPLAIN查看执行计划：
    • type：最佳是 const > ref > range > ALL
    • key：是否命中索引
    • rows：预估扫描行数
    • extra：是否出现 Using filesort, Using temporary
  3. 优化手段 ：
    • 添加合适索引
    • 覆盖索引
    • 拆分大表
    • LIMIT 分页优化

分库分表后的跨分片查询

  • 手段：
    • 业务规避
    • 异步聚合（如日志、报表）
    • 中间件支持（如 ShardingSphere 分布式 SQL 解析 + 路由 + 聚合）

唯一索引 + 乐观锁幂等机制

插入前判断记录是否存在（幂等键），或插入失败即跳过。

复制代码 
INSERT INTO coupon_log(user_id, coupon_id, request_id)
VALUES (...) ON DUPLICATE KEY UPDATE ...
  • 乐观锁：基于 version 字段，失败重试
  • 悲观锁：如 SELECT ... FOR UPDATE，加锁范围大，吞吐低
对比 乐观锁 悲观锁
并发性能 高 低
死锁风险 小 存在
应用场景 读多写少 严格强一致性

4. Redis与高可用架构

为什么用 Lua 实现原子性？

  1. 所有命令作为一个事务性脚本执行
  2. 单线程模型天然避免并发冲突
  3. 与 MULTI/EXEC 不同，Lua 是"不可打断+打包执行"

Redis 脑裂问题与防范

脑裂后主写成功，主挂掉无法同步从节点 → 数据丢失。

防止写入孤立主：

复制代码 
min-slaves-to-write: 2
min-slaves-max-lag: 10

表示只有在有 ≥2 个从节点延迟 <10s 时才允许主节点写入。

布隆过滤器误判率优化

误判 = 说有但其实没有

  • 调整参数：expectedInsertions、falseProbability
  • 多哈希函数，合理内存分配
  • 将误判项记录到数据库（如灰度机制）
  • 定期重建布隆过滤器

5. 分布式系统与消息中间件

RocketMQ事务消息两阶段提交

  1. Half Message：消息先存储为"准备状态"
  2. 执行本地事务
  3. 事务回查 ：
    • 成功 → Commit
    • 失败 → Rollback
    • 超时 → Broker 定期回查生产者状态

消费端幂等性方案

  • 通过唯一 msg_id/request_id 入库前判断（Redis Set / 去重表 + 唯一索引）
  • 如果高并发瓶颈：
    • Redis 先判断，再异步入库（最终一致）
    • 可设置 TTL 或滑动窗口做清理

MQ堆积延迟排查

  1. 查看消费速率和消费端堆积量
  2. 检查消费者是否：
    • 死循环/业务异常
    • 并发度设置过低
  3. 手段：
    • 扩容消费者
    • 提升消费能力
    • 消息分区优化（或分topic）

6. 短链接系统设计

短链生成算法对比

方法 优点 缺点
Hash(MD5, SHA) 简单、可分布式 存在哈希冲突，需重试
Snowflake 唯一性强、时间有序 不适合短码（太长）
数据库自增 简单 分布式不方便
base62编码 将ID压缩为短字符串 需考虑冲突与排序性

推荐组合：Snowflake生成ID + Base62编码

短链唯一性与哈希冲突处理

  1. 哈希后检查数据库是否存在
  2. 存在则重新哈希/加盐或加冲突计数
  3. 记录 原始URL+生成短码 的映射表

QPS 10万级别缓存策略

  1. Redis 做短链跳转缓存（Key: shortCode → URL）
  2. 热点数据加入本地 Caffeine 缓存
  3. 缓存穿透 → 布隆过滤器 + 缓存空值
  4. 异步写DB，日志落盘异步归档

7. 开放性问题

单元测试发现Bug案例

在 Mini-Spring 实现 AOP 时，某个切面注入出现空指针。测试时通过 mock bean 提前暴露出代理对象未生效的问题，进而修复为通过三级缓存暴露代理后的对象。

技术选型分歧如何协调

  1. 收集团队观点 + 论证维度（性能、生态、学习成本）
  2. 快速 POC 小范围验证
  3. 从场景适配角度做最终决策，而非"好恶"
  4. 若有博弈，保留少数意见作为 Plan B，确保应变能力

深入秒杀系统项目技术细节

以下针对"优惠券秒杀系统"的核心技术点进行深度解析与场景化问答：

1. 责任链模式在参数校验中的实现

Q：责任链模式如何保证优惠券创建流程的扩展性？如果新增一个"黑名单用户校验"节点，如何最小化代码改动？

  • 答案 ：

    • 核心实现：

      1. 定义统一的校验接口，每个校验器实现该接口并持有下一个节点的引用。

      2. 校验失败时抛出异常，成功则调用链的下一个节点。

        public interface CouponValidator {
        void validate(CouponRequest request) throws ValidationException;
        }
        public class ParamValidator implements CouponValidator {
        private CouponValidator next;
        public void validate(CouponRequest request) {
        if (request.getAmount() <= 0) throw new ValidationException("金额无效");
        if (next != null) next.validate(request);
        }
        // 设置下一个校验器
        public void setNext(CouponValidator next) { this.next = next; }
        }

    • 扩展性 ：新增校验器只需实现CouponValidator接口，并通过setNext插入到责任链中。例如新增BlacklistValidator：

      复制代码 
      CouponValidator chain = new ParamValidator();
chain.setNext(new InventoryValidator());
chain.setNext(new BlacklistValidator()); // 新增节点

    • 优势：无需修改已有校验逻辑，符合开闭原则（OCP）。

2. 执行点记录与断点续发机制

Q：如何设计"执行点记录"机制来支持故障恢复？如果发放优惠券时系统宕机，重启后如何快速恢复？

  • 答案 ：

    • 数据结构设计： 在数据库中记录发放批次的关键信息：

      复制代码 
      CREATE TABLE coupon_batch (
    batch_id VARCHAR(64) PRIMARY KEY,
    total_count INT,
    sent_count INT,         -- 已发放数量
    last_user_id VARCHAR(64) -- 最后处理的用户ID
);

    • 恢复流程：

      1. 系统重启后，查询coupon_batch表获取未完成的批次。
      2. 根据last_user_id从断点处继续遍历用户列表，批量扣减库存并更新sent_count。

    • 性能优化：

      • 批量处理：每次发放100条优惠券，减少数据库写入压力。
      • 异步日志：通过RocketMQ异步记录发放进度，降低主流程延迟。

3. 幂等性保障方案

Q：如何通过"唯一索引+乐观自旋"实现RocketMQ消费端的幂等性？如果并发极高，自旋重试可能导致CPU飙升，如何优化？

  • 答案 ：

    • 实现逻辑：

      1. 消费消息前，尝试插入去重表（唯一索引为消息ID）：

        INSERT INTO msg_dedup (msg_id) VALUES ('msg_001') ON DUPLICATE KEY UPDATE msg_id=msg_id;

      2. 若插入成功，继续处理；若触发唯一索引冲突，判定为重复消息，直接丢弃。

    • 自旋优化：

      • 限制重试次数：例如最多重试3次，超过则记录日志并人工介入。
      • 退避策略：每次重试前增加等待时间（如指数退避：100ms → 200ms → 400ms）。

4. Redis ZSet在优惠券列表展示中的应用

Q：为什么选择ZSet存储用户已领取的优惠券？如果需支持按过期时间排序，如何设计Score？

  • 答案 ：
    • ZSet优势 ：
      • 天然支持按Score排序（如领取时间），查询时直接使用ZREVRANGE倒序获取。
      • 时间复杂度低：插入和范围查询均为O(log N)。
    • 过期时间排序 ：

      • 将Score设置为优惠券过期时间戳（而非领取时间），查询时按Score范围过滤：

        复制代码 
        ZADD user:coupons:1001 1672502400000 "coupon_001"  -- 2023-01-01过期
ZRANGEBYSCORE user:coupons:1001 1672502400000 +inf  -- 查询未过期优惠券

5. Redis Lua脚本与原子性校验

Q：请写出资格校验的Lua脚本伪代码，并说明为何不直接用Redis事务（MULTI/EXEC）？

  • 答案 ：

    • Lua脚本示例：

      复制代码 
      -- KEYS[1]: 库存键, KEYS[2]: 已领取用户集合, ARGV[1]: 用户ID
local stock = tonumber(redis.call('GET', KEYS[1]))
if stock <= 0 then
    return 0 -- 库存不足
end
if redis.call('SISMEMBER', KEYS[2], ARGV[1]) == 1 then
    return -1 -- 已领取
end
redis.call('DECR', KEYS[1])
redis.call('SADD', KEYS[2], ARGV[1])
return 1 -- 领取成功

    • Lua vs 事务：

      • 原子性：Lua脚本执行期间不会被其他命令打断，事务中的命令可能被其他客户端插入执行。
      • 灵活性：Lua支持复杂逻辑（如条件判断、循环），事务仅支持简单命令队列。

6. 高并发下缓存穿透与击穿应对

Q：布隆过滤器如何解决缓存穿透？如果误判率较高，如何优化？

  • 答案 ：
    • 布隆过滤器原理 ：
      • 通过多个哈希函数将元素映射到位数组，查询时若任意一位为0，则元素一定不存在。
    • 误判率优化 ：
      1. 增加哈希函数数量：降低冲突概率（但会增加计算开销）。
      2. 扩大位数组容量：减少哈希碰撞。
      3. 兜底策略 ：缓存空值（key:null）并设置短TTL，拦截重复查询。

7. RocketMQ消息堆积处理

Q：如果消费端处理速度远低于生产端，导致消息大量堆积，如何快速解决？

  • 答案 ：
    • 应急方案 ：
      1. 扩容消费者：增加消费者实例或线程池大小。
      2. 批量消费 ：调整consumeMessageBatchMaxSize参数，一次处理多条消息。
      3. 降级非核心逻辑：例如先缓存领取记录，异步持久化到数据库。
    • 根本解决 ：
      • 优化消费逻辑：避免同步阻塞操作（如远程调用），改用异步或并行处理。
      • 限流保护：通过Sentinel对消费者限流，避免雪崩。

总结：面试回答技巧

  1. 细节具体化：结合代码、数据结构和流程图说明实现（如"三级缓存解决循环依赖"）。
  2. 场景绑定：强调设计背后的业务需求（如"秒杀场景要求原子性，因此选择Lua脚本"）。
  3. 问题反思：主动提及遇到的挑战（如"初期未考虑构造器注入循环依赖，通过单元测试发现并修复"）。
  4. 性能数据：若有压测结果，可量化说明优化效果（如"引入Redis后，QPS从1k提升至10k"）。
相关推荐
杜子不疼.3 分钟前
【C++】玩转模板：进阶之路
java·开发语言·c++
夜晚中的人海12 分钟前
【C++】异常介绍
android·java·c++
Le1Yu44 分钟前
2025-9-28学习笔记
java·笔记·学习
C++chaofan1 小时前
项目中为AI添加对话记忆
java·数据结构·人工智能·redis·缓存·个人开发·caffeine
老华带你飞1 小时前
机电公司管理小程序|基于微信小程序的机电公司管理小程序设计与实现(源码+数据库+文档)
java·数据库·vue.js·spring boot·微信小程序·小程序·机电公司管理小程序
拾忆，想起1 小时前
AMQP协议深度解析：消息队列背后的通信魔法
java·开发语言·spring boot·后端·spring cloud
PH = 72 小时前
Spring Ai Alibaba开发指南
java·后端·spring
涛声依旧2 小时前
基于springBoot鲜花商城小程序
java·spring·微信小程序
尘埃不入你眼眸3 小时前
服务器安装Java与nginx与nacos
java·服务器·nginx
karry_k4 小时前
什么是Fork/Join？
java·后端
热门推荐
01GitHub 镜像站点02KGG转MP3工具|非KGM文件|解密音频03OpenSpeedy简介04UV安装并设置国内源05jdk21下载、安装（Windows、Linux、macOS）06在国行 macOS 下用 DeepSeek 补齐 Xcode 26 的 AI 能力：问题、原因与 mitmproxy 解决方案（含可用脚本与安装教程）07Linux下V2Ray安装配置指南08UV 工具安装与国内镜像源配置指南09阿里最新开源Wan2.2-Animate-14B 本地部署教程：统一双模态框架，MoE架构赋能电影级角色动画与替换10Spec-Kit 使用指南