三、核心技术场景考察及候选人表现（一）考察场景高并发秒杀场景：1 万人同时抢购 100 个库存的商品，要求保证用户体验、系统稳定性与扩展性（二）候选人方案及面试官质疑候选人核心方案：前端先获取 token（通过 Lua 脚本实现锁机制），再凭 token 下单；后续考虑通过 MQ 异步处理、库存分片等方式优化面试官核心质疑点超卖与少卖风险：Lua 脚本仅解决锁竞争问题，下单环节的复杂逻辑（风控等）可能导致下单失败，已分发 token 会造成少卖；锁机制无法完全避免超卖系统扩展性不足：面对 1000 万人抢 1 万个商品的场景，数据库难以承载高并发读写，token 机制与数据库扛压能力不匹配异步...

面试战绩： 字节 二面挂美团 一面挂携程 池子已一个月 大概率泡死wps 二面挂深信服 预二面其实还有几家给了面试机会但是眼高手低推掉了😭真的很后悔其余的全笔试挂了我笔试真真真真真的好烂啊，平常没积累实习结束的晚投递得晚没太多时间准备😭，导致根本没有几次面试机会，很多实际场景和项目拷打接的也不是很好只能看后续如果有面试机会再加把劲，多练算法准备春招不要重蹈覆辙了

我的简历真的很烂吗😭😭😭投了一个多月了找我的全是中科软、外企德科、科锐国际，孩子只是想找一个自研，25 双非真的这么难吗😭😭😭

面试官您好，关于 HashMap 的底层实现，我是按照以下三个维度来理解的：1. 宏观结构 (Overview)从宏观上看，HashMap 的底层结构在 JDK 1.8 中是 “数组 + 链表 + 红黑树”。它的主体是一个 Node 数组（源码中叫 table），数组的每个位置我们称之为“桶”（Bucket）。常规情况：当没有任何冲突时，数据直接存在数组里。Hash 冲突：当发生哈希冲突时，早期的 JDK 1.7 采用的是单纯的链表（头插法）。JDK 1.8 改进：为了解决哈希冲突导致链表过长、查询效率退化为 的问题，JDK 1.8 引入了红黑树。 转换机制：当链表长度 > 8 且 数组...