华为OD新系统机试与面试真题精选

正在备战 2026 华为 OD 校招 / 社招的同学，机试算法 + 技术面 C++ 八股是通关两大核心关卡！很多考生反馈华为 OD 技术面高频深挖 C++ 内存、智能指针、多态、进程线程、死锁等底层原理，答不全、踩知识点漏洞极易挂面。本专栏整理华为 OD 历年 C++ 高频面试八股，覆盖 90% 技术面提问；同时附上 2026 最新华为 OD 新系统机试全套真题题库入口，包含OD新系统机考全部算法题，配套多语言代码、考点解析，机试刷题 + 面试背诵一站式搞定，零基础、非科班也能快速突击上岸华为 OD。

点击查看华为 OD 机试真题完整目录：2026最新华为OD机试新系统卷 + 双机位C卷 真题题库目录｜全覆盖题库 + 逐点算法考点详解

华为OD面试真题精选：点击立即查看

华为 OD 面经｜26 届 Java 方向｜东莞｜机试、综测、HR 面、技术一二面全记录

一、基本信息

华为 OD Java 方向， 26 届应届生，地点为 东莞。

整体流程包括：

• 机试
• 综测
• HR 面
• 技术一面
• 技术二面
• 等待综面

机试为 7.5 场，分数 333。题目可参考算法大师提供的机考题库。技术面整体以 Java 基础、MySQL、并发、Spring、Redis、JVM、项目深挖、算法题 为主。

---

二、机试 & 综测

机试

7.5 场笔试，最终分数 333。

机试题目整体可以提前参考网上题库进行准备，重点还是熟悉常见输入输出、数组、字符串、栈、队列、DFS / BFS、动态规划等高频题型。

建议：

• 提前熟悉华为 OD 机试输入输出格式。
• 多刷题库中的高频题，尤其是数组模拟、字符串处理、栈、图搜索类题目。
• 代码要注意边界条件、时间复杂度和异常输入。
• 面试阶段可能会打开机试代码让候选人讲解思路，因此不要只背答案，要能讲清楚解法。

综测

综测一般由外包 HR 提供题库答案，按要求填写即可。

建议：

• 保持答案前后一致。
• 不要出现明显极端或矛盾选项。
• 保持职业稳定性、团队协作、抗压能力等倾向。

---

三、HR 面

HR 面整体更偏稳定性和匹配度考察。面试官重点围绕 求职动机、城市选择、加班接受度、职业规划、对 OD 的了解 进行追问，例如：

• 自我介绍，并介绍实习经历。
• 为什么选择来东莞？
• 离职原因是什么？
• 对加班怎么看？
• 未来职业规划是什么？
• 对 OD 了解多少？为什么选择华为和 OD？
• 反问环节。

其中，“为什么来东莞”主要考察候选人是否有长期发展的可能；“对加班怎么看”主要考察候选人对交付节奏和岗位压力的接受程度。

建议：

HR 面不要只机械表态“都能接受”，更建议回答得稳定、真实、有逻辑：

• 城市选择要体现稳定性，例如能接受东莞发展，重点看岗位和平台机会。
• 离职原因避免抱怨前公司，可从职业发展、岗位匹配度、成长空间角度回答。
• 对加班可以表达理解和配合，但也要补充会通过提升效率、合理规划减少无效加班。
• 对 OD 要提前了解，能说明 OD 的岗位性质、工作模式和自己为什么接受。
• 职业规划要贴合 Java 后端方向，体现愿意长期积累技术和业务经验。

---

四、技术一面

技术一面以 Java 后端基础 + 数据库 + 并发 + Spring + Redis + 链表 + JVM / 内存排查 + 机试代码讲解 + 手撕算法 为主，整体偏基础八股和编码思路表达。

项目与经历

1. 自我介绍。
2. 介绍实习经历。
3. 介绍项目经历。
4. 打开笔试时代码，讲解实现思路。

建议：

项目介绍建议按“背景—职责—技术方案—难点—结果”展开，不要只罗列技术栈。机试代码讲解时，要说明题意理解、核心数据结构、复杂度和边界处理。

MySQL

