华为 OD 面经|26 届 Java 方向|东莞|机试、综测、HR 面、技术一二面全记录
华为 OD 面经|26 届 Java 方向|东莞|机试、综测、HR 面、技术一二面全记录
正在备战 2026 华为 OD 校招 / 社招的同学,机试算法 + 技术面 C++ 八股是通关两大核心关卡!很多考生反馈华为 OD 技术面高频深挖 C++ 内存、智能指针、多态、进程线程、死锁等底层原理,答不全、踩知识点漏洞极易挂面。本专栏整理华为 OD 历年 C++ 高频面试八股,覆盖 90% 技术面提问;同时附上 2026 最新华为 OD 新系统机试全套真题题库入口,包含OD新系统机考全部算法题,配套多语言代码、考点解析,机试刷题 + 面试背诵一站式搞定,零基础、非科班也能快速突击上岸华为 OD。
点击查看华为 OD 机试真题完整目录:2026最新华为OD机试新系统卷 + 双机位C卷 真题题库目录|全覆盖题库 + 逐点算法考点详解
华为OD面试真题精选:点击立即查看
文章目录
一、基本信息
华为 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 / 内存排查 + 机试代码讲解 + 手撕算法 为主,整体偏基础八股和编码思路表达。
项目与经历
- 自我介绍。
- 介绍实习经历。
- 介绍项目经历。
- 打开笔试时代码,讲解实现思路。
建议:
项目介绍建议按“背景—职责—技术方案—难点—结果”展开,不要只罗列技术栈。机试代码讲解时,要说明题意理解、核心数据结构、复杂度和边界处理。
MySQL
- 多个人同时修改数据库会发生什么?
- 联合索引相关问题:给定几个索引场景,判断是否走索引,并说明原因。
参考思路:
多事务同时修改同一行数据时,MySQL 会通过事务和锁机制保证一致性。通常先获取锁的事务继续执行,其他事务等待;如果多个事务互相等待,就可能产生死锁,数据库会检测并回滚其中一个事务。
联合索引判断是否生效,核心看:
- 是否符合最左前缀原则。
- 是否跳过了联合索引的前导列。
- 是否对索引列使用函数、计算或隐式类型转换。
like是否以通配符开头。- 范围查询后面的索引列是否还能继续充分利用。
Java 并发
- 并发控制有哪几种方式?
synchronized和Lock的区别是什么?
参考思路:
并发控制可以从以下几类回答:
- 悲观锁:如
synchronized、ReentrantLock、数据库行锁。 - 乐观锁:如版本号机制、CAS。
- 线程安全容器:如
ConcurrentHashMap、CopyOnWriteArrayList。 - 读写锁:适合读多写少场景。
- 消息队列或串行化处理:将并发写转为顺序消费。
synchronized 是 JVM 内置锁,使用简单,会自动加锁和释放锁;Lock 是 JUC 提供的显式锁,需要手动释放,但能力更灵活,例如支持公平锁、可中断锁、超时获取锁、多个条件队列等。
Spring
- Spring 有哪些核心功能?
- 介绍 IOC。
- 手动
new的对象能不能交给 Spring 管理? - Bean 对象注入方式有哪些?
参考思路:
Spring 核心功能主要包括:
- IOC / DI:对象创建和依赖注入由容器管理。
- AOP:将日志、事务、权限等横切逻辑与业务逻辑解耦。
- 事务管理:统一管理数据库事务。
- MVC / Web 支持:用于构建 Web 应用。
- Bean 生命周期管理:负责 Bean 的创建、初始化、销毁等过程。
手动 new 出来的对象默认不归 Spring 容器管理,因此不能直接享受依赖注入、AOP、事务代理等能力。如果确实需要交给 Spring 管理,可以通过配置 Bean、组件扫描、@Bean 方法或手动注册到容器等方式实现。
Bean 注入方式包括:
- 构造器注入。
- Setter 注入。
- 字段注入。
- 方法参数注入。
实际开发中更推荐构造器注入,因为依赖关系更清晰,也更利于测试。
Redis / 消息队列
- Redis 可不可以当消息队列?
- 既然 Redis 可以做消息队列,为什么还要用 RabbitMQ?
- Redis 和 RabbitMQ 的本质区别是什么?
参考思路:
Redis 可以实现消息队列,例如通过 List、Pub/Sub、Stream 等方式实现。但 Redis 本质上是内存数据结构存储系统,更适合缓存、高性能数据结构和轻量消息场景。
RabbitMQ 是专业消息中间件,提供更完整的消息能力,例如:
- 消息确认机制。
- 持久化。
- 路由交换机。
- 重试机制。
- 死信队列。
- 消费者确认和流控。
因此,如果只是简单异步通知或轻量队列,Redis 可以胜任;如果业务对可靠性、路由、重试、削峰填谷和消息可追踪性要求更高,更适合使用 RabbitMQ。
数据结构
- 是否用过双向链表?
- 双向链表和单向链表在插入、删除上的效率有什么区别?
参考思路:
单向链表每个节点只有 next 指针,结构简单、空间占用更少;双向链表有 prev 和 next 指针,可以同时访问前驱和后继。
如果已经定位到目标节点,二者插入和删除都可以做到 O(1)。但双向链表在删除当前节点时更方便,因为可以直接找到前驱节点;单向链表如果不知道前驱节点,需要从头遍历寻找前驱,时间复杂度可能变为 O(n)。
JVM / 内存排查
- 是否遇到过内存问题?
- 如何排查?
- 用过什么工具?
- 了解虚拟线程和协程吗?是否使用过?
参考思路:
内存问题可以按“现象—定位—分析—解决”回答:
- 现象:
OOM、频繁 Full GC、接口变慢、内存持续上涨。 - 定位:查看 GC 日志、监控指标、堆内存快照和线程情况。
- 工具:
jstat、jmap、jstack、Arthas、MAT、VisualVM。 - 分析:检查大对象、无界缓存、集合持续累积、线程数异常、连接未释放等。
- 解决:限制缓存大小、修复对象引用、分页处理大数据、优化对象生命周期。
虚拟线程可以说明是 Java 为高并发 I/O 场景提供的轻量级线程模型;协程是更广义的轻量级并发模型。如果没有实际使用过,可以如实说明了解概念,但生产项目中暂未落地。
手撕算法
题目描述:
- 长度为
n的数组。 - 每次可以把
m个连续且相同的数替换为它们的和。 - 替换后的数继续放回原数组,可能继续触发合并。
- 重复该过程,直到数组中不存在
m个连续相同的数。 - 输出最终数组。
五、技术二面
技术二面相比一面更偏 项目深挖、数据库优化、并发容器、性能优化、JVM、AI 工具使用、算法题,更关注候选人是否真的做过项目,以及能否把技术方案讲清楚。
项目与实习深挖
- 自我介绍。
- 介绍实习经历。
- 介绍项目经历。
- 结合实习,讲一下你在数据库表设计或优化上提升性能的经验。
- 简历内容基本问完后,是否还有需要补充的重点?
建议:
二面项目追问会更细,需要提前准备 2-3 个项目亮点,例如:
- 慢 SQL 优化。
- 缓存设计。
- 秒杀业务优化。
- 接口响应时间优化。
- 数据库表结构优化。
- 高并发场景下的数据一致性处理。
每个亮点建议按这个结构准备:
- 背景:为什么要优化?
- 问题:原来有什么瓶颈?
- 定位:通过什么工具或指标发现?
- 方案:具体怎么改?
- 结果:性能提升了多少,或者稳定性改善在哪里?
数据库优化
- 如果项目中的 SQL 非常多、非常杂,怎么判断里面是否有语句影响性能或存在优化空间?
- 数据库表设计或优化方面,如何提升性能?
参考思路:
可以从以下几个角度回答:
- 开启慢 SQL 日志,筛选执行时间长、扫描行数多、执行频率高的 SQL。
- 使用
EXPLAIN分析执行计划,重点看索引使用、扫描行数、连接类型、是否出现Using filesort、Using temporary。 - 结合业务链路监控,定位接口耗时高的 SQL。
- 对高频 SQL 建立合适索引,避免索引缺失或冗余索引。
- 优化 SQL 写法,避免
select *、函数操作索引列、隐式类型转换、大分页。 - 对大表考虑分库分表、冷热数据分离、归档历史数据。
- 对读多写少场景使用缓存,但要注意一致性和过期策略。
表设计优化可以补充:
- 字段类型尽量小而合适。
- 高频查询字段建立索引。
- 控制单表字段数量和行大小。
- 合理设计主键,避免过长主键。
- 根据业务查询模型设计表结构,而不是只追求范式。
Java 并发与集合
- 如果有一个
ArrayList资源,一般如何保证线程安全? - 讲一下
ConcurrentHashMap。 - 平时如何使用
synchronized?锁实例还是锁类?
参考思路:
如果要保证 ArrayList 线程安全,可以根据场景选择:
- 使用
Collections.synchronizedList()包装。 - 使用
CopyOnWriteArrayList,适合读多写少。 - 使用局部变量,避免共享可变状态。
- 使用并发容器替代原容器。
- 必要时用锁保护临界区。
注意:面试中不要第一反应只说“加锁”,可以先从数据结构和场景选择角度回答。
ConcurrentHashMap 可以这样回答:
- JDK 1.8 中主要基于数组 + 链表 + 红黑树。
- 通过 CAS +
synchronized控制并发更新。 - 读操作大多不加锁,依赖
volatile保证可见性。 - 写操作只锁定局部桶节点,降低锁粒度。
- 链表长度达到阈值且数组容量满足条件时,会转为红黑树,优化查询性能。
synchronized 使用时要注意锁对象选择:
- 锁实例对象:只保护当前对象实例的共享资源。
- 锁类对象:保护类级别共享资源,影响范围更大。
- 锁私有对象:更推荐,避免外部代码误用同一个锁。
- 不建议锁字符串常量、包装类常量等可能被共享的对象。
性能优化
- 你做过很多性能优化,是怎么判断这些地方需要优化的?
- 具体怎么优化的?
- 能结合秒杀业务讲几个例子吗?
参考思路:
性能优化不要直接说“我加了缓存、加了索引”,而要按完整链路回答:
- 通过监控、日志、压测、慢 SQL、链路追踪发现瓶颈。
- 判断瓶颈属于数据库、缓存、网络、CPU、锁竞争还是外部接口。
- 针对瓶颈选择方案,而不是盲目优化。
- 优化后用数据验证结果。
秒杀业务可以从以下角度展开:
- 使用 Redis 预扣库存,减少数据库压力。
- 使用消息队列异步下单,削峰填谷。
- 使用限流、验证码、风控拦截异常流量。
- 使用分布式锁或 Lua 脚本保证库存扣减原子性。
- 使用唯一索引或幂等表防止重复下单。
- 热点商品信息提前缓存,减少数据库查询。
JVM
- 了解 JVM 吗?
- 能不能讲一下 G1 垃圾回收过程?
参考思路:
G1 的核心特点是将堆划分为多个大小相等的 Region,不再简单按连续的新生代、老年代物理空间划分。它的目标是在可预测停顿时间内,优先回收收益最高的 Region。
G1 回收过程可以这样答:
- 初始标记:标记 GC Roots 直接关联的对象,会 STW。
- 并发标记:从 GC Roots 开始进行可达性分析,与用户线程并发执行。
- 最终标记:修正并发标记期间变化的引用关系,会 STW。
- 筛选回收:根据 Region 的垃圾比例和回收收益,选择部分 Region 进行回收。
- 混合回收:不仅回收年轻代,也会回收部分老年代 Region。
可以补充:G1 适合大堆内存、对停顿时间有要求的服务端应用。
AI 工具使用
- 使用过哪些 AI 工具?
- 如何让 AI 工具更好地帮助你?
参考思路:
可以回答使用过 ChatGPT、通义、文心、Copilot 等工具,主要用于:
- 辅助理解陌生代码。
- 生成单元测试样例。
- 梳理技术方案。
- 排查报错原因。
- 优化文档和接口说明。
- 辅助学习新技术。
但要强调不会完全依赖 AI:
- 关键代码和结论需要自己验证。
- 涉及业务逻辑、数据安全和线上变更时必须人工确认。
- 提问时要提供清晰上下文、约束条件、目标格式和已有尝试。
- 把 AI 当作效率工具,而不是替代工程判断。
手撕算法
技术二面的算法题为建图 + DFS 遍历,题目整体不复杂。
准备建议:
重点掌握以下内容:
- 邻接表建图。
- DFS 递归写法。
- DFS 非递归栈写法。
visited数组防止重复访问。- 连通分量、路径搜索、拓扑相关基础题型。
六、整体感受
整体来看,这次华为 OD Java 面试流程比较完整,技术面覆盖面较广,但问题并不特别偏,主要集中在 Java 后端常见基础和项目真实性考察。
一面更偏基础八股和编码思路,包括 MySQL、并发、Spring、Redis、JVM、数据结构和机试代码讲解;二面更偏项目深挖和实际工程能力,尤其关注数据库优化、性能优化、并发容器、秒杀业务和问题定位能力。
建议:
- 机试代码一定要能讲清楚,面试中可能会直接打开笔试代码追问。
- Java 基础八股要准备扎实,尤其是 MySQL 索引、并发、Spring、Redis、JVM。
- 项目不能只背技术栈,要准备真实问题、解决方案和结果数据。
- HR 面要重视稳定性表达,尤其是城市选择、加班态度和 OD 认知。
- 对性能优化类问题,要重点体现“发现问题—定位问题—解决问题—验证结果”的闭环思维。

更多推荐
所有评论(0)