Java 中推动办法重试的一种机制

有这种一个需求，当调用某个方式抛出异常，比如通过 HttpClient 调用远程接口时因为网络因素报 TimeOut 异常；或者所请求的接口返回类似于“处理中”这样的信息，需要重复去查结果时，我们期望当前方法无法在这些特定的状况下，重复执行，如果超过了我们的希望，则不重复执行。而且，我们期望才能控制重试次数，不期望无限期执行下去。

Java 中有诸多定时任务的推动，如 Spring 的 Schedule，Quartz 等，稍微想一下，显然不符合我们的意愿。递归倒是可以，但是有些问题，先看下递归的实现：

    private int retryTimes = 3;
    @Test
    public void upperMethod() {
        method("123", "456");
    }
    public void method(String param1, String param2) {
        System.out.println(param1 + param2);
        // 其他一些操作，但是没有得到预期的返回结果，或者抛出异常
        boolean isException = true;
        if(isException && retryTimes > 0){
            retryTimes --;
            method(param1, param2);
        }
    }

method 方法是必须重复执行的，重复执行 3 次，加上第一次执行，一共 4 次。如果异常了，则在 catch 里面递归调用 method。如果返回“处理中”等状况，则进行判定，是否应该递归调用。

这里的问题是定义了 retryTimes 这样一个全局变量，不优雅，如果必须重复执行的方式较好，而且重复次数不一样，则需定义多个全局函数。递归可以优化一下：

    @Test
    public void upperMethod() {
        method(3, "123", "456");
    }
    public void method(int retryTimes,String param1, String param2) {
        System.out.println(param1 + param2);
        // 其他一些操作，但是没有得到预期的返回结果，或者抛出异常
        boolean isException = true;
        if(isException && retryTimes > 0){
            method(--retryTimes, param1, param2);
        }
    }

这里去掉了全局函数，但是 method 方法多了一个和自身逻辑无关的 retryTimes 变量，还不优雅。如果参数众多，还会变得混乱。

下面做了一个还算优雅的方式：

    @Test
    public void mainMethod() {
        subMethod("123", "456");
    }
    public void subMethod(String param1, String param2) {
        System.out.println(param1 + param2);
        RetryUtil.setRetryTimes(3).retry(param1, param2);
    }

增加了一个 RetryUtil 的工具类java 调用失败重试2次，设置重试次数，然后传入当前方法的参数，进行重复执行。这里的重点就是 RetryUtil 的实现：

public class RetryUtil {
    private static ThreadLocal<Integer> retryTimesInThread = new ThreadLocal<>();
    /**
     * 设置当前方法重试次数
     *
     * @param retryTimes
     * @return
     */
    public static RetryUtil setRetryTimes(Integer retryTimes) {
        if (retryTimesInThread.get() == null)
            retryTimesInThread.set(retryTimes);
        return new RetryUtil();
    }
    /**
     * 重试当前方法
     * <p>按顺序传入调用者方法的所有参数</p>
     *
     * @param args
     * @return
     */
    public Object retry(Object... args) {
        try {
            Integer retryTimes = retryTimesInThread.get();
            if (retryTimes <= 0) {
                retryTimesInThread.remove();
                return null;
            }
            retryTimesInThread.set(--retryTimes);
            String upperClassName = Thread.currentThread().getStackTrace()[2].getClassName();
            String upperMethodName = Thread.currentThread().getStackTrace()[2].getMethodName();
            Class clazz = Class.forName(upperClassName);
            Object targetObject = clazz.newInstance();
            Method targetMethod = null;
            for (Method method : clazz.getDeclaredMethods()) {
                if (method.getName().equals(upperMethodName)) {
                    targetMethod = method;
                    break;
                }
            }
            if (targetMethod == null)
                return null;
            targetMethod.setAccessible(true);
            return targetMethod.invoke(targetObject, args);
        } catch (Exception e) {
            e.printStackTrace();
            return null;
        }
    }
}

为了避免多线程情况下发生并发问题，这里定义了一个 ThreadLocal 变量来传输当前线程的重试次数。然后借助 setRetryTimes ，一个静态方式来设定这个重试次数，并返回一个 RetryUtil 对象。

调用者通过返回的 RetryUtil 对象调用 retry 方法实现重试。retry 方法接收一个可变参数，因为调用者实际的参数不确定，这里要求按次序传入调用者方法的所有参数。

接下来判断 ThreadLocal 变量是否大于等于 0 ，如果是，则表明重复次数未超过，返回 null；如果不是，则使 ThreadLocal 变量减一。接下来：

String upperClassName = Thread.currentThread().getStackTrace()[2].getClassName();
String upperMethodName = Thread.currentThread().getStackTrace()[2].getMethodName();

来获得当前方法（retry）的上层方法名跟上层类名。Thread.currentThread().getStackTrace() 得到线程的方法栈数组，数组的第二个元素 Thread.currentThread().getStackTrace()[1] 为当前方法栈，第三个元素Thread.currentThread().getStackTrace() [2] 为上层方法栈，通过上层方法的栈帧得到上层方法的方式名跟类名。

下面就是通过反射获取该类的所有步骤，循环判断方式名是否等于所应重复执行的方式，如果是的话java 调用失败重试2次，执行该办法，参数就是传入可变参数。

可能你们会说反射会耗时，但我觉得对于上述这样需求的状况，重试次数也不会太多，因此性能可以接受。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-138853-1.html