异常流程试题及答案

异常流程试题及答案一、单项选择题（每题3分，共30分）1.以下哪一项不属于系统级异常？A.数据库连接超时（ConnectionTimeout）B.用户输入非法手机号（如11位数字外的字符）C.服务器内存溢出（OutOfMemoryError）D.第三方API调用返回503ServiceUnavailable答案：B解析：系统级异常通常指与底层资源或基础设施相关的不可控错误（如数据库、内存、外部服务），而用户输入非法属于业务逻辑可预判的校验异常（业务级异常）。2.在电商订单支付流程中，用户完成支付后，支付系统未及时回调通知电商系统，导致订单状态仍为“未支付”。此时最合理的异常处理策略是？A.立即向用户发送短信提醒“支付未成功，请重新支付”B.在电商系统中增加“支付结果轮询”机制，主动查询支付状态C.直接标记订单为“支付失败”并释放库存D.等待24小时后自动关闭订单答案：B解析：支付回调延迟是常见的异步通信异常，通过轮询主动确认支付结果（如每5分钟查询一次，持续1小时），既能避免误判，又能减少用户干扰。选项A可能误判用户已支付的情况；选项C和D会直接影响用户权益，不合理。3.某金融系统在处理用户提现请求时，数据库突然宕机，导致提现操作未完成事务提交。此时应优先执行以下哪一步？A.记录异常日志，通知运维修复数据库B.向用户返回“提现处理中，请稍后查询”C.尝试回滚未提交的事务，释放账户冻结的资金D.重新发起提现请求，覆盖原操作答案：C解析：数据库宕机时，若事务未提交，需优先保证数据一致性。用户提现时通常会先冻结账户资金（预扣），若事务中断，需回滚冻结操作，避免用户资金被错误锁定。选项A是后续步骤，选项B是用户反馈，选项D可能导致重复扣款。4.以下关于异常日志记录的描述，错误的是？A.需包含异常类型、时间戳、请求参数、用户ID等上下文信息B.应记录完整的异常堆栈（StackTrace），但需过滤敏感信息（如密码）C.生产环境中，为避免日志冗余，应仅记录ERROR级别日志，忽略WARN级别D.分布式系统中需记录全局唯一的请求ID（TraceID），便于链路追踪答案：C解析：WARN级别日志（如接口调用超时但未影响最终结果）可用于监控潜在风险，生产环境应根据业务需求保留，并非全部忽略。其他选项均为日志记录的最佳实践。5.在微服务架构中，服务A调用服务B时，服务B因负载过高返回429TooManyRequests。服务A的正确处理方式是？A.立即重试调用服务B，直到成功B.触发熔断机制，暂时停止调用服务B，转向降级逻辑（如返回缓存数据）C.修改服务A的代码，增加并发数限制，避免调用服务BD.通知运维扩容服务B的服务器答案：B解析：429异常表明服务B已过载，此时重试会加剧负载。熔断机制（如Hystrix或Sentinel）可暂时切断调用，执行降级（如返回历史数据或默认值），保护系统整体稳定性。选项A会导致雪崩效应；选项C是长期优化，非紧急处理；选项D是运维后续动作。6.某物流系统中，用户下单时选择“次日达”，但因仓库爆仓导致实际发货延迟2天。系统需向用户反馈异常，以下哪项信息最关键？A.道歉话术（如“非常抱歉给您带来不便”）B.延迟原因（仓库爆仓）C.新的预计送达时间（如“预计3天后送达”）D.补偿方案（如赠送10元优惠券）答案：C解析：用户最关心的是“何时能收到”，明确新的送达时间可降低焦虑。其他信息（道歉、原因、补偿）虽重要，但优先级低于时间确认。7.以下哪一项属于可重试的异常？A.数据库主键冲突（DuplicateKeyException）B.用户余额不足（InsufficientBalanceException）C.网络超时（SocketTimeoutException）D.订单已取消（OrderCancelledException）答案：C解析：网络超时可能是临时网络波动导致，重试可能成功；主键冲突（如重复提交）需检查业务逻辑去重，而非重试；余额不足、订单已取消是业务状态问题，重试无意义。8.在Java中，以下代码可能引发的异常类型是？```javaStringstr=null;intlength=str.length();```A.NullPointerExceptionB.IllegalArgumentExceptionC.IndexOutOfBoundsExceptionD.ClassCastException答案：A解析：调用null对象的方法会抛出空指针异常（NullPointerException）。9.某系统需处理用户上传的Excel文件，若文件格式错误（如列名与模板不匹配），应抛出？A.系统异常（SystemException）B.业务异常（BusinessException）C.运行时异常（RuntimeException）D.错误（Error）答案：B解析：文件格式错误是业务逻辑可预判的场景（如模板校验），应通过业务异常明确提示用户“文件列名不匹配，请检查模板”。系统异常通常指不可控错误（如IO异常）。10.分布式事务中，若部分服务提交成功，部分服务提交失败，需通过以下哪种机制保证数据一致性？A.重试（Retry）B.补偿（Compensation）C.熔断（CircuitBreaker）D.限流（RateLimiting）答案：B解析：分布式事务需满足最终一致性，当部分节点失败时，需调用补偿操作（如反向操作）回滚已成功的节点（如“已扣库存”需“加回库存”）。重试适用于临时异常，熔断和限流是流量控制手段。二、简答题（每题8分，共40分）1.简述业务异常与系统异常的核心区别，并各举2个例子。答案：核心区别：业务异常是业务逻辑可预判、可处理的预期内错误（如用户输入不符合要求、余额不足），通常需明确提示用户具体问题；系统异常是不可控的底层错误（如数据库宕机、网络超时），通常需记录日志并由技术团队修复。示例：-业务异常：用户注册时手机号已被占用（DuplicatePhoneException）、商品库存不足（OutOfStockException）；-系统异常：Redis连接超时（RedisConnectionException）、消息队列宕机（MQBrokerDownException）。2.说明“异常重试”的适用场景及注意事项。答案：适用场景：临时、偶发性异常（如网络抖动、第三方服务短暂不可用），且操作具备幂等性（多次执行结果一致）。注意事项：-限制重试次数（如3次），避免无限重试导致系统负载过高；-采用指数退避策略（RetryBackoff），如第一次等待1秒，第二次2秒，第三次4秒，减少对目标服务的冲击；-仅对可重试异常（如SocketTimeout）重试，对不可重试异常（如主键冲突）直接抛出；-确保操作幂等（如通过唯一订单号防止重复扣款）。3.设计一个电商“下单”流程的异常处理方案，需覆盖库存校验、支付、订单生成三个关键环节。答案：（1）库存校验环节：-预扣库存：用户下单时先锁定库存（而非直接扣减），防止超卖；-异常处理：若库存不足，抛出“库存不足”业务异常，提示用户“商品剩余XX件，当前下单数量超过库存”；若库存服务调用超时，记录日志并尝试重试（最多2次），仍失败则返回“库存查询失败，请稍后再试”。（2）支付环节：-异步支付：用户选择支付方式后，跳转至支付网关，系统生成“支付中”订单；-异常处理：支付超时（如30分钟未完成），自动关闭订单并释放预扣库存；支付回调失败（如网络问题未收到通知），通过轮询主动查询支付状态（每5分钟查询1次，持续2小时），确认成功后更新订单状态。（3）订单生成环节：-事务控制：使用分布式事务（如Seata）或本地事务+消息队列，保证“扣库存”与“生成订单”原子性；-异常处理：若订单生成失败（如数据库写入异常），回滚预扣的库存，记录日志并通知用户“订单提交失败，已为您保留库存，请重新下单”。4.列举至少4种常见的异常监控手段，并说明其适用场景。答案：（1）日志监控（如ELKStack）：通过收集应用日志，过滤ERROR/WARN级别异常，适用所有异常场景（如系统崩溃、业务逻辑错误）；（2）APM工具（如SkyWalking、Pinpoint）：追踪分布式链路中的异常（如服务调用超时、接口响应慢），适用于微服务架构；（3）指标监控（如Prometheus）：监控关键指标（如QPS、错误率、内存使用率），当错误率超过阈值（如5%）时触发告警，适用于实时发现系统异常；（4）用户反馈监控：通过收集用户端报错信息（如APP崩溃日志、前端JS异常），适用于发现客户端特有异常（如低版本浏览器兼容性问题）。5.说明“全局异常处理”在SpringBoot中的实现方式及优势。答案：实现方式：-使用@ControllerAdvice注解定义全局异常处理类，结合@ExceptionHandler注解捕获特定异常（如RuntimeException、BusinessException）；-对不同异常类型返回统一格式的响应（如{code:400,message:"参数错误",data:null}）；-可结合@ResponseStatus指定HTTP状态码（如404、500）。优势：-解耦异常处理逻辑，避免在每个Controller中重复编写try-catch；-统一响应格式，提升前端对接效率；-集中处理未捕获的异常（如空指针），避免返回原始错误堆栈给用户，增强安全性；-便于扩展（如添加日志记录、监控告警）。三、案例分析题（20分）背景：某在线教育平台推出“限时免费课程”活动，活动开始后，大量用户涌入导致系统出现以下异常：（1）用户登录接口响应超时（平均耗时从200ms升至5s）；（2）课程领取接口返回“数据库连接池耗尽”；（3）部分用户成功领取课程后，页面显示“课程未到账”；（4）运维监控到服务器CPU使用率持续90%以上。问题：请分析上述异常的可能原因，并提出具体的解决措施。答案：异常（1）：登录接口响应超时可能原因：活动期间并发登录请求激增，超出服务器处理能力；登录逻辑中存在慢查询（如未索引的用户表查询）。解决措施：-限流：对登录接口进行限流（如每秒最多1000次请求），拒绝超出阈值的请求并返回“当前登录用户过多，请稍后再试”；-优化查询：检查用户表索引（如手机号、用户名是否为主键或唯一索引），添加缺失索引；-缓存会话：将用户登录态存储到Redis（而非数据库），减少数据库访问压力。异常（2）：数据库连接池耗尽可能原因：大量未释放的数据库连接（如事务未及时提交/回滚）、连接池配置过小（如最大连接数设置为20，而并发请求达200）。解决措施：-检查代码：确保所有数据库操作使用try-with-resources或finally块释放连接，避免连接泄漏；-调整连接池参数：增大最大连接数（如调整为100），设置合理的超时时间（如连接超时30秒）；-读写分离：将查询操作路由到从库，减少主库压力；-使用连接池监控（如HikariCP的metrics），实时监控连接使用情况。异常（3）：课程领取后未到账可能原因：课程发放逻辑未在事务中执行（如“扣减库存”与“添加用户课程”未原子化），或分布式事务提交失败；缓存未及时更新（如用户课程列表缓存未失效）。解决措施：-事务控制：将“扣减课程库存”和“添加用户课程记录”放入本地事务（@Transactional），确保原子性；若涉及多服务（如库存服务+用户服务），使用分布式事务框架（如Seata）；-缓存更新：课程到账后，主动清除用户课程列表的缓存（如删除Redis中key为“user:course:12345”的缓存），或设置短过期时间（如5分钟）；-补偿机制：添加“课程发放失败”队列，定时重试未成功的发放任务（如每小时扫描一次），确保最终一致性。异常（4）：CPU使用率持续90%以上可能原因：代码中存在死循环（如错误的循环条件）、大量线程竞争（如锁粒度过大）、GC频繁（如堆内存分配不合理）。解决措施：-线程dump分析：通过jstack命令获取线程堆栈，定位是否有死锁或长时间运行的线程；-代码审查：检查循环逻辑（如分页查询是否遗漏终止条件）、锁使用（如将synchronized块缩小到最小范围）；-JVM调优：增大堆内存（如-Xmx从2G调整为4G），选择合适的GC收集器（如G1），减少FullGC频率；-横向扩容：增加服务器实例，通过负载均衡（如Nginx）分摊流量。四、编程题（10分）需求：设计一个Java工具类`ExceptionHandlerUtil`，要求实现以下功能：（1）捕获方法执行过程中抛出的异常，记录详细日志（包含方法名、参数、异常类型、堆栈信息）；（2）对可重试异常（如IOException）进行最多3次重试，重试间隔为1秒、2秒、4秒（指数退避）；（3）对不可重试异常（如IllegalArgumentException）直接抛出，不重试；（4）返回方法执行结果或包装后的异常信息（如自定义的Result对象）。要求：使用Java8+语法，代码需包含必要注释，体现健壮性。答案：```javaimportlombok.extern.slf4j.Slf4j;importjava.io.IOException;importjava.lang.reflect.Method;importjava.util.concurrent.TimeUnit;importjava.util.function.Supplier;/通用异常处理工具类，支持重试、日志记录及结果包装/@Slf4jpublicclassExceptionHandlerUtil{/执行带异常处理的方法@paramsupplier待执行的方法（无参有返回值）@parammethod方法对象（用于日志记录）@paramargs方法参数（用于日志记录）@param<T>返回值类型@return包装后的结果对象/publicstatic<T>Result<T>execute(Supplier<T>supplier,Methodmethod,Object...args){intretryCount=0;finalintmaxRetry=3;while(true){try{Tresult=supplier.get();returnResult.success(result);}catch(Exceptione){//记录详细日志log.error("方法执行异常|方法名:{},参数:{},异常类型:{},堆栈:{}",method.getName(),args,e.getClass().getSimpleName(),e.getStackTrace());//判断是否可重试if(isRetryable(e)&&retryCount<maxRetry){retryCount++;longdelay=(long)(Math.pow(2,retryCount-1)1000);//1s,2s,4stry{TimeUnit.MILLISECONDS.sleep(delay);}catch(InterruptedExceptionie){Thread.currentThread().interrupt();//恢复中断状态log.warn("重试等待被中断:{}",ie.getMessage());}}else{//不可重试或达到最大重试次数，返回异常结果returnResult.error(e.getMessage(),e.getClass().getSimpleName());}}}}/判断异常是否可重试@parame异常对象@return是否可重试/privatestaticbooleanisRetryable(Exceptione){//示例：IO异常（如网络问题）可重试，参数异常不可重试returneinstanceofIOException;}/结果包装类/publicstaticclassResult<T>{privatebooleansuccess;privateTdata;privateStringerrorMsg;privateStringerrorType;publicstatic<T>Result<T>success(Tdata){Result<T>result=newResult<>();result.success=true;result.data=data;returnresult;}publicstatic<T>Result<T>error(StringerrorMsg,StringerrorType){Result<T>result=newResult<>();result.success=false;result.errorMsg=errorMsg;result.errorType=err