写在前面去年七月我参加了滴滴校招提前批后端开发的面试部门是网约车安全一面在一天内完成。整场面试涵盖了项目经验、Java并发基础、分布式中间件到算法手撕考察范围极广节奏也非常紧凑。在这里我把所有面试题目和思路整理出来帮助正在备战大厂的你少走弯路。⚡ 友情提示本文干货密集建议收藏后反复阅读配合实际刷题效果更佳面试全貌一览本次一面共涉及 16 道题目分布在以下几个核心方向自我介绍 项目深挖2题分库分表设计4题Java 集合 并发6题Kafka 高性能 延迟队列2题算法手撕合并区间1题Part 1项目深挖 — 分库分表设计一上来就是项目经验但别以为聊聊就行——面试官会顺着你的项目把数据库设计问到底。Q1. 什么时候进行分表按照什么维度当单表数据量达到瓶颈通常建议 500w 行以内或读写性能出现瓶颈时就需要考虑分表。分表维度通常有两种水平分表按行拆分如按用户ID、时间范围和垂直分表按列拆分将热点字段与冷数据分离。具体选择哪种维度要结合业务访问模式来决定——如果查询大多数是按用户维度就以用户ID取模做水平分片。Q2. 为什么一张表的上限要设计为 500w500w 并不是一个官方定论而是工程经验值。MySQL InnoDB 的 B 树索引在数据量超过一定规模后树高度增加磁盘 I/O 次数增多查询性能下降明显。通常一个 B 树节点大小为 16KB3层树高可以支撑约 2000w 行。但考虑到索引维护、并发写入和备份压力500w ~ 1000w 是更稳妥的工程选择。备战Tips面试时说出「树高度与 I/O 次数」的关系加分项Q3. 可以基于时间查询任务状态吗如何根据其他字段定位到表号如果分表是按用户ID取模那么按时间查询会成为一个难题因为无法直接定位到哪张表。常见解法① 建立映射索引表记录时间与表号的映射关系② 采用全局二级索引类似ES③ 范围查询时广播查所有分表再聚合scatter-gather④ 设计时兼顾查询维度如采用分区键 辅助键的组合分片策略。这道题的核心考察点分片键选择与查询灵活性之间的权衡取舍。Part 2Java 集合 并发这一part是重头戏滴滴对底层原理的考察非常深入不只是问「会不会用」而是要你说清楚「为什么」。Q4. HashMap 底层实现JDK 8 之后HashMap 采用 数组 链表 红黑树 的结构。默认初始容量 16负载因子 0.75。当链表长度超过 8 且数组长度 64 时链表转换为红黑树将查询时间复杂度从 O(n) 降为 O(log n)。Q5. 如何解决哈希冲突哈希函数有什么优化HashMap 使用链地址法解决冲突。在哈希函数上JDK 8 引入了扰动函数将 hashCode 的高16位与低16位进行异或使哈希值更加均匀分布降低碰撞概率。Q6. 为什么 HashMap 底层数组长度是 2 的 n 次幂核心原因是为了用位运算 (n-1) hash 替代取模运算 hash % n效率更高。当数组长度是 2 的 n 次幂时(n-1) 的二进制全为 1运算等价于取余同时保证了索引均匀分布。扩容时同样受益元素要么留在原位要么移动到「原位置 旧容量」处无需重新计算所有哈希值。Q7. 介绍 ConcurrentHashMapJDK 8 中 ConcurrentHashMap 放弃了 JDK 7 的 Segment 分段锁改用 CAS synchronized 的方式• 对空桶插入时使用 CAS 无锁操作对已有节点的操作则锁住链表头节点粒度更细• 扩容支持多线程协同迁移transfer大幅提升并发性能。Q8. CAS 是什么ABA 问题如何解决CASCompare And Swap是一种乐观锁机制包含三个操作数内存值、预期值、新值。只有当内存值等于预期值时才将其更新为新值否则重试。ABA 问题变量从 A 变为 B 再变回 ACAS 无法感知中间的变化。解决方案使用 AtomicStampedReference在值的基础上附加版本号stamp每次更新时版本号自增从而识别 ABA 变化。备战Tips除了版本号也可以用 AtomicMarkableReference布尔标记适用于只需标记「是否被修改过」的场景。Q9. 介绍 AQS是公平锁还是非公平锁公平锁如何实现AQSAbstractQueuedSynchronizer是 JUC 中锁和同步器的核心框架底层维护了一个 volatile int state 和一个 CLH 双向等待队列。ReentrantLock 默认是非公平锁直接 CAS 抢锁公平锁版本会先检查队列中是否有等待线程有则入队等待保证 FIFO 顺序。Q10. 讲一下条件锁条件队列Condition 是 AQS 提供的条件变量类比 Object.wait/notify但功能更强支持多个条件队列。调用 condition.await() 时当前线程释放锁并进入条件队列调用 condition.signal() 时将条件队列中的线程转移到 AQS 等待队列重新竞争锁。典型应用生产者-消费者模型ReentrantLock 两个 Condition 分别表示「队列非空」和「队列未满」。Part 3Kafka 高性能揭秘Q11. Kafka 为什么是高性能的Kafka 的高性能来自多个维度的协同设计① 顺序写磁盘消息追加写入 Segment 文件比随机写快几十倍② 零拷贝Zero Copy使用 sendfile 系统调用跳过用户空间数据直接从 PageCache 发送到 NIC③ 批量压缩Producer 端批量发送 压缩减少网络传输量④ 分区并行多 Partition 支持并行消费水平扩展吞吐⑤ PageCache利用操作系统的 Page Cache 做缓冲减少实际磁盘 I/O。Q12. Kafka 如何实现延迟队列Kafka 原生并不支持延迟队列但可以通过以下方案实现方案一时间轮Kafka 内部使用多层时间轮Hierarchical Timing Wheels处理延迟任务可借鉴此思路在业务层实现。方案二层级Topic设计多个延迟级别的 Topic如 delay-5s、delay-10s、delay-30s消息先投递到对应延迟 Topic由专属 Consumer 轮询到期后再投递到真正的业务 Topic。方案三结合 RocketMQ如果延迟队列需求较强可考虑换用原生支持 18 级延迟消息的 RocketMQ。备战Tips面试中如果你能主动对比 Kafka 与 RocketMQ 的延迟队列方案会显得非常有深度。Part 4算法手撕 — 合并区间LeetCode 56. Merge Intervals难度中等属于高频必刷题。核心思路① 将所有区间按照左端点升序排序② 遍历区间维护一个「当前合并区间」③ 若下一区间的左端点 当前区间右端点则合并右端点取 max④ 否则将当前区间加入结果并以新区间开始新一轮合并。⏱ 时间复杂度 O(n log n)空间复杂度 O(n)。务必处理好边界条件空输入、单个区间等。int[][] merge(int[][] intervals) {Arrays.sort(intervals, (a, b) - a[0] - b[0]);Listint[] res new ArrayList();for (int[] cur : intervals) {if (res.isEmpty() || res.getLast()[1] cur[0])res.add(cur);elseres.getLast()[1] Math.max(res.getLast()[1], cur[1]);}return res.toArray(new int[0][]);}总结与复盘考察方向涉及题目重要程度项目 数据库分库分表、分片策略、索引设计⭐⭐⭐⭐⭐Java 集合HashMap、ConcurrentHashMap⭐⭐⭐⭐⭐Java 并发CAS/ABA、AQS、条件锁⭐⭐⭐⭐⭐消息队列Kafka 高性能、延迟队列⭐⭐⭐⭐算法合并区间LeetCode 56⭐⭐⭐✅ 整体来看滴滴一面的考察非常扎实重点在于底层原理的理解和工程实践经验的结合。如果你也在备战大厂建议把 Java 并发JUC和 MySQL 索引 分表策略作为重点攻坚方向。如果这篇文章对你有帮助欢迎点赞、在看、分享你的支持是我持续分享的动力
一天速通滴滴校招！后端开发 | 网约车安全部门 | 真实一面全记录16道高频考题 + 手撕算法，你敢来挑战吗？
发布时间：2026/7/27 11:12:07
写在前面去年七月我参加了滴滴校招提前批后端开发的面试部门是网约车安全一面在一天内完成。整场面试涵盖了项目经验、Java并发基础、分布式中间件到算法手撕考察范围极广节奏也非常紧凑。在这里我把所有面试题目和思路整理出来帮助正在备战大厂的你少走弯路。⚡ 友情提示本文干货密集建议收藏后反复阅读配合实际刷题效果更佳面试全貌一览本次一面共涉及 16 道题目分布在以下几个核心方向自我介绍 项目深挖2题分库分表设计4题Java 集合 并发6题Kafka 高性能 延迟队列2题算法手撕合并区间1题Part 1项目深挖 — 分库分表设计一上来就是项目经验但别以为聊聊就行——面试官会顺着你的项目把数据库设计问到底。Q1. 什么时候进行分表按照什么维度当单表数据量达到瓶颈通常建议 500w 行以内或读写性能出现瓶颈时就需要考虑分表。分表维度通常有两种水平分表按行拆分如按用户ID、时间范围和垂直分表按列拆分将热点字段与冷数据分离。具体选择哪种维度要结合业务访问模式来决定——如果查询大多数是按用户维度就以用户ID取模做水平分片。Q2. 为什么一张表的上限要设计为 500w500w 并不是一个官方定论而是工程经验值。MySQL InnoDB 的 B 树索引在数据量超过一定规模后树高度增加磁盘 I/O 次数增多查询性能下降明显。通常一个 B 树节点大小为 16KB3层树高可以支撑约 2000w 行。但考虑到索引维护、并发写入和备份压力500w ~ 1000w 是更稳妥的工程选择。备战Tips面试时说出「树高度与 I/O 次数」的关系加分项Q3. 可以基于时间查询任务状态吗如何根据其他字段定位到表号如果分表是按用户ID取模那么按时间查询会成为一个难题因为无法直接定位到哪张表。常见解法① 建立映射索引表记录时间与表号的映射关系② 采用全局二级索引类似ES③ 范围查询时广播查所有分表再聚合scatter-gather④ 设计时兼顾查询维度如采用分区键 辅助键的组合分片策略。这道题的核心考察点分片键选择与查询灵活性之间的权衡取舍。Part 2Java 集合 并发这一part是重头戏滴滴对底层原理的考察非常深入不只是问「会不会用」而是要你说清楚「为什么」。Q4. HashMap 底层实现JDK 8 之后HashMap 采用 数组 链表 红黑树 的结构。默认初始容量 16负载因子 0.75。当链表长度超过 8 且数组长度 64 时链表转换为红黑树将查询时间复杂度从 O(n) 降为 O(log n)。Q5. 如何解决哈希冲突哈希函数有什么优化HashMap 使用链地址法解决冲突。在哈希函数上JDK 8 引入了扰动函数将 hashCode 的高16位与低16位进行异或使哈希值更加均匀分布降低碰撞概率。Q6. 为什么 HashMap 底层数组长度是 2 的 n 次幂核心原因是为了用位运算 (n-1) hash 替代取模运算 hash % n效率更高。当数组长度是 2 的 n 次幂时(n-1) 的二进制全为 1运算等价于取余同时保证了索引均匀分布。扩容时同样受益元素要么留在原位要么移动到「原位置 旧容量」处无需重新计算所有哈希值。Q7. 介绍 ConcurrentHashMapJDK 8 中 ConcurrentHashMap 放弃了 JDK 7 的 Segment 分段锁改用 CAS synchronized 的方式• 对空桶插入时使用 CAS 无锁操作对已有节点的操作则锁住链表头节点粒度更细• 扩容支持多线程协同迁移transfer大幅提升并发性能。Q8. CAS 是什么ABA 问题如何解决CASCompare And Swap是一种乐观锁机制包含三个操作数内存值、预期值、新值。只有当内存值等于预期值时才将其更新为新值否则重试。ABA 问题变量从 A 变为 B 再变回 ACAS 无法感知中间的变化。解决方案使用 AtomicStampedReference在值的基础上附加版本号stamp每次更新时版本号自增从而识别 ABA 变化。备战Tips除了版本号也可以用 AtomicMarkableReference布尔标记适用于只需标记「是否被修改过」的场景。Q9. 介绍 AQS是公平锁还是非公平锁公平锁如何实现AQSAbstractQueuedSynchronizer是 JUC 中锁和同步器的核心框架底层维护了一个 volatile int state 和一个 CLH 双向等待队列。ReentrantLock 默认是非公平锁直接 CAS 抢锁公平锁版本会先检查队列中是否有等待线程有则入队等待保证 FIFO 顺序。Q10. 讲一下条件锁条件队列Condition 是 AQS 提供的条件变量类比 Object.wait/notify但功能更强支持多个条件队列。调用 condition.await() 时当前线程释放锁并进入条件队列调用 condition.signal() 时将条件队列中的线程转移到 AQS 等待队列重新竞争锁。典型应用生产者-消费者模型ReentrantLock 两个 Condition 分别表示「队列非空」和「队列未满」。Part 3Kafka 高性能揭秘Q11. Kafka 为什么是高性能的Kafka 的高性能来自多个维度的协同设计① 顺序写磁盘消息追加写入 Segment 文件比随机写快几十倍② 零拷贝Zero Copy使用 sendfile 系统调用跳过用户空间数据直接从 PageCache 发送到 NIC③ 批量压缩Producer 端批量发送 压缩减少网络传输量④ 分区并行多 Partition 支持并行消费水平扩展吞吐⑤ PageCache利用操作系统的 Page Cache 做缓冲减少实际磁盘 I/O。Q12. Kafka 如何实现延迟队列Kafka 原生并不支持延迟队列但可以通过以下方案实现方案一时间轮Kafka 内部使用多层时间轮Hierarchical Timing Wheels处理延迟任务可借鉴此思路在业务层实现。方案二层级Topic设计多个延迟级别的 Topic如 delay-5s、delay-10s、delay-30s消息先投递到对应延迟 Topic由专属 Consumer 轮询到期后再投递到真正的业务 Topic。方案三结合 RocketMQ如果延迟队列需求较强可考虑换用原生支持 18 级延迟消息的 RocketMQ。备战Tips面试中如果你能主动对比 Kafka 与 RocketMQ 的延迟队列方案会显得非常有深度。Part 4算法手撕 — 合并区间LeetCode 56. Merge Intervals难度中等属于高频必刷题。核心思路① 将所有区间按照左端点升序排序② 遍历区间维护一个「当前合并区间」③ 若下一区间的左端点 当前区间右端点则合并右端点取 max④ 否则将当前区间加入结果并以新区间开始新一轮合并。⏱ 时间复杂度 O(n log n)空间复杂度 O(n)。务必处理好边界条件空输入、单个区间等。int[][] merge(int[][] intervals) {Arrays.sort(intervals, (a, b) - a[0] - b[0]);Listint[] res new ArrayList();for (int[] cur : intervals) {if (res.isEmpty() || res.getLast()[1] cur[0])res.add(cur);elseres.getLast()[1] Math.max(res.getLast()[1], cur[1]);}return res.toArray(new int[0][]);}总结与复盘考察方向涉及题目重要程度项目 数据库分库分表、分片策略、索引设计⭐⭐⭐⭐⭐Java 集合HashMap、ConcurrentHashMap⭐⭐⭐⭐⭐Java 并发CAS/ABA、AQS、条件锁⭐⭐⭐⭐⭐消息队列Kafka 高性能、延迟队列⭐⭐⭐⭐算法合并区间LeetCode 56⭐⭐⭐✅ 整体来看滴滴一面的考察非常扎实重点在于底层原理的理解和工程实践经验的结合。如果你也在备战大厂建议把 Java 并发JUC和 MySQL 索引 分表策略作为重点攻坚方向。如果这篇文章对你有帮助欢迎点赞、在看、分享你的支持是我持续分享的动力
