java银行面试题目及答案

java银行面试题目及答案一、单项选择题（共10题，每题2分，共20分）1.银行核心交易系统中，转账业务要求两个账户的增减操作必须同时成功或同时失败，这对应事务的哪一特性？（）A.原子性B.一致性C.隔离性D.持久性答案：A。解析：原子性指事务是不可分割的最小执行单元，所有操作要么全部执行成功，要么全部失败回滚，转账的两个账户操作完全符合原子性要求；一致性是指事务执行前后数据始终处于合法状态（如转账前后总余额不变），是原子性、隔离性、持久性共同作用的结果；隔离性是指多个事务并发执行时互不干扰；持久性是指事务提交后对数据的修改永久生效。2.银行核心系统频繁出现FullGC卡顿，以下哪个原因最不可能导致该问题？（）A.大对象未及时释放B.元空间内存设置过小C.新生代Eden区设置过大D.内存泄漏答案：C。解析：Eden区设置过大会减少MinorGC频率，对象进入老年代的概率降低，反而会降低FullGC的触发概率；大对象直接进入老年代、元空间不足触发FullGC、内存泄漏导致老年代占比持续升高都是FullGC频繁的常见诱因，银行核心系统通常会拆分大对象、配置256M以上元空间避免该问题。3.银行分布式核心交易场景要求高可用、强一致，以下哪种分布式锁实现最适合？（）A.Redis红锁B.Zookeeper临时有序节点C.数据库排他锁D.本地锁答案：B。解析：Zookeeper基于CP架构，天然保证强一致性，临时有序节点实现的分布式锁不存在锁过期、主从同步不一致问题，适合银行核心资金交易对一致性的高要求；Redis红锁是AP架构，极端情况下会出现锁丢失问题，不适合核心交易；数据库排他锁性能差、易出现死锁，仅适合低并发场景；本地锁无法满足分布式集群部署需求。4.银行多线程处理批量代发业务（IO密集型），以下哪个线程池参数配置最合理？（）A.核心线程数1，最大线程数200，队列长度10000B.核心线程数等于CPU核心数，最大线程数等于CPU核心数*2，队列长度1000C.核心线程数等于CPU核心数*2，最大线程数等于CPU核心数*4，队列长度500D.核心线程数100，最大线程数100，队列长度1答案：C。解析：IO密集型任务IO等待时间占比高，核心线程数通常设置为CPU核心数*2，更多线程可以提升CPU利用率；队列长度不宜过长避免OOM，也不宜过短导致频繁触发拒绝策略，500-1000是银行批量业务的合理区间；A选项核心线程数太少处理效率低，队列过长易OOM；B选项是CPU密集型任务的配置；D选项队列太短会导致大量任务被拒绝，不符合批量业务特点。5.银行用户账户表主键设计最合理的是？（）A.自增IDB.UUIDC.雪花算法生成的分布式IDD.用户手机号作为主键答案：C。解析：雪花算法生成的ID是有序长整型，索引查询效率高，全局唯一，适合分布式集群部署的银行系统，同时ID中包含时间戳便于业务排查；自增ID在分库分表场景下会出现主键冲突，无法满足分布式架构需求；UUID是无序字符串，索引插入性能差，存储空间大；手机号属于敏感信息，且存在变更可能，不适合作为主键。6.银行转账方法调用另一个扣减积分方法，要求扣减积分异常不影响转账主流程，以下哪个事务传播行为适合扣减积分方法？（）A.REQUIREDB.REQUIRES_NEWC.NOT_SUPPORTEDD.NESTED答案：B。解析：REQUIRES_NEW会开启一个独立的新事务，新事务的回滚不会影响父事务，符合扣减积分异常不影响转账的需求；REQUIRED会加入父事务，积分扣减异常会导致整个转账事务回滚；NOT_SUPPORTED以非事务方式运行，不适合积分扣减需要事务保证的场景；NESTED是嵌套事务，子事务回滚会触发父事务回滚（除非显式捕获异常），不符合需求。7.银行核心系统微服务拆分原则错误的是？（）A.按业务域拆分，如账户服务、支付服务、信贷服务B.避免循环依赖，服务之间依赖层级不超过3层C.核心交易服务尽可能依赖更多公共服务提升复用率D.数据隔离，每个服务对应独立的数据库答案：C。解析：银行核心交易服务对稳定性要求极高，应尽可能减少外部依赖，避免公共服务故障引发核心服务雪崩；其余选项均为微服务拆分的正确原则，按业务域拆分符合高内聚低耦合要求，限制依赖层级避免调用链路过长引发超时，数据隔离避免单库故障影响多个服务。8.银行跨服务转账涉及账户服务和流水服务，以下哪种方案能保证最终一致性且性能最优？（）A.本地消息表B.两阶段提交（2PC）C.TCC事务D.最大努力通知答案：A。解析：本地消息表将业务操作和消息写入放在同一个本地事务中，保证消息生成的可靠性，再通过异步任务投递消息，实现最终一致性，性能损耗极低，适合银行高并发转账场景；2PC是强一致方案，性能差，易出现阻塞问题；TCC开发成本高，回滚逻辑复杂；最大努力通知适合对一致性要求更低的场景（如短信通知），不适合资金流水类业务。9.银行系统存储用户当天的交易流水，要求按交易时间排序，且频繁进行范围查询，以下哪个集合最适合？（）A.HashMapB.ArrayListC.TreeMapD.LinkedList答案：C。解析：TreeMap基于红黑树实现，默认按Key的自然顺序排序，支持高效的范围查询，符合按交易时间排序、范围查询的需求；HashMap是无序的；ArrayList插入、删除元素性能差，范围查询需要遍历；LinkedList范围查询效率极低。10.银行接口防重放攻击最不合理的方案是？（）A.请求加时间戳，有效期内允许请求B.请求加全局唯一流水号，服务端缓存已处理流水号C.请求加签名，校验签名合法性D.限制同一个IP每秒请求次数答案：D。解析：IP限流只能防止恶意刷接口，无法防止重放攻击，攻击者可以在限流阈值内重复发送合法请求；时间戳、唯一流水号、签名校验都是防重放的标准方案，银行接口通常会结合三者使用，保证请求的唯一性和合法性。二、填空题（共5题，每题4分，共20分）1.银行核心系统通常要求事务的隔离级别设置为______，避免出现脏读、不可重复读、幻读问题。答案：可重复读（REPEATABLEREAD）。注：MySQLInnoDB引擎的可重复读隔离级别通过MVCC+间隙锁解决了幻读问题，是银行系统的标准配置。2.JDK中提供的______原子类可以实现高性能的账户余额增减操作，避免使用synchronized带来的性能损耗。答案：AtomicLong。解析：AtomicLong基于CAS操作实现原子性更新，无锁化设计在高并发场景下性能远高于同步锁，适合银行账户余额高频更新的场景。3.银行系统数据备份通常采用______策略，即每天做一次全量备份，其余时间做增量备份，兼顾备份效率和恢复速度。答案：全量+增量备份。4.微服务架构下，银行接口调用通常会设置______和重试机制，避免单个服务故障引发整个链路雪崩，通常重试次数不超过3次。答案：超时时间。解析：超时时间设置过长会导致资源长时间占用，过短会误杀正常请求，银行核心接口通常设置超时时间为1-3秒，结合幂等设计实现重试。5.银行用户敏感数据（如身份证号、银行卡号）存储时必须进行______处理，传输时必须使用HTTPS协议，避免数据泄露。答案：脱敏加密。解析：通常采用AES对称加密存储敏感数据，展示时进行掩码处理，如银行卡号只显示前6位和后4位。三、简答题（共4题，每题15分，共60分）1.请简述银行核心转账业务的实现流程，以及如何避免重复转账、超账转、转账失败数据不一致问题？答案：（1）核心转账流程：①用户发起转账请求，网关层校验请求签名、防重放参数，生成全局唯一交易流水号；②参数校验：校验转出账户状态是否正常、余额是否充足、转入账户是否存在、转账金额是否符合规则；③账户操作：扣减转出账户余额，增加转入账户余额，同时记录双方交易流水；④事务提交，返回转账成功结果。（2）避免重复转账：接口实现幂等性，基于全局唯一交易流水号判断请求是否已处理，服务端缓存已处理成功的流水号，相同流水号的请求直接返回之前的处理结果；同时前端做按钮防重复点击限制。（3）避免超账转：扣减转出账户余额时使用乐观锁，执行SQL为`updateaccountsetbalance=balance-#{amount}whereaccount_id=#{accountId}andbalance>=#{amount}`，通过数据库行锁+余额判断保证不会出现负数；同时转账金额必须大于0，且不超过单日转账限额。（4）避免数据不一致：①本地事务保证同一数据库内的账户操作和流水记录原子性；②跨库或跨服务场景下使用本地消息表+MQ异步通知的方式保证最终一致性，消息消费失败会进行重试，超过最大重试次数触发告警人工介入；③每日跑批进行双边对账，核对账户余额变动和流水记录是否匹配，出现不一致自动冲正。2.银行核心系统经常出现卡顿、响应慢的问题，请从JVM、数据库、架构三个层面分析可能的原因及优化方案？答案：（1）JVM层面：原因：①FullGC频繁，导致STW时间过长；②元空间内存不足，触发FullGC；③堆内存设置过小，对象创建频繁触发GC。优化方案：①根据业务特点调整堆内存大小，通常新生代和老年代比例设置为1:2，大内存场景下使用G1垃圾收集器，设置-XX:MaxGCPauseMillis=200控制最大停顿时间；②排查内存泄漏问题，通过MAT分析堆转储文件，释放不必要的大对象引用；③元空间设置为256M以上，避免类加载频繁触发FullGC。（2）数据库层面：原因：①慢SQL过多，导致数据库CPU、IO使用率过高；②锁冲突严重，大量事务等待行锁；③单表数据量过大，查询性能下降；④数据库连接池设置过小，连接不足导致请求排队。优化方案：①开启慢SQL日志，对慢SQL添加索引，避免全表扫描，关联查询不超过3张表；②优化事务粒度，事务内操作尽量少，减少锁持有时间，避免死锁；③单表数据量超过500万时进行分库分表，按账户ID或时间维度分片；④连接池大小设置为CPU核心数*2+磁盘IO数，通常银行系统设置为20-50即可，避免连接过多导致数据库压力过大。（3）架构层面：原因：①服务调用链路过长，超时时间设置不合理；②热点请求未做缓存，全部打到数据库；③没有熔断降级机制，下游服务故障拖垮上游服务；④集群节点负载不均，部分节点压力过大。优化方案：①梳理调用链路，核心交易链路依赖服务不超过3个，合理设置超时时间，避免级联故障；②热点数据（如用户账户信息、公共参数）缓存到Redis，设置过期时间和缓存更新策略，避免缓存击穿、雪崩；③接入Sentinel或Hystrix实现熔断降级，非核心服务异常时直接返回默认值，不影响主流程；④接入负载均衡，按权重分配请求，同时设置限流规则，峰值时拒绝超出系统承载能力的请求，返回排队提示。3.请简述TCC事务的原理，以及在银行跨行转账场景下如何实现TCC事务，有哪些注意事项？答案：（1）TCC原理：TCC分为Try、Confirm、Cancel三个阶段，Try阶段完成所有业务检查，预留业务资源；Confirm阶段确认执行业务操作，不做任何业务检查，只使用Try阶段预留的资源，要求幂等；Cancel阶段取消执行业务操作，释放Try阶段预留的资源，同样要求幂等。TCC属于最终一致性方案，性能高于2PC，适合跨服务的资金交易场景。（2）跨行转账场景实现：①Try阶段：扣减转出方账户的可用余额，增加冻结余额，同时在转入方银行预留对应额度的待入账金额，记录TCC事务日志；②Confirm阶段：扣减转出方的冻结余额，实际增加转入方的账户余额，更新事务状态为成功；③Cancel阶段：恢复转出方的可用余额，扣减冻结余额，释放转入方预留的待入账额度，更新事务状态为失败。（3）注意事项：①必须实现幂等性，Confirm和Cancel阶段可能会被重复调用，需要根据事务ID判断是否已处理；②必须允许空回滚，即Try阶段没有执行成功的情况下，Cancel阶段被调用时要返回成功，不能抛出异常；③需要有事务超时机制，长时间处于中间状态的事务必须触发回滚，避免资源冻结；④需要有对账机制，每日核对TCC事务状态和账户流水，出现不一致人工介入处理。4.银行系统对数据安全性要求极高，请简述Java开发中需要注意哪些安全规范？答案：（1）代码安全：①避免SQL注入，必须使用MyBatis的#{}占位符，禁止使用${}拼接SQL，特殊场景必须使用时要做严格的参数校验；②避免XSS攻击，所有用户输入的参数都要做转义处理，存储和展示时过滤特殊字符；③避免命令注入，禁止直接拼接用户输入的参数执行系统命令，必须使用时要做白名单校验。（2）数据安全：①所有敏感数据（身份证号、银行卡号、密码、手机号）存储时必须加密，密码使用BCrypt不可逆加密，其余敏感数据使用AES对称加密，密钥单独存储在配置中心，禁止硬编码；②数据展示时必须脱敏，如手机号显示138*1234，银行卡号显示622202*1234；③数据传输时必须使用HTTPS协议，禁止HTTP传输敏感数据，接口请求必须加签名，校验参数是否被篡改。（3）权限安全：①所有接口都要做权限校验，区分普通用户、管理员、内部系统的权限，禁止越权访问；②用户登录采用JWT或Session机制，设置过期时间，禁止永久有效令牌；③操作日志必须记录所有敏感操作的用户、时间、参数、IP地址，便于审计追溯。（4）依赖安全：①定期排查项目依赖的第三方Jar包的安全漏洞，如Log4j、Fastjson的高危漏洞，及时升级到安全版本；②禁止引入未经过安全审计的第三方依赖，避免后门风险。四、编程题（共1题，20分）题目：请实现一个线程安全的银行账户类，支持存款、取款、查询余额三个方法，要求高并发场景下性能尽可能高，同时避免出现超取问题。答案：```javaimportjava.util.concurrent.atomic.AtomicLong;/*线程安全的银行账户类*/publicclassBankAccount{//账户IDprivatefinalStringaccountId;//账户余额，使用AtomicLong实现原子操作，无锁化保证线程安全privatefinalAtomicLongbalance;publicBankAccount(StringaccountId,longinitBalance){if(initBalance<0){thrownewIllegalArgumentException("初始余额不能为负数");}this.accountId=accountId;this.balance=newAtomicLong(initBalance);}/*存款方法*@paramamount存款金额，单位分*@return存款后的余额*/publiclongdeposit(longamount){if(amount<=0){thrownewIllegalArgumentException("存款金额必须大于0");}returnbalance.addAndGet(amount);}/*取款方法*@paramamount取款金额，单位分*@return取款后的余额，取款失败返回-1*/publiclongwithdraw(longamount){if(amount<=0){thrownewIllegalArgumentException("取款金额必须大于0");}longcurrentBalance;longnewBalance;do{//获取当前余额currentBalance=balance.get();//余额不足，取款失败if(currentBalance<amount){return-1;}//计算新余额newBalance=currentBalance-amount;//CAS更新，更新失败则重试}while(!pareAndSet(currentBalance,newBalance));returnnewBalance;}/*查询余额方法*@return当前账户余额*/publiclonggetBalance(){returnbalance.get();}publicStringgetAccountId(){returnaccountId;}}```代码说明：①使用AtomicLong存储余额，基于CAS实现无锁化的原子操作，高并发场景下性能远高于synchronized同步锁；②取款时使用自旋CAS保证操作的原子性，同时判断余额是否充足，避免超取问题；③所有参数都做合法性校验，避免非法参数导致的业务异常；④金额使用长整型存储，单位为分，避免浮点数精度丢失问题，符合银行系统的标准设计。五、场景题（共1题，30分）题目：某城商行的支付系统峰值QPS达到5000，现有架构是单体架构，数据库单库单表，高峰期经常出现响应超时、转账失败的问题，请设计一个高可用、高并发的分布式支付系统架构，满足业务发展需求。答案：（1）架构分层设计：采用微服务架构，分为接入层、网关层、业务服务层、数据层四个层级：①接入层：使用LVS+Nginx实现四层+七层负载均衡，支持水平扩展，峰值时可以动态扩容节点，同时接入WAF防火墙拦截恶意请求。②网关层：使用SpringCloudGateway作为统一网关，实现签名校验、防重放、权限校验、限流熔断、路由转发功能，设置限流规则，QPS超过系统承载能力时直接返回排队提示，避免系统被打垮。③业务服务层：