【面经合集】当 deepseek 遇上小红书的面试｜Java后端｜01

🌟【友情提示】本篇面经来自粉丝投稿+智能润色，点击进入 -> 🔗互联网面经大全 围观25届校招修罗场！！每个技术细节都经过脱敏处理，请勿对号入座~ 🌈 面试官：
听说你之前做过实习项目，能聊聊你在项目中处理并发问题的经验吗？比如什么情况下会加行锁？

💬小基：

当时做电商库存系统时遇到过超卖问题。其实加行锁要看场景：

• 低并发直接用synchronized简单粗暴，性能比ReentrantLock还好（毕竟JVM底层有自旋优化）
• 高并发用ReentrantLock手动控制，比如设置超时时间避免死锁
• 秒杀场景反而用乐观锁+版本号，配合Redis预减库存更合适

🌈 面试官：

刚才提到乐观锁，能说说MVCC和它的关系吗？

💬小基：

MVCC就像给数据库加了"时光机"！比如咱们查订单时：

1. 每个事务都有专属快照（类似手机截屏）
2. 更新时检查版本号（像文件修改时间戳）
3. 如果发现别人改过就重试（类似Git冲突解决）
   小红书的帖子点赞系统就用这个，读多写少不怕冲突

🌈 面试官：

限流算法在工作中怎么选型？

💬小基：

这要看业务脾气：

🌈 面试官：

Redis持久化怎么保证数据安全？

💬小基：

要像存钱一样分两个账户：

• RDB（定期存折）：整点快照，恢复快但可能丢几分钟数据
• AOF（流水账）：每笔操作都记账，最多丢1秒数据
  小红书把两者都打开，appendfsync everysec平衡性能与安全

🌈 面试官：

遇到过频繁Full GC吗？怎么排查的？

💬小基：

有次大促完服务卡爆，用GC日志分析发现：

1. 内存泄漏：错误缓存策略导致对象堆积（用MAT找到真凶）
2. 元空间不足：动态生成类太多
3. 大对象：有个1MB的JSON反复序列化
   最后-Xmx调大+改用堆外缓存搞定

🌈 面试官：

Spring用哪些设计模式让你眼前一亮？

💬小基：

像乐高积木一样巧妙：

• 代理模式：AOP切面动态增强
• 单例模式：Bean默认作用域省资源
• 模板方法：JdbcTemplate消除重复代码
• 观察者：事件监听机制超解耦
  看源码就像看设计模式教科书

🌈 面试官：

手写个LRU缓存吧？

💬小基：

class LRUCache:
    def __init__(self, capacity: int):
        self.cache = OrderedDict()  # 新来的放右边
        self.cap = capacity

    def get(self, key: int) -> int:
        if key not in self.cache:
            return -1
        self.cache.move_to_end(key)  # 标记为最近使用
        return self.cache[key]

    def put(self, key: int, value: int) -> None:
        if key in self.cache:
            self.cache.move_to_end(key)
        else:
            if len(self.cache) >= self.cap:
                self.cache.popitem(last=False)  # 淘汰最左边的
        self.cache[key] = value
# 核心思路：字典快速查找 + 双向链表维护访问顺序
# 时间复杂度：O(1) 的查询和插入