1. 这轮面试在考什么
这轮派安盈一面的题目比上一轮更贴近“资金系统核心能力”，面试官想验证的不是你会不会说支付流程，而是你是否真的理解资金在系统里的流转和一致性控制。核心在看三件事：
- 你对多币种账户、换汇、余额、虚拟账户这些资金域概念是不是有实战理解。
- 你是否能把支付防重、防并发、防重复扣款讲清楚，而不是只说一句“加锁”。
- 你对 Java 并发和数据库底层是否有扎实基础，尤其是 OOM、MVCC、事务、慢 SQL、海量数据治理这些高频题。
2. 支付资金域怎么答
你们项目换汇有没有限时锁汇
建议口径：如果是比较成熟的多币种资金系统，换汇通常会有“报价有效期”或者“限时锁汇”机制。原因是汇率是波动的，不能让用户拿着一个很早的报价无限期成交。常见做法是生成一条带有效期的 quote，里面包含源币种、目标币种、汇率、手续费、过期时间。用户在有效期内确认，就按这条报价执行；超过有效期就重新报价。
项目结合点：如果你们项目没有做成完整的 lock rate，也可以诚实说当前更偏“下单时取汇率 / 入账时按当时汇率换算”，但从设计上讲，限时锁汇更适合面向客户可见的换汇产品，因为它能避免汇率窗口期带来的争议。
有没有了解过虚拟账户
建议口径：虚拟账户本质上是“面向客户展示的收款标识”，不是一定对应一张真实银行账户。它的价值在于资金归集和识别归属，比如给不同商户、不同用户、不同订单分配不同虚拟账号，入金后系统根据虚拟账号把钱自动归集到对应客户或主账户。
项目结合点：如果结合多币种收款账户场景，可以说虚拟账户适合做本地收款、跨境入金识别、对账归属、资金归集。它的重点不是“开很多银行户”，而是“让系统能自动知道这笔钱属于谁”。
换汇的时候余额不够怎么做
建议口径：余额不够时，系统核心不是直接报错，而是先判断是哪一层余额不够。通常要区分：
- 账户总余额不够：直接拒绝换汇申请。
- 可用余额不够但总余额够：说明有冻结资金，不能直接占用，要提示资金不可用。
- 单币种余额不够：如果支持自动补足，可以走先购汇再换汇；不支持就直接失败。
项目结合点：如果放在你们项目里，换汇前应该先校验 `available balance`，通过后先冻结或预扣源币种余额，再执行换汇，成功后减少源币种、增加目标币种；失败则回滚冻结。这样能避免并发下超卖余额。
换汇余额这块是怎么变动的
建议口径：换汇本质上是两边账同时变：源币种减少，目标币种增加，中间还可能有手续费和汇差。一个比较标准的流程是：
- 校验源币种可用余额。
- 冻结或预扣源币种金额。
- 根据汇率计算目标币种应入账金额。
- 扣减源币种余额，增加目标币种余额。
- 如果有手续费，单独记一笔 fee ledger。
- 整笔操作记录资金流水，保证可审计。
面试表达：你可以强调换汇不是“改两个余额字段”，而是一次标准账务处理，必须有冻结、流水、审计和失败回滚。
怎么防止一笔订单重复支付
建议口径：防止重复支付不能只靠前端按钮置灰，后端至少要做四层：
- 业务单号唯一：同一个 merchantOrderNo 在业务上只能对应一笔有效支付。
- 幂等键控制：比如 `merchantId + orderNo + actionType` 做幂等校验。
- 状态机校验：订单已经成功、处理中、已关闭时不能重复发起。
- 数据库唯一约束或 Redis 锁：防止并发重复落单。
项目结合点：支付系统里真正稳的是“业务幂等 + 状态机 + 数据库唯一约束”，Redis 锁只是第一层快互斥，不能单独作为最终防重保证。
3. Java 并发和内存怎么答
线上出现 OOM，排查思路是什么
建议口径：OOM 排查我会先分类型，再看现场。先确认是堆内存溢出、Metaspace、直接内存还是线程数过多导致的内存问题。然后按“三步走”：
- 看监控：内存曲线、GC 次数、GC 停顿时间、线程数、流量变化。
- 看现场：导出 heap dump，用 MAT 或 Arthas 看大对象、集合、缓存、消息积压。
- 看根因：是缓存没淘汰、MQ 积压、批任务加载过大、代码持有对象没释放，还是线程泄漏。
项目结合点：支付系统里常见的 OOM 根因往往是大批量对账、导出报表、消息积压、或者本地缓存失控，而不是单纯 JVM 参数配小了。
synchronized 和 Lock 讲一下
建议口径：synchronized 是 JVM 层面的内置锁，语法简单、自动释放，适合临界区简单、范围清晰的场景。Lock 是 JUC 提供的显式锁，像 ReentrantLock，优点是可以手动控制加解锁、支持可中断、超时、公平锁和条件队列。
怎么区分讲：如果只是简单同步块，我会优先用 synchronized；如果要可中断加锁、定时尝试获取锁、多个条件队列或更灵活控制，我会用 Lock。
ThreadLocal 讲一下，以及会出现什么问题
建议口径：ThreadLocal 不是给线程加锁，而是给“每个线程一份独立副本”，常用于保存用户上下文、TraceId、数据库路由上下文这类线程隔离数据。
典型问题：
- 线程池复用场景下忘记清理，会出现脏数据串线程。
- value 强引用、key 弱引用，长期不清理会导致内存泄漏风险。
- 异步线程切换后上下文丢失，不能天然跨线程传递。
面试表达：ThreadLocal 重点不是“会用”，而是你知道它在线程池场景下一定要 remove()。
HashMap 和 ConcurrentHashMap 区别是什么
建议口径：HashMap 是非线程安全的，多线程并发读写会有数据覆盖、结构不一致等问题；ConcurrentHashMap 是线程安全的，JDK 8 以后主要通过 CAS + synchronized + 分段思想优化并发更新，读性能和并发性能都比 Hashtable 更好。
怎么落回项目：像支付配置缓存、本地规则缓存，如果是多线程共享访问，就不能随便用 HashMap，需要至少用 ConcurrentHashMap 或成熟缓存组件。
4. 数据库底层和治理怎么答
MVCC 实现原理讲一下
建议口径：MVCC 的核心是“读不加锁也能看到一致性快照”。以 InnoDB 为例，它依赖三部分：
- 每行数据的隐藏字段，比如事务 ID、回滚指针。
- undo log，用来形成历史版本链。
- Read View，用来判断当前事务能看到哪个版本。
所以普通快照读会根据 Read View 沿着版本链找一个当前事务可见的版本，而不是总读最新值。
怎么排查慢 SQL
建议口径：慢 SQL 排查我会从“现象、SQL、本质、治理”四层看：
- 先从监控或慢 SQL 日志里定位是哪条 SQL 慢。
- 再用
EXPLAIN看执行计划，确认是否走索引、是否回表、是否排序、是否临时表。 - 再看本质原因，是索引设计不合理、where 条件不命中、数据量太大、join 太重，还是分页方式有问题。
- 最后再决定是补索引、改 SQL、拆查询、冷热分离还是分库分表。
数据库事务这块讲一下
建议口径：事务核心是 ACID：原子性、一致性、隔离性、持久性。面试里我会重点讲隔离级别和实际业务使用。像 InnoDB 常见隔离级别有读未提交、读已提交、可重复读、串行化，MySQL 默认是可重复读。
项目结合点：支付系统里事务重点不只是背定义，而是明确“本地事务保护单服务内落库一致性，跨服务一致性靠 MQ、补偿和幂等”，不要把分布式一致性问题都寄托给数据库事务。
数据库表上亿行，查询很慢怎么办
建议口径：我会按治理层次来做，而不是一上来就说分库分表：
- 先看索引和 SQL 是否合理。
- 做冷热分离、历史归档，把热点数据和历史数据拆开。
- 高频查询做汇总表、宽表或搜索侧索引。
- 实在单表扛不住，再做水平分表或分库。
如果冷热库做了还是很慢，还有没有别的方案
建议口径：有，说明问题不只是冷热，而是查询模式本身不适合继续打 OLTP 主库。可以继续往下做：
- 针对查询场景单独建汇总表、明细索引表。
- 把复杂查询转到 OLAP、ES、ClickHouse、报表库等分析侧。
- 分页从 offset 改成基于游标或主键翻页。
- 把实时查询改成异步生成结果或离线报表。
面试表达：如果冷热分离后还慢，说明要重新审视“数据组织方式”和“查询架构”，不一定只是继续切表。
5. 这轮题你应该怎么讲得更像做过项目
这一轮不要只答知识点，建议用下面这个顺序串起来：
- 先讲你做的是多币种收款 / 资金处理相关系统，所以你会先从余额、换汇、重复支付防重去回答。
- 再讲技术层怎么兜底：幂等、状态机、数据库唯一约束、冻结余额、账务流水。
- 最后补基础设施：OOM、锁、ThreadLocal、MVCC、慢 SQL 和事务治理。
这样面试官听起来会更像“你真的做过这类系统”，而不是单独刷了几个面试题。
6. 这轮最值得补 demo 的点
- 换汇 demo：源币种冻结、换汇成功、失败回滚、手续费流水。
- 重复支付防重 demo：幂等键 + 状态机 + 数据库唯一约束。
- ThreadLocal demo：线程池复用导致脏数据，配合 remove 修复。
- 慢 SQL demo：同一张大表下，对比无索引、错误分页、优化索引后的执行计划变化。