中国太平太平金科软件开发专业面试

《面试题目》

1. 简单做一下自我介绍。
2. 如果你的角色是技术经理，给你任务并要求最终交付上线，完全通过 Agent 协作开发一个简单小软件，你会怎么做？
3. 在已有系统 / 软件上做信创替代（Oracle 换高斯、JDK 替换、Tomcat 换成宝兰德等），和上面用 Agent 开发新软件的流程相比，编排思路上有什么差别？
4. 私有化部署大模型，从千问 3.0 升级到 3.8，原有知识库需要保留，如何增量更新知识？
5. 谈谈你对当前大模型应用以及未来发展的理解。
6. 怎么通过 skill 或者知识库减少大模型幻觉，如何判定最终交付结果？
7. 初级人员使用高级人员编写好的 skill，人工复核时无法判断结果好坏，该怎么解决？
8. 简单说一下你对面向对象编程的理解。
9. final、finally、finalize 有什么区别？
10. 所有异常处理都需要 finally 吗？举几个必须使用 finally 的场景。
11. 异常的种类有哪些？举几个常见异常。
12. 所有异常都需要 throw 抛出吗？程序设计中如何判断哪些异常需要抛出？
13. 你会自定义异常类型吗？
14. HashMap 和 Hashtable 有什么区别？
15. 方法上加 synchronized 关键字上锁之后，其他线程还能进来吗？
16. 讲一下 GC。
17. 线程和进程有什么区别？
18. 口述单例模式。
19. 反射的基本原理。
20. 消息中间件用过哪些？RocketMQ 用过吗？
21. RabbitMQ 主要用来做什么？
22. Redis 过期键，过期之后内存上是立即清理掉了吗？
23. 有没有遇到过缓存雪崩？什么场景，怎么处理？
24. 数据库用过哪些？高斯、OceanBase 这类国产数据库有没有用过？
25. PostgreSQL 和 MySQL 差别在哪？
26. 保险业务场景：柜面加互联网、小额巨量保单、每日几百万数据、对接外部平台、交易需要实时性、后管有综合查询偏 AP，选 MySQL 还是 PG？
27. 分库分表之后，跨分片综合查询聚合开销大，如何优化？
28. 你有什么想要了解的？
29. 你是哪里人，考虑来深圳还是武汉？
30. 你后续的职业规划和发展方向是什么？

《参考解析》

信创替代与 Agent 新开发的编排差别

两者最大的区别是「约束条件」而不是「工具」。从零开发只需要考虑功能正确，编排上按需求、设计、编码、测试的顺序拆给不同角色即可；信创替代是在一个已经运行、有人依赖的系统上做外科手术，编排里必须多出几步：先做依赖与兼容性盘点（哪些 jar 绑定了 Oracle 方言、哪些 API 是 JDK 私有实现、容器与中间件的配置差异），再建立可回滚的迁移路径（双跑对账、灰度切流、随时能退回旧栈），最后把回归验证做成硬门槛。换句话说，新开发优化的是速度，替代项目优化的是「不出事且能回退」，验证成本远高于编码成本。

私有化知识库怎么增量更新

换基座模型不等于要重建知识库——知识库和模型是两层。要重做的是与模型强相关的切片：embedding 模型如果跟着升级，向量维度和语义空间都变了，历史向量必须全量重算，这一步无法增量；如果 embedding 不变，增量更新只需要处理新增与变更的文档，按文档 ID 与内容哈希判断是否重切，删除的文档同步删掉向量。工程上建议把「原文 → 切片 → 向量」做成幂等流水线，用文档版本号驱动，避免每次升级都靠人工比对。

怎么减少幻觉、怎么判定交付结果

