本文研究的主要是Java編程Retry重試機制實例詳解，分享了相關代碼示例，小編覺得還是挺不錯的，具有一定借鑒價值，需要的朋友可以參考下
應用中需要實現一個功能： 需要將數據上傳到遠程存儲服務，同時在返回處理成功情況下做其他操作。這個功能不復雜，分為兩個步驟：第一步調用遠程的Rest服務邏輯包裝給處理方法返回處理結果；第二步拿到第一步結果或者捕捉異常，如果出現錯誤或異常實現重試上傳邏輯，否則繼續邏輯操作。
包裝正常上傳邏輯基礎上，通過判斷返回結果或監聽異常決策是否重試，同時為了解決立即重試的無效執行(假設異常是有外部執行不穩定導致的)，休眠一定延遲時間重新執行功能邏輯。
public void commonRetry(Map<String, Object> dataMap) throws InterruptedException { Map<String, Object> paramMap = Maps.newHashMap(); paramMap.put("tableName", "creativeTable"); paramMap.put("ds", "20160220"); paramMap.put("dataMap", dataMap); boolean result = false; try { result = uploadToOdps(paramMap); if (!result) { Thread.sleep(1000); uploadToOdps(paramMap); //一次重試} } catch (Exception e) { Thread.sleep(1000); uploadToOdps(paramMap);//一次重試} }上述方案還是有可能重試無效，解決這個問題嘗試增加重試次數retrycount以及重試間隔週期interval，達到增加重試有效的可能性。
public void commonRetry(Map<String, Object> dataMap) throws InterruptedException { Map<String, Object> paramMap = Maps.newHashMap(); paramMap.put("tableName", "creativeTable"); paramMap.put("ds", "20160220"); paramMap.put("dataMap", dataMap); boolean result = false; try { result = uploadToOdps(paramMap); if (!result) { reuploadToOdps(paramMap,1000L,10);//延遲多次重試} } catch (Exception e) { reuploadToOdps(paramMap,1000L,10);//延遲多次重試} }方案一和方案二存在一個問題：正常邏輯和重試邏輯強耦合，重試邏輯非常依賴正常邏輯的執行結果，對正常邏輯預期結果被動重試觸發，對於重試根源往往由於邏輯複雜被淹沒，可能導致後續運維對於重試邏輯要解決什麼問題產生不一致理解。重試正確性難保證而且不利於運維，原因是重試設計依賴正常邏輯異常或重試根源的臆測。
那有沒有可以參考的方案實現正常邏輯和重試邏輯解耦，同時能夠讓重試邏輯有一個標準化的解決思路？答案是有：那就是基於代理設計模式的重試工具，我們嘗試使用相應工具來重構上述場景。
命令設計模式具體定義不展開闡述，主要該方案看中命令模式能夠通過執行對象完成接口操作邏輯，同時內部封裝處理重試邏輯，不暴露實現細節，對於調用者來看就是執行了正常邏輯，達到解耦的目標，具體看下功能實現。 （類圖結構）
IRetry約定了上傳和重試接口，其實現類OdpsRetry封裝ODPS上傳邏輯，同時封裝重試機制和重試策略。與此同時使用recover方法在結束執行做恢復操作。
而我們的調用者LogicClient無需關注重試，通過重試者Retryer實現約定接口功能，同時Retryer需要對重試邏輯做出響應和處理， Retryer具體重試處理又交給真正的IRtry接口的實現類OdpsRetry完成。通過採用命令模式，優雅實現正常邏輯和重試邏輯分離，同時通過構建重試者角色，實現正常邏輯和重試邏輯的分離，讓重試有更好的擴展性。
spring-retry是一個開源工具包，目前可用的版本為1.1.2.RELEASE，該工具把重試操作模板定制化，可以設置重試策略和回退策略。同時重試執行實例保證線程安全，具體場景操作實例如下：
public void upload(final Map<String, Object> map) throws Exception { // 構建重試模板實例RetryTemplate retryTemplate = new RetryTemplate(); // 設置重試策略，主要設置重試次數SimpleRetryPolicy policy = new SimpleRetryPolicy(3, Collections.<Class<? extends Throwable>, Boolean> singletonMap(Exception.class, true)); // 設置重試回退操作策略，主要設置重試間隔時間FixedBackOffPolicy fixedBackOffPolicy = new FixedBackOffPolicy(); fixedBackOffPolicy.setBackOffPeriod(100); retryTemplate.setRetryPolicy(policy); retryTemplate.setBackOffPolicy(fixedBackOffPolicy); // 通過RetryCallback 重試回調實例包裝正常邏輯邏輯，第一次執行和重試執行執行的都是這段邏輯final RetryCallback<Object, Exception> retryCallback = new RetryCallback<Object, Exception>() { //RetryContext 重試操作上下文約定，統一spring-try包裝public Object doWithRetry(RetryContext context) throws Exception { System.out.println("do some thing"); Exception e = uploadToOdps(map); System.out.println(context.getRetryCount()); throw e;//這個點特別注意，重試的根源通過Exception返回} }; // 通過RecoveryCallback 重試流程正常結束或者達到重試上限後的退出恢復操作實例final RecoveryCallback<Object> recoveryCallback = new RecoveryCallback<Object>() { public Object recover(RetryContext context) throws Exception { System.out.println("do recory operation"); return null; } }; try { // 由retryTemplate 執行execute方法開始邏輯執行retryTemplate.execute(retryCallback, recoveryCallback); } catch (Exception e) { e.printStackTrace(); } }簡單剖析下案例代碼，RetryTemplate 承擔了重試執行者的角色，它可以設置SimpleRetryPolicy(重試策略，設置重試上限，重試的根源實體)，FixedBackOffPolicy（固定的回退策略，設置執行重試回退的時間間隔）。 RetryTemplate通過execute提交執行操作，需要準備RetryCallback 和RecoveryCallback 兩個類實例，前者對應的就是重試回調邏輯實例，包裝正常的功能操作，RecoveryCallback實現的是整個執行操作結束的恢復操作實例。
RetryTemplate的execute 是線程安全的，實現邏輯使用ThreadLocal保存每個執行實例的RetryContext執行上下文。
Spring-retry工具雖能優雅實現重試，但是存在兩個不友好設計：一個是重試實體限定為Throwable子類，說明重試針對的是可捕捉的功能異常為設計前提的，但是我們希望依賴某個數據對象實體作為重試實體，但Sping-retry框架必須強制轉換為Throwable子類。另一個就是重試根源的斷言對象使用的是doWithRetry的Exception 異常實例，不符合正常內部斷言的返回設計。
Spring Retry提倡以註解的方式對方法進行重試，重試邏輯是同步執行的，重試的“失敗”針對的是Throwable，如果你要以返回值的某個狀態來判定是否需要重試，可能只能通過自己判斷返回值然後顯式拋出異常了。
Spring 對於Retry的抽象
“抽象”是每個程序員必備的素質。對於資質平平的我來說，沒有比模仿與理解優秀源碼更好地進步途徑了吧。為此，我將其核心邏輯重寫了一遍...下面就看看Spring Retry對於“重試”的抽象。
Spring retry相關接口.jpg
Guava retryer工具與spring-retry類似，都是通過定義重試者角色來包裝正常邏輯重試，但是Guava retryer有更優的策略定義，在支持重試次數和重試頻度控制基礎上，能夠兼容支持多個異常或者自定義實體對象的重試源定義，讓重試功能有更多的靈活性。 Guava Retryer也是線程安全的，入口調用邏輯採用的是Java.util.concurrent.Callable的call方法，示例代碼如下：
public void uploadOdps(final Map<String, Object> map) { // RetryerBuilder 構建重試實例retryer,可以設置重試源且可以支持多個重試源，可以配置重試次數或重試超時時間，以及可以配置等待時間間隔Retryer<Boolean> retryer = RetryerBuilder.<Boolean> newBuilder() .retryIfException().//設置異常重試源retryIfResult(new Predicate<Boolean>() {//設置自定義段元重試源， @Override public boolean apply(Boolean state) {//特別注意：這個apply返回true說明需要重試，與操作邏輯的語義要區分return true; } }) .withStopStrategy(StopStrategies.stopAfterAttempt(5))//設置重試5次，同樣可以設置重試超時時間.withWaitStrategy(WaitStrategies.fixedWait(100L, TimeUnit.MILLISECONDS)).build();//設置每次重試間隔try { //重試入口採用call方法，用的是java.util.concurrent.Callable<V>的call方法,所以執行是線程安全的boolean result = retryer.call(new Callable<Boolean>() { @Override public Boolean call() throws Exception { try { //特別注意：返回false說明無需重試，返回true說明需要繼續重試return uploadToOdps(map); } catch (Exception e) { throw new Exception(e); } } }); } catch (ExecutionException e) { } catch (RetryException ex) { } }示例代碼原理分析：
RetryerBuilder是一個factory創建者，可以定制設置重試源且可以支持多個重試源，可以配置重試次數或重試超時時間，以及可以配置等待時間間隔，創建重試者Retryer實例。
RetryerBuilder的重試源支持Exception異常對象和自定義斷言對象，通過retryIfException 和retryIfResult設置，同時支持多個且能兼容。
RetryerBuilder的等待時間和重試限製配置採用不同的策略類實現，同時對於等待時間特徵可以支持無間隔和固定間隔方式。
Retryer 是重試者實例，通過call方法執行操作邏輯，同時封裝重試源操作。
優雅重試共性和原理
正常和重試優雅解耦，重試斷言條件實例或邏輯異常實例是兩者溝通的媒介。
約定重試間隔，差異性重試策略，設置重試超時時間，進一步保證重試有效性以及重試流程穩定性。
都使用了命令設計模式，通過委託重試對象完成相應的邏輯操作，同時內部封裝實現重試邏輯。
Spring-tryer和guava-tryer工具都是線程安全的重試，能夠支持並發業務場景的重試邏輯正確性。
優雅重試適用場景
功能邏輯中存在不穩定依賴場景，需要使用重試獲取預期結果或者嘗試重新執行邏輯不立即結束。比如遠程接口訪問，數據加載訪問，數據上傳校驗等等。
對於異常場景存在需要重試場景，同時希望把正常邏輯和重試邏輯解耦。
對於需要基於數據媒介交互，希望通過重試輪詢檢測執行邏輯場景也可以考慮重試方案。
以上就是本文關於Java編程Retry重試機制實例詳解的全部內容，希望對大家有所幫助。感興趣的朋友可以繼續參閱本站其他相關專題，如有不足之處，歡迎留言指出。感謝朋友們對本站的支持！