1. 多个人同时修改数据库会发生什么？
2. 联合索引相关问题：给定几个索引场景，判断是否走索引，并说明原因。

参考思路：

多事务同时修改同一行数据时，MySQL 会通过事务和锁机制保证一致性。通常先获取锁的事务继续执行，其他事务等待；如果多个事务互相等待，就可能产生死锁，数据库会检测并回滚其中一个事务。

联合索引判断是否生效，核心看：

• 是否符合最左前缀原则。
• 是否跳过了联合索引的前导列。
• 是否对索引列使用函数、计算或隐式类型转换。
• like 是否以通配符开头。
• 范围查询后面的索引列是否还能继续充分利用。

Java 并发

1. 并发控制有哪几种方式？
2. synchronized 和 Lock 的区别是什么？

参考思路：

并发控制可以从以下几类回答：

• 悲观锁：如 synchronized、ReentrantLock、数据库行锁。
• 乐观锁：如版本号机制、CAS。
• 线程安全容器：如 ConcurrentHashMap、CopyOnWriteArrayList。
• 读写锁：适合读多写少场景。
• 消息队列或串行化处理：将并发写转为顺序消费。

synchronized 是 JVM 内置锁，使用简单，会自动加锁和释放锁；Lock 是 JUC 提供的显式锁，需要手动释放，但能力更灵活，例如支持公平锁、可中断锁、超时获取锁、多个条件队列等。

Spring

1. Spring 有哪些核心功能？
2. 介绍 IOC。
3. 手动 new 的对象能不能交给 Spring 管理？
4. Bean 对象注入方式有哪些？

参考思路：

Spring 核心功能主要包括：

• IOC / DI：对象创建和依赖注入由容器管理。
• AOP：将日志、事务、权限等横切逻辑与业务逻辑解耦。
• 事务管理：统一管理数据库事务。
• MVC / Web 支持：用于构建 Web 应用。
• Bean 生命周期管理：负责 Bean 的创建、初始化、销毁等过程。

手动 new 出来的对象默认不归 Spring 容器管理，因此不能直接享受依赖注入、AOP、事务代理等能力。如果确实需要交给 Spring 管理，可以通过配置 Bean、组件扫描、@Bean 方法或手动注册到容器等方式实现。

Bean 注入方式包括：

• 构造器注入。
• Setter 注入。
• 字段注入。
• 方法参数注入。

实际开发中更推荐构造器注入，因为依赖关系更清晰，也更利于测试。

Redis / 消息队列

1. Redis 可不可以当消息队列？
2. 既然 Redis 可以做消息队列，为什么还要用 RabbitMQ？
3. Redis 和 RabbitMQ 的本质区别是什么？

参考思路：

Redis 可以实现消息队列，例如通过 List、Pub/Sub、Stream 等方式实现。但 Redis 本质上是内存数据结构存储系统，更适合缓存、高性能数据结构和轻量消息场景。

RabbitMQ 是专业消息中间件，提供更完整的消息能力，例如：

• 消息确认机制。
• 持久化。
• 路由交换机。
• 重试机制。
• 死信队列。
• 消费者确认和流控。

因此，如果只是简单异步通知或轻量队列，Redis 可以胜任；如果业务对可靠性、路由、重试、削峰填谷和消息可追踪性要求更高，更适合使用 RabbitMQ。

数据结构

1. 是否用过双向链表？
2. 双向链表和单向链表在插入、删除上的效率有什么区别？

参考思路：

单向链表每个节点只有 next 指针，结构简单、空间占用更少；双向链表有 prev 和 next 指针，可以同时访问前驱和后继。

如果已经定位到目标节点，二者插入和删除都可以做到 O(1)。但双向链表在删除当前节点时更方便，因为可以直接找到前驱节点；单向链表如果不知道前驱节点，需要从头遍历寻找前驱，时间复杂度可能变为 O(n)。

JVM / 内存排查

1. 是否遇到过内存问题？
2. 如何排查？
3. 用过什么工具？
4. 了解虚拟线程和协程吗？是否使用过？

参考思路：

内存问题可以按“现象—定位—分析—解决”回答：

