美团 Agent开发 一面

群里小伙伴投稿的时候 我也懵了一下 ,纯八股

1. 自我介绍,着重讲讲你的履历

2. 讲讲 HashMap 和 Hashtable 的区别，为什么现在工程里几乎不用 Hashtable

Hashtable 的方法基本都是同步的，粒度重，性能差，而且不支持高并发场景下的细粒度优化。HashMap 本身不是线程安全的，但它更轻量，配合外部同步、ConcurrentHashMap 或更合理的并发设计更适合现代工程。Hashtable 还有一个问题是历史包袱重，API 设计也比较老旧，所以现在一般不作为首选。

3. 设计一个线程安全的“批量删除 HashMap 中符合条件的 value”功能

不能直接在遍历时删原 Map，否则很容易触发并发修改异常。比较稳的方式是先遍历收集待删 key，再统一删除；如果是多线程场景，要么外部加锁，要么用并发容器配合分段处理。对于高并发写少读多的场景，通常更建议把删除动作封装成原子操作，避免业务层自己乱改集合状态。

public void removeByValue(Map<String, String> map, String target) {
    List<String> keys = new ArrayList<>();
    for (Map.Entry<String, String> entry : map.entrySet()) {
        if (Objects.equals(entry.getValue(), target)) {
            keys.add(entry.getKey());
        }
    }
    for (String key : keys) {
        map.remove(key);
    }
}

4. 讲讲 JVM 垃圾回收机制，重点说对象什么时候进入老年代

对象一般先分配在新生代，经过多次 Minor GC 仍然存活，就会晋升到老年代。大对象、长期存活对象、年龄阈值达到要求的对象都会进入老年代。真正线上出问题的往往不是“不会回收”，而是晋升过快、老年代碎片化、Full GC 频繁和停顿时间过长。回答这类问题时，最好能把对象生命周期、分代思想、回收器选择和停顿模型一起讲。

5. 说一下 HTTPS 的完整过程，为什么它比 HTTP 安全

HTTPS 本质上是在 HTTP 和传输层之间加了一层 TLS。连接建立时会进行证书校验、密钥协商和会话密钥生成，后续数据都用对称加密传输。它能解决窃听、篡改和中间人攻击问题，但前提是证书可信、握手过程正确、服务端身份可验证。HTTPS 不是“加了个 S 就安全了”，而是一套完整的信任和加密体系。

6. 讲讲消息积压怎么排查，别只说扩消费者

先看是生产快还是消费慢，再看是不是某个 key 或某个队列热点导致局部堆积。然后拆消费耗时，判断卡在数据库、RPC、锁、重试还是序列化。再看重试次数、死信队列、消费者实例分布和线程池状态。很多积压不是 MQ 本身问题，而是消费逻辑里有同步慢操作或者异常重试风暴。

7. 说一下 MySQL 索引最左前缀原则，什么情况下看起来用了联合索引，实际还是全表扫

联合索引能否命中，取决于查询条件是否连续匹配左侧列。中间断掉、范围查询过早出现、函数包裹、类型隐式转换、排序条件不匹配，都可能导致后面的列失效。即便 key 看起来命中了，优化器也可能因为回表成本高、选择性差而放弃。判断是否真的走了高效路径，要结合 EXPLAIN 的 rows、filtered、Extra 一起看。

8. MySQL 里为什么 B+ 树比红黑树更适合做索引

数据库索引关注的不是纯内存查找，而是磁盘页和 IO 成本。B+ 树扇出大、树高低，查询时随机 IO 少；叶子节点有序，天然适合范围扫描；内部节点只保存键，能提高页利用率。红黑树虽然适合内存排序，但树高更高，不适合数据库页组织。哈希表只能处理等值，范围能力太差，所以也不适合通用索引。

9. 讲一下页分裂和页合并对数据库性能的影响

页分裂会带来写放大、页迁移、缓存失效和锁竞争，尤其在随机插入场景下特别明显。页合并则更多发生在大量删除之后，虽然频率低，但会影响空间回收和后台整理成本。顺序自增主键通常比随机主键更友好，因为它能尽量减少叶子页频繁分裂。很多人只看插入成功与否，忽略了长期写性能和页结构退化。

10. 在高并发系统里，Redis 除了缓存还能做什么

Redis 还能做短期状态存储、幂等控制、分布式锁、限流计数、延迟任务、排行榜和热点数据协调。很多系统把 Redis 只看成数据库前置缓存，其实它更像一个高性能的运行时状态中心。特别是在 Agent 系统里，会话态、路由结果、任务中间状态和重复提交防护，都很适合放在 Redis 里。

11. 设计一个热点 key 失效后的降级方案，怎么避免缓存击穿把数据库打挂

先做互斥回源或 singleflight，确保同一个 key 只有一个请求回源；再做随机过期、逻辑过期和异步刷新，避免一批 key 同时过期；同时加本地缓存和限流兜底，防止大量请求直接冲向数据库。真正稳的方案不是“把缓存打得更大”，而是让失效后系统仍然能有序退化。

public String getWithLock(String key) {
    String val = redis.get(key);
    if (val != null) return val;
    synchronized (("LOCK_" + key).intern()) {
        val = redis.get(key);
        if (val != null) return val;
        val = queryDb(key);