Java線程安全問題怎么解決

這期內容當中小編將會給大家帶來有關Java線程安全問題怎么解決，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

線程安全解決方案

synchronized,ReentrantLock,Atomic 使用場景描述

在實際開發過程中如果服務量，請求頻繁，就會經常碰見并發，這時候不做處理就會出現很多非法數據。這時候就需要解決線程安全的問題，這時候就可以使用java當中的鎖機制。常用有java關鍵synchronized、可重入鎖ReentrantLock，還有并發包下的Atomic 或者Concurrent的安全類型。

synchronized使用場景：

在資源競爭不是很激烈的情況下，偶爾出現并發，需要同步的情形下，synchronized是很合適的。原因在于，編譯程序通常會盡可能的進行優化synchronized，另外可讀性非常好，不管用沒用過5.0多線程包的程序員都能理解。可以多對方法進行加鎖（同步方法），也可以對對象進行加鎖（同步代碼快）。

  /**
   * synchronized用id
   */
  private static volatile Long syncId=0L;

  /**
   * synchronized方式獲取id 同步方法
   * @return
   */
  public static synchronized Long getSyncId1(){
    syncId++;
    return syncId;
  }

  /**
   * synchronized方式獲取id 同步代碼塊
   * @return
   */
  public static Long getSyncId2(){
    synchronized (syncId){
      syncId++;
      return syncId;
    }
  }

代碼可讀性強，畢竟是java的關鍵字，執行優先級高。synchronized關鍵字一放，就解決線程安全的問題。

但是還有一個問題，當前資源競爭激烈時，對于部分線程遲遲獲取不到鎖，這時候會出現一個鎖升級的過程，且鎖升級的過程是不可逆的。當從輕量級鎖到偏向鎖，再到一個重量級鎖。性能會大大的降低。

在資源競爭激烈可以使用其他方式來加鎖。

ReentrantLock使用場景:

ReentrantLock提供了多樣化的同步，比如有時間限制的同步，可以被Interrupt的同步（synchronized的同步是不能Interrupt的）等。在資源競爭不激烈的情形下，性能稍微比synchronized差點點。但是當同步非常激烈的時候，synchronized的性能一下子能下降好幾十倍。而ReentrantLock還能保證正常的性能。

且這個鎖可以定義成公平鎖還可以定義成非公平鎖。

  /**
   * ReentrantLock用id
   */
  private static volatile Long lockId=0L;

  /**
   * ReentrantLock公平鎖
   */
  private static final ReentrantLock reentrantLock = new ReentrantLock(true);


  /**
   * ReentrantLock方式獲取id
   * @return
   */
  public static Long getLockId(){
    reentrantLock.lock();
    try {
      lockId++;
      return lockId;
    }catch (Exception e){
      e.printStackTrace();
      return getLockId();
    }finally {
      reentrantLock.unlock();
    }
  }

我這里以公平鎖作為演示對象。ReentrantLock還可以查看鎖的狀態, 鎖是否被鎖上了.
可以查看當前有多少線程再等待鎖。但是因為ReentrantLock是悲觀鎖，加鎖時會對資源進行加鎖，當讀取頻繁時性能會不如CAS的樂觀鎖。所以讀取頻繁使用樂觀鎖，寫入頻繁使用悲觀鎖。

Atomic或者Concurrent使用場景:

和上面的類似，不激烈情況下，性能比synchronized略遜，而激烈的時候，也能維持常態。激烈的時候，Atomic的性能會優于ReentrantLock一倍左右。但是其有一個缺點，就是只能同步一個值，一段代碼中只能出現一個Atomic的變量，多于一個同步無效。因為他不能在多個Atomic之間同步。

  /**
   * Atomic用id
   */
  private static volatile AtomicLong atomicId=new AtomicLong(0L);

  /**
   * Atomic方式獲取id
   * @return
   */
  public static Long getAtomicId(){
    return atomicId.addAndGet(1);
  }

對于其他類型的比如和Map和Set可以使用用并發包下的ConcurrentHashMap和ConcurrentHashSet等線程安全的數據類型。

  /**
   * 線程安全的hashMap
   */
  private static ConcurrentHashMap<String,String> hashMap = new ConcurrentHashMap<>();
  
  public static void put(String key,String value){
    hashMap.put(key,value);
  }

  public static String get(String key{
    return hashMap.get(key);
  }

ConcurrentHashMap內部的實現是CAS的樂觀鎖，當鎖無法取得會開始自旋，直到下一次取得鎖。

上述就是小編為大家分享的Java線程安全問題怎么解決了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。