差異處

這裏顯示兩個版本的差異處。

連向這個比對檢視

下次修改
前次修改
java:effective_java:exceptions:strive_for_failure_atomicity [2022/03/23 23:27]
tony 建立
java:effective_java:exceptions:strive_for_failure_atomicity [2022/04/18 22:35] (目前版本)
tony [Introduction]
行 1: 行 1:
 {{tag>​java effective_java exceptions}} {{tag>​java effective_java exceptions}}
-====== Effective Java - Synchronize access to shared mutable data ======+====== Effective Java - Strive for failure atomicity ​======
 ===== Introduction ===== ===== Introduction =====
 +這個Item主要在宣導「在工作失敗時,要努力讓物件的狀態完好如呼叫前」。如果method滿足這個條件,就可以稱為具有failure-atomic的method。(Note.要考慮的不只有待操作的物件,應還有做為輸入參數的物件)\\
 +\\
 +第一個方法是操作Immutable object。因為它不會被改變,自然而然就滿足所謂的failure-atomic。依照過往經驗,如果要回傳一個Collection,盡量讓它是Immutable object只用於計算,並避免直接的修改造成side effect。\\
 +\\
 +第二個方法就是在造成物件狀態改變之前,做precheck。假如不做檢查讓物件進入了錯誤的狀態,反而可能會衍生更多問題,且不好debug。\\
 +\\
 +第三個方法就是先把物件複製一份在操作。就算發生問題,也不會影響到原本的物件狀態。\\
 +\\
 +最後一個方法,就是要實做一段recovery code,好讓發生問題時,可以rollback回原本的狀態。像是使用資料庫的Transaction,或操作檔案前先複製一份,有問題在還原檔案等等。\\
 +\\
 +使用這些方法,都要注意一下"​代價"​與"​多執行緒存取"​的問題。像要複製物件或準備環原點,都會存在著性能開銷,且程式碼往往會複雜一些些;比較低成本的Immutable object不一定適用於各種情況;precheck則大部分情況都有可能要注意多執行緒的存取,假如是依賴目標物件的狀態做precheck的話。\\
 +\\
 +另外,書中有建議,如果無法滿足failure-atomic的method,"​建議"​要寫註解讓用的人知道。
  
 ===== Note ===== ===== Note =====