今天有个工作不久的同事问我：日常开发中 Java 的反射有啥用呢？尤其是写业务程序的时候，基本就是增删改查，复杂的需求无非就是写起来麻烦一些，都没什么技术含量，像反射这种比较高级的特性，也就只有在那些像 Spring 这样的框架中才用得到啊。
听他这么说，也不知道该如何回答，就想到了几年前自己写的一篇博客，他看以后，说反射确实有用，只要留心，用处应该挺大的，所以面试的时候也经常会问到反射的问题。所以今天将这篇博客的文章分享给大家，希望对有同样困惑的同学有所帮助。
原文如下：
有这样一个需求，当调用某个方法抛出异常，比如通过 HttpClient 调用远程接口时由于网络原因报 TimeOut 异常；或者所请求的接口返回类似于“处理中”这样的信息，需要重复去查结果时，我们希望当前方法能够在这种特定的情况下，重复执行，如果达到了预期，则不继续重复。而且，希望能够控制重试次数，不希望无限期执行下去。
Java 中有各种定时任务的实现，如 Spring 的 Schedule，Quartz 等，稍微想一下，显然不符合我们的需求。递归倒是可以，但是有些问题，先看下递归的实现：
method 方法是需要重复执行的，重复执行 3 次，加上第一次执行，一共 4 次。如果异常了，则在 catch 里面递归调用 method。如果返回“处理中”等情况，则进行判断，是否需要递归调用。
这里的问题是定义了 retryTimes 这样一个全局变量，不够优雅，如果需要重复执行的方法较多，而且重复次数不一样，则需定义多个全局变量。递归可以优化一下：
这里去掉了全局变量，但是 method 方法多了一个和自身逻辑无关的 retryTimes 变量，还不优雅。如果参数较多，还会显得混乱。
下面做了一个还算优雅的方法：
增加了一个 RetryUtil 的工具类，设置重试次数，然后传入当前方法的参数，进行重复执行。这里的重点就是 RetryUtil 的实现：
为了防止多线程情况下出现并发问题，这里定义了一个 ThreadLocal 变量来存储当前线程的重试次数。然后通过 setRetryTimes ，一个静态方法来设置这个重试次数，并返回一个 RetryUtil 对象。
调用者通过返回的 RetryUtil 对象调用 retry 方法实现重试。retry 方法接收一个可变参数，因为调用者实际的参数不确定，这里要求按顺序传入调用者方法的所有参数。
接下来判断 ThreadLocal 变量是否小于等于 0 ，如果是，则说明重复次数已达到，返回 null；如果不是，则让 ThreadLocal 变量减一。接下来：
来获取当前方法retry的上层方法名和上层类名。Thread.currentThread().getStackTrace() 得到线程的方法栈数组，数组的第二个元素 Thread.currentThread().getStackTrace() [1] 为当前方法栈，第三个元素 Thread.currentThread().getStackTrace() [2] 为上层方法栈，通过上层方法的栈帧得到上层方法的方法名和类名。
下面就是通过反射获取该类的所有方法，循环判断方法名是否等于所要重复执行的方法，如果是的话，执行该方法，参数就是传入可变参数。
可能大家会说反射会耗时，但我认为对于上述这种需求的情况，重试次数也不会太多，因此性能可以接受。
以上就是今天分享的内容，希望对你有所启发。后台回复 「星辰大海」 获取更多学习资料！
网友评论