减少幻觉最有效的顺序是：先保证检索能拿到正确的原文（混合检索加重排、切片与查询改写），再约束生成（要求只依据给定材料、逐句给出处、材料里没有就说不知道），最后才是模型选择与参数。判定交付不能靠「读起来像对的」，要给出可核对的依据：答案里的每个结论能否指回具体文档与段落，关键字段是否与源文档逐字一致，数值与日期做规则校验。批量场景下抽样人工复核加自动化一致性检查，比逐条人工读更现实。

异常处理与 finally

finally 的语义是「无论是否抛异常都要执行的清理块」，典型必须用的场景是关闭文件流/数据库连接/socket、释放锁、回滚未提交的事务、还原 ThreadLocal 或全局状态。但 finally 不是万能的：如果 finally 里也抛异常，会覆盖掉原始异常；finally 里写 return 会吞掉异常和返回值，这两点经常被追问。判断一个异常该不该抛，标准是「当前层有没有能力处理它」——能补偿（重试、降级、换默认值）就地处理，不能就往上传，别把 catch 写成只打一行日志的摆设；业务异常自定义成受检或非受检取决于调用方是否必须显式处理，多数团队会让业务异常继承 RuntimeException 以免污染签名。

Redis 过期键是怎么清理的

不是到期瞬间删除，而是「惰性删除 + 定时抽样删除」的组合：访问一个键时先判断是否过期，过期就删并返回空；同时有个定时任务每轮随机抽一批设置了过期时间的键，删掉其中已过期的，如果过期比例超过阈值就继续抽，用这种方式把内存占用控制在可接受范围。因此会出现「键已经逻辑过期但内存还占着」的情况，内存紧张时还要配合 maxmemory 的淘汰策略（LRU/LFU/random 等）兜底。追问常到这里：主从和集群里过期删除各自独立进行，从库不会主动删，只等主库的删除命令同步过来。

缓存雪崩、穿透与击穿

雪崩是大量键在同一时间失效（常见原因是统一设了相同的过期时间，或缓存层整体重启），流量瞬间全打到数据库。处置上：过期时间加随机抖动、热点数据逻辑过期加异步刷新、多级缓存、以及入口处的限流与降级。要顺带区分相近的两个概念——穿透是查一个数据库里也不存在的键，靠布隆过滤器或空值缓存挡住；击穿是单个热点键失效，靠互斥锁或单飞（singleflight）让一个请求去回源、其余等待。回答时按「现象 → 根因 → 处置」讲，并说清各自适用的场景差异。

小额巨量保单场景选 MySQL 还是 PG

先把负载拆开看：交易侧是高频小事务、写多读少、要求低延迟，这部分 MySQL 和 PG 都能胜任，MySQL 在互联网侧运维工具和分库分表中间件生态更成熟；难点在「后管综合查询偏 AP」这一侧——多条件组合、跨表聚合、报表统计，MySQL 在复杂查询优化、并行扫描、丰富的索引类型（GIN/GiST、部分索引、表达式索引）和物化视图上明显弱于 PG。所以更合理的答案不是二选一，而是按读写分离或分链路落库：交易用擅长的库保证写入，分析侧用 PG 或专用 OLAP 承接，中间通过 binlog/CDC 同步，避免用一套库同时扛两种完全不同的负载。如果只能选一套，倾向 PG，因为它能同时兼顾事务与复杂查询，代价是团队要接受运维与人才储备上的迁移成本。

分库分表后的跨分片查询怎么优化

跨分片聚合慢的根因是每个分片都要返回大量明细再在中间层合并。可用的手段按优先级排：① 尽量把查询改造成能带上分片键，让请求路由到单分片；② 把需要频繁多维查询的字段冗余到一张按查询维度分片的「查询表」或宽表，牺牲写入一致性换查询效率；③ 把明细同步到 OLAP/ES 承接复杂检索与聚合，分片库只负责事务；④ 中间件侧做并行查询与流式归并，减少内存压力；⑤ 业务上限制查询范围（时间窗口、必选条件），避免全分片扫描。落地时要注意数据一致性与延迟，把「允许多大延迟」作为选型的前提。