基本信息形式：1V1视频面试，面试官多为技术骨干或团队Leader。包含自我介绍、项目经历深挖、技术八股、算法题四个环节。 时长：约40-60分钟。项目深挖约占15-20分钟，技术提问15-20分钟，算法10-15分钟。 氛围：节奏紧凑，问题深入。面试官会顺着你的回答层层追问，注重考察对底层原理的理解。
面试流程一面通知 → 按时参加视频面试 → 自我介绍 → 项目深挖 → 技术八股提问 → 手撕代码 → 反问环节 → 退场（一面结束后很快通知二面）。 面试问题及参考回答一、项目与实习经历深挖（核心环节）说明：滴滴面试的项目深挖约占15-20分钟，面试官会顺着你的项目问到具体的技术实现、方案选型、难点攻克等细节。
问题1：介绍一下你的核心项目，你在其中的角色和贡献。 参考回答：（采用STAR原则回答） S（情境） ：在[项目名称]中，我们面临[具体问题/业务需求]。 T（任务） ：我负责[核心模块]，目标是[关键指标]。 A（行动） ：我采用了[具体技术方案]，设计了[系统架构]。遇到[XX困难]时，我通过[查阅资料/方案对比/团队协作]解决了问题。 R（结果） ：最终[性能提升了X%/响应时间降低了Xms/支撑了X万QPS]。
问题2：什么时候进行分表？按什么维度分？ 参考回答：当单表数据量达到500w-1000w行或读写性能出现瓶颈时需考虑分表。分表维度有两种：水平分表（按行拆分，如按用户ID取模、按时间范围）和垂直分表（按列拆分，将热点字段与冷数据分离）。选择哪种维度要结合业务访问模式——如果查询大多按用户维度，就以用户ID取模做水平分片。
问题3：可以基于时间查询任务状态吗？如何根据其他字段定位到表号？ 参考回答：如果分表是按用户ID取模，按时间查询确实会成为难题。常见解法：①建立映射索引表，记录时间与表号的映射关系；②采用全局二级索引（类似ES）；③范围查询时广播查所有分表再聚合（scatter-gather）；④设计时兼顾查询维度，采用分区键+辅助键的组合分片策略。这道题的核心考察点在于分片键选择与查询灵活性之间的权衡。
问题4：ES的索引力度和查询效率是怎么平衡的？有没有做冷热分离？ 参考回答：平衡策略包括：①根据查询模式设计索引字段，避免过度索引；②冷热分离——近期数据放在热节点（SSD），历史数据迁移到冷节点（HDD）；③合理设置分片数和副本数；④利用索引生命周期管理自动迁移数据。
问题5：在与大模型交互时，是单轮还是多轮？为什么这么选择？ 参考回答：根据场景选择——简单任务（单轮问答）用单轮即可，复杂任务（需要多步推理、工具调用）用多轮Auto-agent模式。多轮可以保留上下文、支持工具链调用，但延迟更高。
二、Java/Go基础与并发（技术核心）
问题1：HashMap底层实现？为什么数组长度是2的n次幂？ 参考回答：JDK 8中HashMap采用数组+链表+红黑树结构。默认初始容量16，负载因子0.75。链表长度超过8且数组长度≥64时，链表转红黑树，查询复杂度从O(n)降为O(log n)。 数组长度是2的n次幂的核心原因是为了用位运算(n-1) & hash替代取模运算hash % n，效率更高。且扩容时元素要么留在原位，要么移动到「原位置+旧容量」处，无需重新计算哈希值。
问题2：介绍ConcurrentHashMap？ 参考回答：JDK 8中ConcurrentHashMap放弃了JDK 7的Segment分段锁，改用CAS + synchronized：
问题3：CAS是什么？ABA问题如何解决？ 参考回答：CAS（Compare And Swap）是一种乐观锁机制，包含内存值、预期值、新值三个操作数。只有当内存值等于预期值时，才将其更新为新值，否则重试。 ABA问题：变量从A变为B再变回A，CAS无法感知中间变化。解决方案：使用AtomicStampedReference，在值的基础上附加版本号（stamp），每次更新时版本号自增；或用AtomicMarkableReference（布尔标记）。
问题4：介绍AQS，是公平锁还是非公平锁？ 参考回答：AQS（AbstractQueuedSynchronizer）是JUC中锁和同步器的核心框架，底层维护一个volatile int state和一个CLH双向等待队列。ReentrantLock默认是非公平锁（直接CAS抢锁），公平锁版本会先检查队列中是否有等待线程，有则入队等待，保证FIFO顺序。
问题5：MySQL事务隔离级别？怎么实现的？ 参考回答：四种隔离级别：READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE。MVCC（多版本并发控制）是实现机制——每行数据有隐藏列（创建版本号、删除版本号），事务读取时只读取版本号小于等于当前事务版本号的数据，从而实现可重复读和读已提交。
三、缓存与消息队列（滴滴高频）
问题1：Redis为什么高性能？ 参考回答：①纯内存操作；②单线程模型，避免上下文切换和锁竞争；③I/O多路复用（epoll），单线程同时处理多个客户端连接；④高效数据结构（SDS、跳表、压缩列表等）。
问题2：Redis与MySQL缓存一致性怎么保证？ 参考回答：采用旁路缓存策略（Cache-Aside） ：写请求先更新DB，再删除缓存；读请求先查缓存，未命中再查DB并回写。延迟双删策略更可靠——先删缓存→更新DB→休眠→再删缓存，避免并发读写导致的脏数据。
问题3：RocketMQ vs Kafka的区别？ 参考回答：Kafka侧重高吞吐日志场景，对消息可靠性保证较弱，适合ELK日志收集、大数据ETL；RocketMQ侧重金融级消息可靠性，支持事务消息、延迟消息、消息轨迹追踪，适合电商交易、订单系统。滴滴作为实时调度平台，对消息可靠性和延迟要求都很高。
问题4：Kafka为什么高性能？ 参考回答：①顺序写磁盘：消息追加写入Segment文件，比随机写快几十倍；②零拷贝（Zero Copy）：使用sendfile系统调用，数据直接从PageCache发送到网卡；③批量压缩；④分区并行；⑤PageCache缓冲。
| 
发表于 2026-5-27 22:43:02