• 现象：OOM、频繁 Full GC、接口变慢、内存持续上涨。
• 定位：查看 GC 日志、监控指标、堆内存快照和线程情况。
• 工具：jstat、jmap、jstack、Arthas、MAT、VisualVM。
• 分析：检查大对象、无界缓存、集合持续累积、线程数异常、连接未释放等。
• 解决：限制缓存大小、修复对象引用、分页处理大数据、优化对象生命周期。

虚拟线程可以说明是 Java 为高并发 I/O 场景提供的轻量级线程模型；协程是更广义的轻量级并发模型。如果没有实际使用过，可以如实说明了解概念，但生产项目中暂未落地。

手撕算法

题目描述：

• 长度为 n 的数组。
• 每次可以把 m 个连续且相同的数替换为它们的和。
• 替换后的数继续放回原数组，可能继续触发合并。
• 重复该过程，直到数组中不存在 m 个连续相同的数。
• 输出最终数组。

---

五、技术二面

技术二面相比一面更偏 项目深挖、数据库优化、并发容器、性能优化、JVM、AI 工具使用、算法题，更关注候选人是否真的做过项目，以及能否把技术方案讲清楚。

项目与实习深挖

1. 自我介绍。
2. 介绍实习经历。
3. 介绍项目经历。
4. 结合实习，讲一下你在数据库表设计或优化上提升性能的经验。
5. 简历内容基本问完后，是否还有需要补充的重点？

建议：

二面项目追问会更细，需要提前准备 2-3 个项目亮点，例如：

• 慢 SQL 优化。
• 缓存设计。
• 秒杀业务优化。
• 接口响应时间优化。
• 数据库表结构优化。
• 高并发场景下的数据一致性处理。

每个亮点建议按这个结构准备：

• 背景：为什么要优化？
• 问题：原来有什么瓶颈？
• 定位：通过什么工具或指标发现？
• 方案：具体怎么改？
• 结果：性能提升了多少，或者稳定性改善在哪里？

数据库优化

1. 如果项目中的 SQL 非常多、非常杂，怎么判断里面是否有语句影响性能或存在优化空间？
2. 数据库表设计或优化方面，如何提升性能？

参考思路：

可以从以下几个角度回答：

• 开启慢 SQL 日志，筛选执行时间长、扫描行数多、执行频率高的 SQL。
• 使用 EXPLAIN 分析执行计划，重点看索引使用、扫描行数、连接类型、是否出现 Using filesort、Using temporary。
• 结合业务链路监控，定位接口耗时高的 SQL。
• 对高频 SQL 建立合适索引，避免索引缺失或冗余索引。
• 优化 SQL 写法，避免 select *、函数操作索引列、隐式类型转换、大分页。
• 对大表考虑分库分表、冷热数据分离、归档历史数据。
• 对读多写少场景使用缓存，但要注意一致性和过期策略。

表设计优化可以补充：

• 字段类型尽量小而合适。
• 高频查询字段建立索引。
• 控制单表字段数量和行大小。
• 合理设计主键，避免过长主键。
• 根据业务查询模型设计表结构，而不是只追求范式。

Java 并发与集合

1. 如果有一个 ArrayList 资源，一般如何保证线程安全？
2. 讲一下 ConcurrentHashMap。
3. 平时如何使用 synchronized？锁实例还是锁类？

参考思路：

如果要保证 ArrayList 线程安全，可以根据场景选择：

• 使用 Collections.synchronizedList() 包装。
• 使用 CopyOnWriteArrayList，适合读多写少。
• 使用局部变量，避免共享可变状态。
• 使用并发容器替代原容器。
• 必要时用锁保护临界区。

注意：面试中不要第一反应只说“加锁”，可以先从数据结构和场景选择角度回答。

ConcurrentHashMap 可以这样回答：

• JDK 1.8 中主要基于数组 + 链表 + 红黑树。
• 通过 CAS + synchronized 控制并发更新。
• 读操作大多不加锁，依赖 volatile 保证可见性。
• 写操作只锁定局部桶节点，降低锁粒度。
• 链表长度达到阈值且数组容量满足条件时，会转为红黑树，优化查询性能。

