恒生电子二面：性能优化真伪、OOM 排查与 AI 代码责任

《面试题目》

1. 请先简单介绍一下自己，重点说说学习经历和项目经验。
2. 在滴滴是做 Java 吗？实习结束后那边有沟通吗？会继续留在滴滴吗？
3. 数据资产批量查询从 1.5 秒优化到 265 毫秒，是给你一个问题让你尝试，还是优化后真的上了生产？实习生写的代码也能上生产？这是核心功能吗？
4. 数据资产具体指什么？这算是系统之外的查询功能吗？不改变系统服务内核？
5. 那性能提升是怎么做到的？
6. 你还有 OOM / GC 问题的处理经验？如果生产上真出现 OOM / GC，一般怎么定位？是什么原因导致的？整体排查思路是什么？
7. 最近有用 AI 辅助做这些事情吗？如果用编程工具辅助开发，怎么保证 AI 生成代码的质量？最终上生产责任在谁？
8. 如果脱离这些代码，AI 写的代码出了问题，怎么快速定位？怎么保证人对代码的熟悉程度？
9. 这是你日常的思考，还是现在临时想觉得应该这样做？
10. 有通过 AI 了解过恒生吗？觉得恒生电子是一家怎样的公司？金融开发方面还有其他了解吗？
11. 你是天津人，会考虑杭州的发展吗？家里不反对吗？有在谈恋爱吗？
12. 现在手上有 offer 吗？现在在面哪些公司？比较中意哪些公司？恒生哪些方面吸引你来面试？还是只把它当作池子里的一个选项？
13. 为什么觉得金融业的态势会比较好？基于哪些信息让你有信心？
14. 期望薪资是多少？

《参考解析》

「优化真的上生产了吗」：把真实性证据准备好

这类追问的意图很明确——核实数字是真实成绩还是练习环境的结果。回答要给证据链，而不是重复数字。准备四个要点：一是环境（哪个服务、多少数据量、线上还是预发）；二是做之前和做之后的指标口径（1.5 秒是 P99 还是平均、在什么并发与数据量下测的）；三是改动的具体内容（比如把 N+1 查询合并、增加联合索引、把逐条远程调用改成批量接口、加缓存或改分页策略）；四是上线方式与验证（灰度发布、观察了多久、有没有回滚）。如果只是实验性优化没上线，就如实说是「在预发环境验证性能提升，没有上线，但方案经过了评审」，同时说清为什么没上线（排期、风险、依赖未就绪）——诚实加上对约束的理解，远比含糊其辞安全。

「实习生代码能上生产吗、是核心功能吗」要正面回答协作现实：实习生提交的代码一定经过 review 与测试才可能合入，能独立负责的通常是旁路能力（报表、内部工具、查询接口），核心交易链路由正式员工把关。把这层说清楚，同时给出你自己代码的质量证据（单测、压测数据、评审意见），比强调「我一个人做的」更有说服力。

OOM 与 GC 的排查：思路要能落到工具与命令

答题结构建议按「确认现象 → 区分类型 → 定位对象 → 处理与预防」四步走。确认现象要看监控与日志：是 OutOfMemoryError: Java heap space、GC overhead limit exceeded、Metaspace、还是 unable to create new native thread/直接内存溢出，不同后缀的病因完全不同；同时看 GC 日志的频率与耗时、老年代占用是否回收后仍不下降。

定位阶段先用 jstat -gcutil 看各分区占用与 GC 次数，jmap -histo:live 看对象直方图找异常增长的类型，jmap -dump 或 -XX:+HeapDumpOnOutOfMemoryError 拿堆快照后用 MAT 看支配树（Dominator Tree）与「Leak Suspects」，重点看是谁持有引用、为什么没释放。如果是 CPU 也高，用 top -Hp 找到线程、jstack 打出栈，把 nid 转 16 进制对应到具体线程。要能区分「内存泄漏」（对象该回收却被引用链挂住，表现为每次 Full GC 后老年代水位持续抬升）与「内存不够」（对象生命周期本来就长，扩大堆或换更省内存的数据结构即可）。常见根因可以报一串：无界缓存或静态集合只放不取、ThreadLocal 未清理、连接/流未关闭、一次查询拉全表、字符串拼接产生大量临时对象、线程池队列无界堆积任务、元空间里动态生成类（反射/代理/脚本引擎）过多、堆外内存没算进堆导致「堆还宽裕进程却被 OOM Killer 杀掉」。

预防上要讲工程手段：设置 -Xmx 与容器限制匹配（JVM 在容器里要显式设堆，否则可能按宿主机内存算）、打开 GC 日志并做告警、对缓存设上限与过期、对批量接口限制单次规模、上线前压测。答题时如果能顺口说出「先看是哪种 OOM、再看老年代回收后的水位」，面试官就知道你不是背概念。

AI 辅助编码的质量与责任

这一组问题考的是工程纪律。质量保证可以分四层讲：一是让 AI 先给方案与影响面（改哪些文件、有哪些假设），人 review 方案再让它动手，把「想」和「写」分开；二是把产出放进既有闸门——代码评审、类型检查、单测与边界用例、静态扫描，这些闸门本来就该拦住所有代码，不因为是人写的还是 AI 写的而放宽；三是小步提交、可回滚，避免一次生成几百行无法 review 的 diff；四是要求它标出不确定的地方，对拿不准的 API 与行为一定去文档或实验验证，而不是接受看起来合理的解释。

「责任在谁」的答案不复杂：在提交者与评审者。可以用代码提交记录与评审人作为责任链，AI 不承担任何责任——这也是为什么不能因为「AI 写的」就跳过评审。至于「脱离这段代码、AI 生成的代码出问题怎么快速定位」，正好接上一条：可定位性来自工程习惯而不是对代码的记忆——有 traceId 与结构化日志、有单测覆盖关键分支、改动小且提交粒度清晰、有监控指标。面试官问「这是你日常的思考还是临时想的」时，最有效的回答是一个真实的小例子：比如你在项目里定的规则是「AI 生成的代码必须能通过既有测试、且每个不确定点写成注释待确认」，并说说这条规则拦下过什么。

杭州、金融行业与 HR 类问题

异地发展的顾虑（天津人、家里是否反对、感情状况）属于所有金融/国企类公司的必问项，回答要给一个稳定的判断，不要含糊——「考虑杭州，离家远但家里支持，自己也更看重行业发展」这类表达就够；被问到私人问题可以简短带过，不必展开。Offer 与在面公司如实回答，不用隐瞒；被问「是不是只把它当池子里的一个选项」时，别撒谎说「只投了你们」，可以说清自己的选择标准（业务方向、技术积累、城市），并说明恒生在你选择里的具体位置与理由。「为什么觉得金融业态势好」需要准备可查的依据：券商与基金的核心系统国产化替代、金融 IT 投入占营收比例长期较高、监管推动的信创与分布式改造、以及财富管理规模增长带来的系统需求；把它落到恒生所处的赛道（券商核心交易、金融数字化）上，比泛泛谈「金融稳定」好得多。期望薪资给一个基于调研的区间并说明构成（base、年终、签字费），可以补一句更看重的是岗位成长与业务方向，但不要用这句话代替数字。