差異處
這裏顯示兩個版本的差異處。
Both sides previous revision 前次修改 下次修改 | 前次修改 | ||
java:effective_java:exceptions:strive_for_failure_atomicity [2022/03/24 23:33] tony [Introduction] |
java:effective_java:exceptions:strive_for_failure_atomicity [2023/06/25 09:48] (目前版本) |
||
---|---|---|---|
行 6: | 行 6: | ||
第一個方法是操作Immutable object。因為它不會被改變,自然而然就滿足所謂的failure-atomic。依照過往經驗,如果要回傳一個Collection,盡量讓它是Immutable object只用於計算,並避免直接的修改造成side effect。\\ | 第一個方法是操作Immutable object。因為它不會被改變,自然而然就滿足所謂的failure-atomic。依照過往經驗,如果要回傳一個Collection,盡量讓它是Immutable object只用於計算,並避免直接的修改造成side effect。\\ | ||
\\ | \\ | ||
- | 第二個方法就是在造成物件狀態改變之前,做precheck。假如不做檢查讓物件進入了錯誤的狀態,反而可能會衍生更多問題,且不好debug。但如果要做precheck,就要特別注意多執行緒存取的情境。 | + | 第二個方法就是在造成物件狀態改變之前,做precheck。假如不做檢查讓物件進入了錯誤的狀態,反而可能會衍生更多問題,且不好debug。\\ |
+ | \\ | ||
+ | 第三個方法就是先把物件複製一份在操作。就算發生問題,也不會影響到原本的物件狀態。\\ | ||
+ | \\ | ||
+ | 最後一個方法,就是要實做一段recovery code,好讓發生問題時,可以rollback回原本的狀態。像是使用資料庫的Transaction,或操作檔案前先複製一份,有問題在還原檔案等等。\\ | ||
+ | \\ | ||
+ | 使用這些方法,都要注意一下"代價"與"多執行緒存取"的問題。像要複製物件或準備環原點,都會存在著性能開銷,且程式碼往往會複雜一些些;比較低成本的Immutable object不一定適用於各種情況;precheck則大部分情況都有可能要注意多執行緒的存取,假如是依賴目標物件的狀態做precheck的話。\\ | ||
+ | \\ | ||
+ | 另外,書中有建議,如果無法滿足failure-atomic的method,"建議"要寫註解讓用的人知道。 | ||
===== Note ===== | ===== Note ===== |