2025年恒生电子面试经验面试题及答案.docxVIP

2025年恒生电子面试经验面试题及答案

技术一面（40分钟，后端开发岗，面试官为30岁左右的Java工程师）

Q1：聊聊你项目中用SpringBoot做过的性能优化，具体遇到了什么问题？怎么定位的？

A：我负责过一个金融数据聚合平台的后端开发，初期用户反馈查询持仓数据接口响应时间偶尔超过2秒（SLA要求1.5秒）。首先用Arthas监控接口调用，发现慢调用集中在非交易时间的早盘前查询（7:30-8:30）。进一步分析SQL日志，发现查询条件中“account_id+update_time”的联合索引未覆盖，导致全表扫描；同时，Redis缓存的失效策略是默认的LRU，但该接口的查询参数(account_id,product_type)组合有明显的热点特征（前20%的用户贡献80%的查询）。优化分三步：①给DB添加(account_id,product_type,update_time)的复合索引，将查询时间从800ms降到120ms；②调整Redis缓存策略为按(account_id,product_type)分组的固定过期时间（交易时间30秒，非交易时间5分钟），并引入本地Caffeine缓存做二级缓存，热点数据本地命中后避免访问Redis；③在网关层对重复请求做3秒内的去重，减少15%的无效调用。优化后接口P99从1.8秒降到800ms，错误率从0.3%降到0.05%。

Q2：JVM内存模型中，元空间和永久代的区别？如果线上应用出现MetaSpace内存溢出，你会怎么排查？

A：元空间（MetaSpace）是JDK8及以上替代永久代（PermGen）的内存区域，主要区别在于：①存储位置：永久代在JVM堆内，受MaxPermSize限制；元空间在本地内存（NativeMemory），默认无固定上限（但受系统内存限制）；②存储内容：永久代存类元数据、常量池、静态变量；元空间存类元数据（Klass、Method、Field等），字符串常量池和静态变量移至堆；③GC策略：永久代GC由CMS负责，容易触发FullGC；元空间由类加载器生命周期管理，无用类加载器卸载时回收。

排查MetaSpace溢出步骤：①用jstat-gcutilPID1000查看GC情况，若YGC频繁但MetaSpace使用持续增长，可能是类加载过多未卸载；②用jmap-clstatsPID查看存活类加载器及加载的类数量，定位是否有自定义类加载器未正确释放（比如动态编译的金融策略脚本加载器）；③检查Arthas的ognl表达式`@sun.reflect.generics.factory.GenericsFactory@getCacheSize()`，确认泛型元数据是否过度缓存；④结合应用日志，看是否有动态提供类的场景（如使用CGLIB代理金融交易规则、ASM提供策略类），若有则检查类加载器是否被容器正确管理（如Spring的DefaultListableBeanFactory是否及时销毁）；⑤若上述无异常，可能是JVM参数配置过小，可通过-XX:MaxMetaSpaceSize调整（一般建议设置为系统内存的1/4，比如16G内存设4G）。

Q3：设计一个分布式锁，用于金融交易系统的订单防重，需要考虑哪些关键点？

A：核心要解决“正确性”和“性能”的平衡，金融场景对并发冲突容忍度极低（比如同一用户同一时间提交两笔相同订单）。关键点包括：

①互斥性：同一时刻仅一个客户端持有锁，需避免Redis主从切换时的锁丢失（可参考Redlock算法，但实际中更常用Redisson的MultiLock，或使用ZooKeeper的顺序节点实现）；

②超时机制：锁必须有过期时间（如30秒），防止客户端崩溃后锁无法释放，但需考虑业务执行时间超过锁过期的情况（可通过守护线程自动续期，如Redisson的WatchDog机制）；

③可重入性：同一客户端同一线程可多次获取同一锁（比如订单接口调用内部服务时需再次加锁），需记录线程ID和重入次数；

④防误删：释放锁时需校验当前客户端是否持有锁（通过Lua脚本比较锁的value是否为客户端ID），避免A释放了B的锁（比如A的锁过期后B获取锁，此时A完成业务后错误释放B的锁）；

⑤性能：金融交易峰值（如早盘集合竞价）QPS可能达10万+，需减少锁粒度（按用户ID或订单ID分片），避免全局锁；同时锁的获取/释放操作需低延迟（Redis的单线程命令、ZooKeeper的顺序节点监听）；

⑥高可用：锁服务需集群部署，避免单点故障（Redis的哨兵模式、ZooKeeper的集群）。

技术二面（50分钟，高级技术专家，侧重系统设计和金融业务结合）

Q1：假设要开发一套券商的智能