synchronized 使用时要注意锁对象选择：

• 锁实例对象：只保护当前对象实例的共享资源。
• 锁类对象：保护类级别共享资源，影响范围更大。
• 锁私有对象：更推荐，避免外部代码误用同一个锁。
• 不建议锁字符串常量、包装类常量等可能被共享的对象。

性能优化

1. 你做过很多性能优化，是怎么判断这些地方需要优化的？
2. 具体怎么优化的？
3. 能结合秒杀业务讲几个例子吗？

参考思路：

性能优化不要直接说“我加了缓存、加了索引”，而要按完整链路回答：

• 通过监控、日志、压测、慢 SQL、链路追踪发现瓶颈。
• 判断瓶颈属于数据库、缓存、网络、CPU、锁竞争还是外部接口。
• 针对瓶颈选择方案，而不是盲目优化。
• 优化后用数据验证结果。

秒杀业务可以从以下角度展开：

• 使用 Redis 预扣库存，减少数据库压力。
• 使用消息队列异步下单，削峰填谷。
• 使用限流、验证码、风控拦截异常流量。
• 使用分布式锁或 Lua 脚本保证库存扣减原子性。
• 使用唯一索引或幂等表防止重复下单。
• 热点商品信息提前缓存，减少数据库查询。

JVM

1. 了解 JVM 吗？
2. 能不能讲一下 G1 垃圾回收过程？

参考思路：

G1 的核心特点是将堆划分为多个大小相等的 Region，不再简单按连续的新生代、老年代物理空间划分。它的目标是在可预测停顿时间内，优先回收收益最高的 Region。

G1 回收过程可以这样答：

• 初始标记：标记 GC Roots 直接关联的对象，会 STW。
• 并发标记：从 GC Roots 开始进行可达性分析，与用户线程并发执行。
• 最终标记：修正并发标记期间变化的引用关系，会 STW。
• 筛选回收：根据 Region 的垃圾比例和回收收益，选择部分 Region 进行回收。
• 混合回收：不仅回收年轻代，也会回收部分老年代 Region。

可以补充：G1 适合大堆内存、对停顿时间有要求的服务端应用。

AI 工具使用

1. 使用过哪些 AI 工具？
2. 如何让 AI 工具更好地帮助你？

参考思路：

可以回答使用过 ChatGPT、通义、文心、Copilot 等工具，主要用于：

• 辅助理解陌生代码。
• 生成单元测试样例。
• 梳理技术方案。
• 排查报错原因。
• 优化文档和接口说明。
• 辅助学习新技术。

但要强调不会完全依赖 AI：

• 关键代码和结论需要自己验证。
• 涉及业务逻辑、数据安全和线上变更时必须人工确认。
• 提问时要提供清晰上下文、约束条件、目标格式和已有尝试。
• 把 AI 当作效率工具，而不是替代工程判断。

手撕算法

技术二面的算法题为建图 + DFS 遍历，题目整体不复杂。

准备建议：

重点掌握以下内容：

• 邻接表建图。
• DFS 递归写法。
• DFS 非递归栈写法。
• visited 数组防止重复访问。
• 连通分量、路径搜索、拓扑相关基础题型。

---

六、整体感受

整体来看，这次华为 OD Java 面试流程比较完整，技术面覆盖面较广，但问题并不特别偏，主要集中在 Java 后端常见基础和项目真实性考察。

一面更偏基础八股和编码思路，包括 MySQL、并发、Spring、Redis、JVM、数据结构和机试代码讲解；二面更偏项目深挖和实际工程能力，尤其关注数据库优化、性能优化、并发容器、秒杀业务和问题定位能力。

建议：

• 机试代码一定要能讲清楚，面试中可能会直接打开笔试代码追问。
• Java 基础八股要准备扎实，尤其是 MySQL 索引、并发、Spring、Redis、JVM。
• 项目不能只背技术栈，要准备真实问题、解决方案和结果数据。
• HR 面要重视稳定性表达，尤其是城市选择、加班态度和 OD 认知。
• 对性能优化类问题，要重点体现“发现问题—定位问题—解决问题—验证结果”的闭环思维。