在分布式系统或依赖外部资源的Java应用中，临时性错误如网络超时、数据库锁等待、第三方接口限流等难以完全避免。如果每次失败都直接中断流程，系统的健壮性会大打折扣。通过合理的异常捕获与重试机制，可以在不增加业务复杂度的前提下，显著提升操作的成功率。
为什么需要捕获并重试
很多刚接触后端开发的工程师会认为，只要代码逻辑正确就不会出错。但实际上，Java程序运行过程中大量失败来自外部环境而非自身bug。例如调用支付网关时返回了超时异常，但服务端其实已经处理了请求，这种场景下简单抛错会让用户重复支付，而重试一次往往就能拿到正确结果。
从系统容错角度看，重试是一种以时间换成功率的策略。它把偶发的、可恢复的错误和真正的逻辑错误区分开。如果不在代码层面捕获这些特定异常并重新尝试，就只能依赖上游或用户手动操作，体验和系统稳定性都会下降。
使用try-catch与循环实现基础重试
最直观的做法是用try-catch捕获目标异常，再配合for循环控制重试次数。这种方式没有第三方依赖，适合逻辑简单、重试条件固定的场景。下面示例展示了对可能抛出IOException的操作重试三次：
public static String fetchWithRetry() throws Exception {
int maxAttempts = 3;
Exception lastEx = null;
for (int i = 0; i < maxAttempts; i++) {
try {
// 模拟一个可能失败的网络调用
return callRemoteService();
} catch (java.io.IOException e) {
lastEx = e;
System.out.println("第" + (i + 1) + "次尝试失败，准备重试");
Thread.sleep(1000); // 简单等待后重试
}
}
throw lastEx; // 全部失败后抛出最后一次异常
}
private static String callRemoteService() throws java.io.IOException {
if (Math.random() < 0.7) {
throw new java.io.IOException("模拟网络波动");
}
return "success";
}
上面的代码通过循环最多执行三次调用，只有捕获到IOException才重试，其他异常会直接终止。每次重试前使用Thread.sleep做了固定间隔停顿，避免对故障服务造成更大压力。
这种写法的优点是清晰可控，但缺点也很明显：重试逻辑和业务代码耦合在一起，当需要为多个方法添加重试时会产生大量重复代码；另外它只处理了一种异常，且等待策略固定，难以应对复杂的退避需求。
利用Guava Retrying构建灵活重试器
对于更严谨的工程实践，推荐使用Google的Guava Retrying库。它提供了Retryer对象，可以用声明式方式定义重试条件、停止策略、等待间隔和重试监听器。开发者只需关注业务逻辑本身。
import com.github.rholder.retry.Retryer;
import com.github.rholder.retry.RetryerBuilder;
import com.github.rholder.retry.StopStrategies;
import com.github.rholder.retry.WaitStrategies;
import com.github.rholder.retry.RetryException;
import java.io.IOException;
import java.util.concurrent.TimeUnit;
public class RetryDemo {
public static void main(String[] args) {
Retryer<String> retryer = RetryerBuilder.<String>newBuilder()
.retryIfExceptionOfType(IOException.class) // 遇到IO异常重试
.withStopStrategy(StopStrategies.stopAfterAttempt(5)) // 最多五次
.withWaitStrategy(WaitStrategies.fixedWait(500, TimeUnit.MILLISECONDS)) // 间隔500毫秒
.build();
try {
String result = retryer.call(() -> callRemoteService());
System.out.println("最终结果: " + result);
} catch (RetryException | Exception e) {
System.out.println("重试耗尽依然失败");
}
}
private static String callRemoteService() throws IOException {
if (Math.random() < 0.6) {
throw new IOException("临时不可用");
}
return "ok";
}
}
示例中RetryerBuilder配置了仅对IOException重试，最多尝试五次，每次固定等待半秒。call方法接收一个Callable，内部业务无需关心循环与捕获。相比手写循环，这种结构把重试策略抽离出来，方便单元测试和统一调整。
Guava Retrying还支持指数退避、随机等待等高级等待策略，也能根据返回值做重试判断，比如当结果等于null时也重试。对于需要精细控制容错行为的服务，它比基础循环更合适。
重试设计的注意事项
重试虽好，但不能滥用。首先必须确保被重试的操作是幂等的，否则像非幂等的写请求在超时后重试，可能造成重复下单或重复扣款。其次，重试次数和间隔要合理，过多重试会拉长请求链路，在依赖普遍故障时易引发线程池耗尽。
另一个常见误区是捕获了过于宽泛的Exception。例如把NullPointerException也纳入重试，这类代码错误重试再多次也不会成功，反而掩盖了bug。应当只针对明确的、可恢复的异常类型重试，并结合日志与监控统计重试率，以便及时发现下游不稳定问题。
| 方案 | 适用场景 | 主要缺点 |
|---|---|---|
| try-catch加循环 | 简单脚本或少量调用点 | 代码冗余，策略单一 |
| Guava Retrying | 多业务模块统一容错 | 引入第三方依赖 |
| Spring Retry注解 | Spring项目声明式重试 | 与框架绑定较强 |
无论选择哪种方式，核心思路都是把临时性失败从致命错误中剥离出来，用可控的重复执行换取更高的系统可用度。理解异常类型与操作幂等性，是写好Java重试逻辑的前提。