Resilience4j独立面试题
本页只放标准回答、追问方向和原理跳转。完整源码、流程图、配置、商业Demo、失败窗口与Runbook见Resilience4j内部原理与生产治理。回答前先说明版本：JDK 8存量线可使用兼容的1.7.1；Resilience4j 2.x是Java 17线。本页现代样本为Boot 3.5.16、Cloud 2025.0.3、Spring Cloud CircuitBreaker 3.3.3和Cloud BOM解析的Resilience4j 2.2.0。
回答主线
mermaid
flowchart TD
A["先说版本与故障场景"] --> B["再说模块职责"]
B --> C["推演许可、执行与统计"]
C --> D["说明失败和取消边界"]
D --> E["给出Metrics、测试与恢复"]一、版本、定位和模块职责
| 面试题 | 标准回答 | 追问方向 | 原理页 |
|---|---|---|---|
| Resilience4j是什么 | 它是一组轻量、模块化、以函数装饰为核心的Java容错组件，包括CircuitBreaker、Retry、Bulkhead、RateLimiter和TimeLimiter。它不是远程调用框架，也不会让分布式调用变成强一致。 | 与Hystrix、Sentinel区别？ | 三层模型 |
| 为什么不能把它只叫熔断器 | CircuitBreaker只是一个模块；超时、并发隔离、重试和限流分别由其他模块负责。只加CircuitBreaker不会自动创建线程池或停止慢I/O。 | 每个模块只解决什么？ | 模块地图 |
| JDK 8和Java 17怎样选版本 | Resilience4j 1.7.1是JDK 8字节码major 52；2.2.0是Java 17字节码major 61。JDK 8存量系统不能只改依赖版本使用2.x，Boot 3现代项目使用Java 17起步。 | Boot 2配置能否复制到Boot 3？ | 版本边界 |
| 为什么独立最新版2.4.0却使用2.2.0 | 截至2026-07-19独立最新版是2.4.0，但Cloud 2025.0.3 BOM与CircuitBreaker 3.3.3解析2.2.0。Spring项目应优先使用兼容BOM组合，不盲目覆盖单个库。 | 强制升级有什么风险？ | 版本基线 |
| Spring Cloud CircuitBreaker和原生Resilience4j区别 | 前者是Spring Cloud统一门面，通过CircuitBreakerFactory创建实现；后者直接使用Registry、Decorator或注解，暴露完整模块能力。二者底层可使用相同内核，但配置、线程切换和组合方式不同。 | 什么时候直接用原生API？ | 集成方式 |
| CircuitBreaker解决什么 | 根据本实例过去已完成调用的失败率和慢调用率决定是否继续访问某个故障域；持续异常时快速拒绝未来调用。它不负责超时和资源隔离。 | OPEN是否说明下游宕机？ | 原生调用链 |
| Retry解决什么 | 对明确可重试、幂等且仍有Deadline的瞬时失败执行有限再次尝试。它不提供幂等，也不判断远端写操作是否已提交。 | maxAttempts是否包含首次调用？ | Retry |
| Bulkhead解决什么 | 限制某依赖同时占用的许可、线程和队列，使一个故障域不能耗尽全部共享资源。它不根据失败率自动开路。 | Semaphore与ThreadPool区别？ | Semaphore |
| RateLimiter解决什么 | 按时间周期发放许可，控制单位时间请求速率。本地RateLimiter按实例独立，不能天然实现集群总配额，也不能限制慢调用造成的高在途。 | 与Bulkhead区别？ | RateLimiter |
| TimeLimiter解决什么 | 限制Future或CompletionStage最多等待多久，超时后返回TimeoutException。它不保证Socket、SQL、远端事务和副作用物理停止。 | cancel(true)为什么不可靠？ | TimeLimiter |
二、CircuitBreaker调用链和状态机
| 面试题 | 标准回答 | 追问方向 | 原理页 |
|---|---|---|---|
| 一次CircuitBreaker调用怎样走 | 先向当前State申请许可；拒绝则抛CallNotPermittedException；放行则计时执行真实调用，按结果或异常分类，记录滑动窗口，再检查失败率和慢调用率是否触发状态转换。 | 结果对象能否算失败？ | 调用链 |
| CLOSED状态做什么 | 正常放行并统计成功、失败、慢成功和慢失败；样本达到minimumNumberOfCalls后，失败率或慢调用率达到阈值才转OPEN。 | 为什么需要最小调用量？ | CLOSED |
| OPEN状态做什么 | 快速拒绝，不访问下游，并记录not permitted。等待期到后惰性或自动进入HALF_OPEN。OPEN是本实例本地状态，不保证全实例一致。 | 拒绝算下游失败吗？ | OPEN |
| HALF_OPEN状态做什么 | 原子发放有限探测许可，用探测样本决定回CLOSED还是OPEN；有限探测防止恢复时瞬间全量流量形成Recovery Storm。 | 探测一直不完成怎么办？ | HALF_OPEN |
| FORCED_OPEN是什么 | 运维强制拒绝所有调用，适合紧急切断依赖，但必须有权限、审计、TTL和恢复流程，否则下游恢复后业务仍长期降级。 | 与普通OPEN区别？ | 特殊状态 |
| DISABLED是什么 | 始终放行，关闭正常熔断保护和对应统计行为。它不等于“只关闭拒绝但保留完整指标”。 | 上线观察应该用什么？ | 特殊状态 |
| METRICS_ONLY是什么 | 始终放行并统计，阈值超限可发布事件但不自动OPEN，适合新规则上线前验证分类和阈值。 | 怎样从观察切到启用？ | 特殊状态 |
| 状态转换怎样保证线程安全 | 当前State保存在AtomicReference中，状态替换用getAndUpdate；CLOSED、OPEN、HALF_OPEN内部再用AtomicBoolean或AtomicInteger保证并发线程只转换一次并有限发放许可。 | 为什么不是volatile枚举？ | 并发状态 |
| 多线程同时达到失败阈值会重复OPEN吗 | CLOSED内部使用isClosed.compareAndSet(true,false)，只有一个线程赢得转换资格；状态引用再原子替换，其他线程仍可记录自己的完成结果但不会重复转换。 | 旧状态完成结果是否丢失？ | 并发状态 |
| OPEN怎样进入HALF_OPEN | 默认可由等待期后的下一次权限申请惰性触发；开启自动转换后由调度器定时触发。两种方式都用原子闸门避免重复转换。 | 自动转换有什么成本？ | OPEN |
| HALF_OPEN许可怎样扣减 | 使用AtomicInteger的原子更新，许可大于0时减一并放行，用完后拒绝；探测完成后按结果CAS到OPEN或CLOSED。 | 未完成的探测会怎样？ | HALF_OPEN |
三、滑动窗口、阈值和异常分类
| 面试题 | 标准回答 | 追问方向 | 原理页 |
|---|---|---|---|
| Count-based窗口是什么 | 维护最近N次调用的Measurement循环数组和一个总聚合；新结果累加，覆盖最旧测量时从总量减去旧值。 | 获取Snapshot复杂度？ | 次数窗口 |
| Time-based窗口是什么 | 维护最近N秒的秒级Bucket，每个Bucket聚合该秒调用；窗口移动时减去过期Bucket，不按QPS保存每条调用。 | 低QPS有什么风险？ | 时间窗口 |
| Subtract-on-Evict是什么 | 新Outcome进入总聚合，最旧Measurement或Bucket淘汰时把其聚合从总量扣掉，因此无需每次扫描整个窗口。 | 为什么Snapshot是O(1)？ | 次数窗口 |
| Snapshot获取为什么是O(1) | 成功、失败、慢调用和总耗时已增量预聚合，读取时复制当前总量，不遍历N个请求；窗口内存通常是O(N)。 | 记录操作是否无锁？ | 滑动窗口 |
| minimumNumberOfCalls作用 | 样本不足时失败率和慢调用率无效，防止低流量接口1次失败就按100%故障开路。次数窗口中实际最小值不会超过窗口大小。 | 参数怎样按QPS选？ | 容量推导 |
| 失败率怎样计算 | failedCalls / totalCalls × 100%，仅在达到最小调用量后有效；达到或超过阈值触发开路条件。 | 等于阈值是否开路？ | CLOSED |
| 慢调用率为什么重要 | 全部请求最终成功但耗时10秒仍会耗尽线程和连接；慢调用率可在异常率为0时识别慢故障。 | 慢阈值从哪里来？ | CLOSED |
| 哪些异常应该计失败 | 通常连接失败、读取超时、5xx计系统失败；参数、权限、库存不足等要按业务契约分类，不能全部算下游故障。 | 429怎样处理？ | 异常分类 |
| ignoreExceptions和recordExceptions区别 | ignore表示不进入成功/失败统计；record决定哪些异常算失败。范围重叠和继承关系必须通过测试确认，避免误开或掩盖故障。 | 默认异常怎样处理？ | 异常分类 |
| 正常返回对象能否触发失败 | 可以通过recordResultPredicate把特定结果视为失败，但应使用稳定业务语义，不能把所有空结果都当系统故障。 | 业务错误码怎样分类？ | 异常分类 |
| CallNotPermitted算失败样本吗 | 它表示本地OPEN或FORCED_OPEN拒绝，没有真正访问下游，应单独统计not permitted，不能当成本次下游又失败。 | 告警怎样区分？ | OPEN |
四、Bulkhead、TimeLimiter、Retry和RateLimiter
| 面试题 | 标准回答 | 追问方向 | 原理页 |
|---|---|---|---|
| SemaphoreBulkhead怎样工作 | 构造Semaphore，进入前按maxWaitDuration获取许可，完成后释放；调用仍在原线程执行，下游阻塞时Tomcat线程仍被占用。 | 公平信号量代价？ | Semaphore |
| Semaphore许可忘记释放会怎样 | 可用许可逐步减少，最终所有调用都BulkheadFull；装饰API会在完成路径释放，手工调用必须用finally或正确onComplete。 | 怎样监控泄漏？ | Semaphore |
| 动态降低Semaphore并发是否瞬时生效 | 源码会收回差额许可，降低时可能等待当前调用释放；配置变更不是无成本的原子数字替换。 | 动态配置线程会不会阻塞？ | Semaphore |
| ThreadPoolBulkhead怎样工作 | 使用有界ThreadPoolExecutor，队列0用SynchronousQueue，否则用ArrayBlockingQueue；线程与队列满时把拒绝转换为BulkheadFullException。 | 默认队列为什么危险？ | 线程池Bulkhead |
| 两种Bulkhead怎样选 | 已异步、快速调用可用Semaphore限制并发；阻塞且需隔离调用线程可用ThreadPool，但要承担线程切换、队列和上下文传播成本。 | Java 21虚拟线程后还需要吗？ | 线程池Bulkhead |
| Bulkhead为什么不能只看线程数 | HTTP连接池、数据库连接池和下游配额可能更小；许可大于真实资源只会让更多线程等待第二层瓶颈。 | 参数怎样推导？ | 容量推导 |
| TimeLimiter Future路径怎样超时 | 调用带超时的Future.get；超时发布事件，并可future.cancel(true)。中断是协作信号，底层库可能继续执行。 | 远端写操作怎么办？ | TimeLimiter |
| CompletionStage怎样超时 | 调度器安排超时任务，到期把CompletableFuture异常完成；原始异步工作仍可能继续。 | 为什么不是物理取消？ | TimeLimiter |
| TimeLimiter后还要HTTP超时吗 | 要。TimeLimiter限制上层等待，客户端Connect、Pool Acquire、Read/Response Timeout才约束网络阶段；SQL还要Query Timeout。 | 各超时怎样分预算？ | TimeLimiter |
| maxAttempts=3是什么意思 | 包含首次调用，最多三个总Attempt；应同时监控逻辑请求与物理Attempt。 | 为什么不是重试三次？ | Retry |
| 同步Retry为什么可能耗尽线程 | 尝试之间通常用Thread.sleep等待，调用线程在退避期仍被占用；高并发重试会增加线程和下游压力。 | 异步Retry怎样做？ | Retry |
| 为什么需要指数退避和抖动 | 固定间隔让大量实例同时重试形成流量脉冲；指数退避拉开尝试，抖动打散时刻，但仍要受Deadline和预算限制。 | Retry Budget是什么？ | Retry |
| AtomicRateLimiter怎样发许可 | 时间划分Cycle，用AtomicReference保存周期、许可和等待时间；CAS扣减或预留未来许可，必要时park等待。 | 为什么许可可以为负？ | RateLimiter |
| RateLimiter许可为负代表什么 | 表示调用已预留未来Cycle许可，不是系统有负容量；后续周期补充许可后逐步归还。 | timeoutDuration怎样影响？ | RateLimiter |
| 本地RateLimiter能做全局限流吗 | 不能天然做到。每实例独立，扩容会增加集群总许可；全局配额需要Gateway、Redis、Envoy或集中系统并考虑其可用性。 | 本地限流适合什么？ | RateLimiter |
五、Spring Boot 3、Spring Cloud和AOP
| 面试题 | 标准回答 | 追问方向 | 原理页 |
|---|---|---|---|
| Boot 3怎样自动配置Resilience4j | 读取AutoConfiguration.imports，按类路径绑定resilience4j.*属性，创建各模块Registry、Aspect、Fallback解析器、Metrics Publisher、Health和事件端点。 | 只有YAML没有模块JAR会怎样？ | Boot自动配置 |
| 使用注解为什么需要AOP | @CircuitBreaker等由Spring Aspect拦截代理方法；没有AOP或调用没经过代理，注解只是元数据，不执行保护。 | 自调用为什么失效？ | 注解顺序 |
| 同一个Bean自调用为什么不生效 | this.method()绕过Spring代理，不经过Aspect。应拆分Bean、从代理入口调用或使用显式Decorator。 | private方法能否代理？ | 自调用 |
| 多注解默认顺序是什么 | 2.2.0样本Order依次为Retry MAX-5、CircuitBreaker MAX-4、RateLimiter MAX-3、TimeLimiter MAX-2、Bulkhead MAX-1；数值更小通常在外层。升级后要重新验证。 | 顺序怎样影响统计？ | Aspect顺序 |
| Retry在CircuitBreaker外层会怎样 | 每个Retry Attempt可能分别经过CircuitBreaker并进入统计，能反映物理失败，但可能更快开路。 | 反过来呢？ | 顺序语义 |
| CircuitBreaker在Retry外层会怎样 | 可能只把整组Retry最终结果当一个样本，反映逻辑请求结果，却隐藏物理Attempt放大。 | 哪个顺序最好？ | 顺序语义 |
| Fallback方法怎样匹配 | 参数与原方法兼容，可在末尾增加Throwable子类，返回类型兼容；更具体异常优先。Fallback自身异常继续向上并应独立观测。 | 为什么总是找不到Fallback？ | Fallback |
| Spring Cloud自动配置创建什么 | 条件满足且无其他Factory时创建Resilience4JCircuitBreakerFactory，注入CircuitBreaker/TimeLimiter Registry、可选BulkheadProvider、配置属性和Customizer。 | Observation怎样接入？ | Cloud自动配置 |
| Factory的id和group是什么 | id表示具体操作，group表示服务或故障域；样本配置优先级通常id、group、默认。稳定命名可复用状态和Metrics。 | 能否用orderId做id？ | Factory配置 |
| Spring Cloud阻塞run怎样执行 | 样本默认把Supplier提交Executor，TimeLimiter限制Future，再由Bulkhead装饰，CircuitBreaker在外层统计，异常进入Fallback。属性可禁用线程池或TimeLimiter。 | 为什么要看目标版本源码？ | Cloud执行链 |
| Factory默认CachedThreadPool有什么风险 | 故障时线程可能增长，且线程切换需要传播Trace/MDC；生产应配置受控Executor、ThreadPoolBulkhead或评估禁用线程路径。 | 怎样验证线程池来源？ | Cloud执行链 |
| 配置属性和Java Customizer谁优先 | 样本Factory先查Registry中的id/group配置，再使用Factory默认配置；属性常先构建Registry，所以具体属性可覆盖仅配置默认的Customizer。应避免多处定义同名阈值。 | 动态配置怎么灰度？ | 配置优先级 |
六、商业场景、监控与故障排查
| 面试题 | 标准回答 | 追问方向 | 原理页 |
|---|---|---|---|
| 库存查询失败Fallback返回什么 | 返回UNKNOWN和degraded=true，而不是0库存或有库存；降级必须进入接口契约、日志、Trace和指标，防止上游持久化伪事实。 | 写操作能否Fallback成功？ | Fallback |
| 支付超时为什么不能直接重试 | 调用方停止等待时支付可能已提交，再次请求可能重复扣款；必须使用幂等键、状态查询、对账和补偿收敛UNKNOWN结果。 | TimeLimiter能回滚吗？ | TimeLimiter |
| 订单聚合怎样保护多个下游 | 订单主数据、库存、优惠、物流和推荐使用独立故障域、子Deadline和Bulkhead；核心失败整体失败，非核心明确降级，Fallback不再远程调用。 | 总Deadline怎样分配？ | 商业Demo |
| 熔断器突然OPEN怎样排查 | 查state变化时间、窗口样本、失败/慢调用、异常分类、下游P99、连接池、线程、数据库和发布，再查Retry放大；不要直接强制CLOSED。 | 怎样证明是慢调用触发？ | Runbook |
| not permitted激增说明什么 | 可能是OPEN、FORCED_OPEN或运维配置，本次请求没有访问下游；应查等待期、HALF_OPEN探测和Fallback容量。 | 是否增加失败率？ | Runbook |
| Bulkhead rejected激增能直接扩容吗 | 不能。先查真实耗时、active、queue、连接池和下游容量；盲目增加线程可能把更高并发推给已过载下游。 | Little定律怎样估算？ | 容量推导 |
| Timeout激增但下游日志成功是什么原因 | TimeLimiter只停止等待，底层调用可能继续并最终成功；应按业务键查询事实，不盲目重试写操作。 | 怎样减少残留任务？ | Runbook |
| Fallback成功率很高是否健康 | 不一定，HTTP 200可能只是长期降级。要监控degraded、UNKNOWN、用户影响和补偿积压，不能只看接口成功率。 | SLO怎样定义？ | Runbook |
| 应监控哪些CircuitBreaker指标 | state、successful、failed、slow、not permitted、buffered calls和状态转换；按稳定breaker name和实例拆分。 | 为什么不能加orderId标签？ | Metrics |
| 事件消费者里能写数据库吗 | 不建议同步远程I/O，事件回调会增加调用路径延迟并可能在故障时递归放大；应轻量、有界、异步并允许遥测退化。 | 事件丢失怎么办？ | Metrics事件 |
| breaker名称能包含skuId吗 | 不能。每个名称对应独立状态、对象和Metrics，高基数会造成内存与时间序列爆炸；名称应表示稳定故障域。 | 业务ID放哪里？ | Registry |
| 怎样灰度新熔断规则 | 先METRICS_ONLY观察异常分类和阈值，再小流量实例启用，故障注入验证OPEN/HALF_OPEN/Fallback，监控误拒绝后逐步扩展。 | 动态配置如何回滚？ | 故障演练 |
| 怎样证明系统真正抗雪崩 | 注入持续500、慢成功、连接失败、Bulkhead满和恢复场景，验证物理Attempt、线程/连接、OPEN拒绝、有限HALF_OPEN、明确降级和恢复无洪峰。 | 只做单元测试够吗？ | 故障演练 |
七、迁移与架构判断
| 面试题 | 标准回答 | 追问方向 | 原理页 |
|---|---|---|---|
| Hystrix怎样迁移到Resilience4j | 先记录Command、线程池、超时、错误分类、Fallback和Metrics基线，再映射CircuitBreaker、Bulkhead、TimeLimiter和Retry，逐故障域灰度比较物理Attempt与P99。 | 能否只替换注解？ | Hystrix迁移 |
| Resilience4j和Sentinel怎样选 | Resilience4j适合进程内模块化函数装饰和Spring Cloud CircuitBreaker；Sentinel更偏流量治理、热点参数和规则控制。可组合但要避免重复限流、熔断和统计冲突。 | 哪个支持集群流控？ | Sentinel |
| Resilience4j和Service Mesh是否重复 | Mesh可在代理层做超时、重试、熔断和限流，应用层更了解业务异常、幂等和降级语义。职责可分层，但不能让两层都无预算重试。 | 哪层做重试？ | 稳定性治理 |
| Java 21虚拟线程能替代Bulkhead吗 | 不能。虚拟线程降低阻塞线程成本，但HTTP连接、数据库连接、CPU、锁、下游配额仍有限；仍需并发限制、超时和过载保护。Java 17本身没有正式虚拟线程。 | ThreadPoolBulkhead还需要吗？ | 线程池Bulkhead |
| 本地熔断状态为什么不一致 | 每个实例按自身流量样本独立统计，负载分布不同就可能一台OPEN、一台CLOSED。这是本地模型，不是共识状态机。 | 是否要集中同步状态？ | OPEN |
| 熔断器能保证下游恢复吗 | 不能。它只限制施压并有限探测；恢复仍取决于下游修复、容量、缓存预热、连接和数据收敛。 | HALF_OPEN解决什么？ | HALF_OPEN |
| Resilience4j能保证Exactly Once吗 | 不能。超时、重试和网络结果未知仍需要业务幂等、唯一约束、状态机、消息和补偿；容错组件不提供分布式事务。 | 支付如何收敛？ | 幂等 |
项目回答模板
我们先按版本拆分：JDK 8存量服务使用兼容的Resilience4j 1.7.1，Java 17、Boot 3.5服务使用Cloud 2025.0 BOM管理的Spring Cloud CircuitBreaker 3.3.3和Resilience4j 2.2.0，不单独覆盖到独立最新版。订单聚合按库存、优惠、物流拆分独立故障域；CircuitBreaker同时统计失败率和慢调用率，Bulkhead限制并发，TimeLimiter受总Deadline约束，Retry只对幂等连接失败最多两个总Attempt。库存降级返回UNKNOWN而不是0库存，支付超时进入幂等查询和对账。
上线前先用METRICS_ONLY验证异常分类，再故障注入500、慢成功、连接失败、Bulkhead满和恢复场景。生产监控state、slow、failed、not permitted、rejected、timeout和物理Attempt；OPEN后不强制CLOSED，而是确认下游恢复并通过有限HALF_OPEN探测。Trace和日志按稳定breaker name关联，业务ID不进入Metric标签。
自检清单
- 能明确Resilience4j 1.x/JDK 8与2.x/Java 17边界。
- 能解释Cloud BOM版本与独立最新版为什么不同。
- 能画出许可、真实调用、结果分类、窗口和状态转换链。
- 能解释Subtract-on-Evict和O(1) Snapshot。
- 能区分OPEN拒绝、Bulkhead拒绝、Timeout和下游失败。
- 能解释TimeLimiter超时后远端仍可能成功。
- 能计算多层Retry物理Attempt。
- 能说明原生注解默认Aspect顺序及其统计影响。
- 能说明Spring Cloud Factory的id/group配置和执行链。
- 能给出故障演练、Metrics和恢复Runbook。
本章小结
Resilience4j面试的分水岭不是会不会背CLOSED、OPEN、HALF_OPEN，而是能否解释状态如何并发转换、窗口如何聚合、每个模块在哪里获取许可、装饰顺序怎样改变物理调用，以及超时、降级和重试之后业务事实怎样收敛。