大厂面试高频题及详细答案.docxVIP

大厂面试高频题及详细答案

一、技术基础类

1.说说HashMap的底层实现，JDK1.7和1.8有什么区别？

答案：

先讲核心实现逻辑：HashMap本质是数组+链表（JDK1.8后增加红黑树）的结构，通过key的hash值计算数组下标，将键值对存储在对应位置。查询、插入时先定位下标，再遍历链表/红黑树找对应key。

JDK1.7和1.8的核心区别主要有4点：

①底层结构：1.7是数组+链表；1.8是数组+链表+红黑树（当链表长度超过8，且数组长度≥64时，链表转为红黑树；当长度小于6时，红黑树转回链表，平衡查询效率和插入成本）。

②hash值计算：1.7是9次扰动（4次位运算+5次异或）；1.8简化为1次扰动（hashCode()异或上hashCode()右移16位），既保证散列性，又提升效率。

③插入方式：1.7是头插法（容易在扩容时产生环形链表，导致死循环）；1.8是尾插法（避免环形链表问题）。

④扩容机制：1.7扩容时会重新计算所有元素的hash值；1.8利用原hash值的高位信息（因为扩容是2倍扩容，下标由hash值低n位决定，扩容后低n+1位，高位是否为1可直接判断元素该留在原位置还是移到新位置），不用重新计算hash，提升扩容效率。

补充：HashMap线程不安全，并发场景下可用ConcurrentHashMap，或用Collections.synchronizedMap包装，但后者效率较低。

2.什么是分布式锁？常用实现方式有哪些？各有什么优缺点？

答案：

分布式锁的核心目的：在分布式系统中，多个节点竞争同一资源时，保证同一时间只有一个节点能获取资源，避免并发问题（比如库存超卖、重复下单）。

常用实现方式及优缺点：

①基于Redis实现（最常用）

实现思路：用SETNXEX命令（原子操作），比如SETlock:keyvalueNXEX30，成功则获取锁；释放锁时用Lua脚本删除（避免误删别人的锁，脚本逻辑：判断当前锁的值是自己的，再删除）。

优点：性能好，Redis集群部署可保证高可用；缺点：需要处理锁超时问题（比如任务执行时间超过锁过期时间，可加续命机制，用后台线程定期刷新过期时间）；集群模式下（非主从切换）可能存在锁丢失问题（主节点锁还没同步到从节点，主节点挂了）。

②基于ZooKeeper实现

实现思路：利用ZooKeeper的临时有序节点。客户端在/lock路径下创建临时有序子节点，比如/lock/node-xxx；判断自己的节点是否是当前/lock下最小的子节点，是则获取锁；不是则监听前一个节点，前一个节点删除时，当前节点竞争锁。释放锁时，删除自己的子节点（临时节点特性：客户端断开连接自动删除，避免死锁）。

优点：天生支持高可用，不存在锁丢失问题；自带监听机制，不用处理超时续命；缺点：性能比Redis差（ZooKeeper是CP模型，需要集群同步）；部署和维护成本高。

③基于数据库实现

实现思路：创建锁表（id,lock_key,holder,create_time），获取锁时插入记录（lock_key唯一，用唯一索引保证原子性），释放锁时删除记录；还可加超时清理机制。

优点：实现简单，不用额外部署中间件；缺点：性能差（数据库压力大）；存在死锁风险（比如进程崩溃没释放锁）；分布式集群下数据库本身需要高可用（比如主从切换）。

二、项目经验类

1.你做过的项目中，遇到的最大技术难点是什么？怎么解决的？

答案（结合真实场景，避免空泛）：

我之前做过一个电商订单中心项目，当时遇到的最大难点是：订单创建接口在大促高峰期（比如双十一）出现响应超时、并发量上不去的问题，甚至出现少量订单重复创建的情况。

当时的排查和解决过程：

①先定位问题：通过监控工具（Prometheus+Grafana）查看接口的响应时间、QPS、错误率，发现高峰期QPS达到5000+时，响应时间从正常的50ms飙升到2s+；同时查看数据库慢查询日志，发现订单表的insert操作和关联查询（比如查询用户地址、商品库存）耗时过长；另外，重复订单问题是因为前端重试机制+后端没做幂等性校验导致的。

②分步骤解决：

第一步：做接口幂等性校验。前端传递唯一的请求ID（requestId），后端用Redis缓存requestId，创建订单前先判断requestId是否存在，存在则直接返回成功（避免重复创建），不存在则执行后续逻辑，创建成功后缓存requestId（设置过期时间，比如30分钟）。

第二步：优化数据库操作。首先，订单表之前是单表，数据量已经到1000万+，查询慢，所以做了分表（按用户ID哈希分表，分成16张表），减少单表数据量；其次，订单创建时需要查询用户地址、商品库存等信息，之前是同步查询，改成异