Java 編碼規範6(編程規約-併發處理)

併發處理

---

其它相關文章
Java 編碼規範1(編程規約-命名風格)
Java 編碼規範2(編程規約-常量定義)
Java 編碼規範3(編程規約-代碼格式)
Java 編碼規範4(編程規約-OOP規約)
Java 編碼規範5(編程規約-集合處理)
Java 編碼規範6(編程規約-併發處理)
Java 編碼規範7(編程規約-控制語句)
Java 編碼規範8(編程規約-註釋規約與其它)
Java 編碼規範9(異常日誌)
Java 編碼規範10(單元測試)
Java 編碼規範11(安全規約)
Java 編碼規範12(MySQL-建表規約)
Java 編碼規範13(MySQL-索引規約)
Java 編碼規範14(MySQL-SQL語句與ORM映射)
Java 編碼規範15(工程結構)

---

1. [強制] 獲取單例對象需要保證線程安全，其中的方法也要保證線程安全。

   • 說明：資源驅動類、工具類、單例工廠類都需要注意。
   • 單例模式推薦使用雙重鎖檢查實現，最好使用內部靜態類實現。

2. [強制] 創建線程或線程池時請指定有意義的線程名稱，方便出錯時回溯。

   • 正例：

     public class TimerTaskThread extends Thread {
         public TimerTaskThread() {
             super.setName("TimerTaskThread");
             ...
         }
         ...
     ｝

3. [強制] 線程資源必須通過線程池提供，不允許在應用中自行顯式創建線程。

   • 說明：使用線程池的好處是減少在創建和銷燬線程上所花的時間以及系統資源的開銷，解決資源不足的問題。如果不使用線程池，有可能造成系統創建大量同類線程而導致消耗完內存或者“過度切換”的問題。

4. [強制] 線程池不允許使用 Executors 去創建，而是通過 ThreadPoolExecutor的方式，這樣的處理方式讓寫同學更加明確線程池運行規則，避資源耗盡風險。

   • FixedThreadPool 和 SingleThreadPoolPool : 允許的請求隊列長度爲 Integer.MAX_VALUE，可能會堆積大量的請求，從而導致 OOM。
   • CachedThreadPool 和 ScheduledThreadPool : 允許的創建線程數量爲 Integer.MAX_VALUE，可能會創建大量的線程，從而導致 OOM。

5. [強制] SimpleDateFormat 是線程不安全的類，一般不要定義爲static變量。
   

   • 如果定義爲static，必須加鎖，或者使用DateUtils工具類。

   • 正例：注意線程安全，使用DateUtils。亦推薦如下處理：

   private static final ThreadLocal<DateFormat> df = new ThreadLocal<DateFormat>() {
       @Override
       protected DateFormat initialValue() {
           return new SimpleDateFormat("yyyy-MM-dd");
       }
   };

6. 說明: 如果是JDK8的應用，可以使用Instant代替Date，LocalDateTime代替Calendar，DateTimeFormatter代替SimpleDateFormat，官方給出的解釋：
   

   simple beautiful strong immutable thread-safe。

7. [強制] 高併發時，同步調用應該去考量鎖的性能損耗。

   • 能用無鎖數據結構，就不要用鎖；
   • 能鎖區塊，就不要鎖整個方法體；
   • 能用對象鎖，就不要用類鎖。
   • 儘可能使加鎖的代碼塊工作量儘可能的小，避免在鎖代碼塊中調用RPC方法。

8. [強制] 對多個資源、數據庫表、對象同時加鎖時，需要保持一致的加鎖順序，否則可能會造成死鎖。

   • 說明: 線程一需要對錶A、B、C依次全部加鎖後纔可以進行更新操作，那麼線程二的加鎖順序也必須是A、B、C，否則可能出現死鎖。

9. [強制] 併發修改同一記錄時，避免更新丟失，需要加鎖。要麼在應用層加鎖，要麼在緩存加鎖，要麼在數據庫層使用樂觀鎖，使用version作爲更新依據。

   • 如果每次訪問衝突概率小於20%，推薦使用樂觀鎖，否則使用悲觀鎖。樂觀鎖的重試次數不得小於3次。

10. [強制] 多線程並行處理定時任務時，Timer運行多個TimeTask時，只要其中之一沒有捕獲拋出的異常，其它任務便會自動終止運行，使用ScheduledExecutorService則沒有這個問題。

11. [推薦] 使用CountDownLatch進行異步轉同步操作，每個線程退出前必須調用countDown方法，線程執行代碼注意catch異常，確保countDown方法被執行到，避免主線程無法執行至await方法，直到超時才返回結果。

    • 注意，子線程拋出異常堆棧，不能在主線程try-catch到。

12. [推薦] 避免Random實例被多線程使用，雖然共享該實例是線程安全的，但會因競爭同一seed導致性能下降。

    • Random實例包括java.util.Random 的實例或者 Math.random()的方式。
    • 正例: 在JDK7之後，可以直接使用API ThreadLocalRandom，而在JDK7之前，需要編碼保證每個線程持有一個實例。

13. [推薦] 在併發場景下，通過雙重檢查鎖（double-checked locking）實現延遲初始化的優化問題隱患(可參考 The “Double-Checked Locking is Broken” Declaration)，推薦解決方案中較爲簡單一種（適用於JDK5及以上版本），將目標屬性聲明爲 volatile 型。

    • 反例：

      class Singleton {
          private Helper helper = null;
          public Helper getHelper() {
              //只有一次鎖檢查
              if (helper == null) synchronized(this) {
                  if (helper == null)
                      helper = new Helper();
              }
              return helper;
          }
          // other methods and fields...
      }

14. [參考] 使用volatile解決多線程內存不可見問題。

    • 對於一寫多讀，是可以解決變量同步問題，但是如果多寫，同樣無法解決線程安全問題。
    • 如果是count++操作，使用如下類實現：AtomicInteger count = new AtomicInteger(); count.addAndGet(1);
    • 如果是JDK8，推薦使用LongAdder對象，比AtomicLong性能更好（減少樂觀鎖的重試次數）。

15. [參考] HashMap在容量不夠進行resize時由於高併發可能出現死鏈，導致CPU飆升，在開發過程中可以使用其它數據結構或加鎖來規避此風險。

16. [參考] ThreadLocal無法解決共享對象的更新問題，ThreadLocal對象建議使用static修飾。

    • 這個變量是針對一個線程內所有操作共享的，所以設置爲靜態變量，所有此類實例共享此靜態變量，也就是說在類第一次被使用時裝載，只分配一塊存儲空間，所有此類的對象(只要是這個線程內定義的)都可以操控這個變量。