Java多線程的同步優化的6種方案

Posted on by

概述

處理器上的寄存器的讀寫的速度比內存快幾個數量級，為瞭解決這種速度矛盾，在它們之間加入瞭高速緩存。

加入高速緩存帶來瞭一個新的問題：緩存一致性。如果多個緩存共享同一塊主內存區域，那麼多個緩存的數據可能會不一致，需要一些協議來解決這個問題。

在Java內存模型中，分為主內存和線程工作內存，線程使用共享數據時，先從主內存中拷貝數據到工作內存，使用完成之後再寫入主內存中。

在Java中，有多線程並發時，我們可以使用多線程同步的方式來解決內存一致性的問題。通常我們可以在程序中添加同步鎖來保障數據的安全訪問，但是也經常會帶來一些同步性能問題，那麼本章將針對常見的同步問題給出瞭一些優化方案。

讀寫鎖

在多線程操作下，如果我們的某些數據經常被讀取操作，但非常少的時機被寫入操作。這時，如果我們使用synchronized等同步方式，性能會非常低。

這種場景下，我們應該使用讀寫鎖來進行優化。

讀寫鎖的特點：

  • 讀寫鎖維護一對鎖，讀鎖和寫鎖。
  • 可以共享讀，但隻能一個寫。
  • 讀讀不互斥，讀寫互斥，寫寫互斥。

某些特定的場景，使用讀寫鎖會極大的提高多線程並發操作的效率。因為，讀寫鎖中，讀鎖不是排它鎖，所以可以並發執行，可以非常顯著的提高讀取效率；隻有在寫鎖時，是排它鎖，這時需要等待寫鎖的釋放。

ReetrantReadWriteLock

ReadWriteLock接口

Java並發包中ReadWriteLock是一個接口，抽象瞭讀寫鎖方法：

public interface ReadWriteLock {
    /**
     * Returns the lock used for reading.
     *
     * @return the lock used for reading
     */
    Lock readLock();

    /**
     * Returns the lock used for writing.
     *
     * @return the lock used for writing
     */
    Lock writeLock();
}

ReadWriteLock管理一組鎖，一個是隻讀的鎖，一個是寫鎖。

ReetrantReadWriteLock類

Java並發庫中ReetrantReadWriteLock實現瞭ReadWriteLock接口並添加瞭可重入的特性。

1. ReetrantReadWriteLock獲取鎖順序有兩種模式：

  • 非公平模式（默認）：非公平鎖主張競爭獲取，可能會延緩一個或多個讀或寫線程，但是會比公平鎖有更高的吞吐量。
  • 公平模式：當以公平模式初始化時，線程將會以隊列的順序獲取鎖。

2. 可重入

ReetrantReadWriteLock鎖是可重入的，當然一個線程獲取多少次鎖，就必須釋放多少次鎖。

  • 讀線程獲取讀鎖之後能夠再次獲取讀鎖。
  • 寫線程獲取寫鎖之後能再次獲取寫鎖，也可以獲取讀鎖。

3. 鎖降級

在讀寫鎖中，鎖降級：從寫鎖變成讀鎖；鎖升級：從讀鎖變成寫鎖。

  • ReentrantReadWriteLock是不支持鎖升級的，也就是當一個線程持有瞭讀鎖，當該線程再次使用寫鎖時，是不可以的。如果一個線程持有瞭讀鎖，則在獲取寫鎖之前，一定要先釋放讀鎖。
  • ReentrantReadWriteLock支持鎖降級的，也就是如果當前線程是寫鎖的持有者，並保持獲得寫鎖的狀態，同時又獲取到讀鎖，然後釋放寫鎖的過程。按照獲取寫鎖、獲取讀鎖、再釋放寫鎖的順序，即寫鎖能夠降級為讀鎖。

讀寫鎖狀態的設計

讀寫鎖的狀態是用一個int值來表示的。state（int32位）字段分成高16位與低16位，其中高16位表示讀鎖個數，低16位表示寫鎖個數。

例如，當前一個線程獲取到瞭寫鎖，並且重入瞭兩次，因此低16位是3，並且該線程又獲取瞭讀鎖，並且重入瞭一次，所以高16位是2，當寫鎖被獲取時如果讀鎖不為0那麼讀鎖一定是獲取寫鎖的這個線程。

寫時復制

寫時復制（Copy-on-write，簡稱COW）是一種計算機程序設計領域的優化策略。其核心思想是，如果有多個調用者同時要求相同資源，他們會共同獲取相同的指針指向相同的資源，直到某個調用者試圖修改資源的內容時，系統才會真正復制一份專用副本給該調用者，而其他調用者所見到的最初的資源仍然保持不變。這過程對其他的調用者都是透明的。此作法主要的優點是如果調用者沒有修改該資源，就不會有副本被創建，因此多個調用者隻是讀取操作時可以共享同一份資源。

在Java中，Copy on Write這種機制通常用在集合上，在並發訪問的情景下，當需要修改JAVA中Containers的元素時，不直接修改該容器，而是先復制一份副本，在副本上進行修改。修改完成之後，將指向原來容器的引用指向新的容器（副本容器）。

寫時復制的特點

  • 由於不會修改原始容器，隻修改副本容器。因此，可以對原始容器進行並發地讀。其次，實現瞭讀操作與寫操作的分離，讀操作發生在原始容器上，寫操作發生在副本容器上。
  • 數據一致性問題：因為修改操作發生在副本上，讀操作的線程可能不會立即讀取到新修改的數據內容，但最終修改操作會完成並更新容器，因此這是最終一致性。
  • CopyOnWrite容器適用於讀多寫少的場景。寫操作時，需要復制一個容器，會造成很大的內存開銷。
  • 不適合於數據的強一致性場合。若要求數據修改之後立即能被讀到，則不能用寫時復制技術。因為它是最終一致性。

Java寫時復制容器類

JDK中提供瞭CopyOnWriteArrayList類和CopyOnWriteArraySet類，實現瞭寫時復制。

減小鎖的粒度

如果我們在一個大的數據操作類裡面，大量使用瞭鎖，並且還是同一個鎖，這時，我們的多線程同步效率就會變得非常低。

我們可以將數據按照不同的類型及應用場景進行分割，然後用不同的鎖進行同步，這樣，不同的場景下就不會產生排它鎖的沖突問題，可以大大提高同步的效率。

該方案簡單來說就是將一個大鎖，分割成多個小鎖，這樣就能顯著的提高多線程並發執行的效率。

減小鎖的占有時間

如果在一個較大的方法中，我們直接給該方法加瞭一個鎖，但是我們需要同步的地方隻是該方法中的一行操作代碼，這樣就是很糟糕的同步使用方式瞭。

我們可以將鎖細化到使用它的代碼行上，而不是整個函數都加鎖，這樣鎖的持有時間就會變少，從而提高瞭多線程同步的性能。

該方案是將同步塊的代碼范圍減小，從而降低鎖的持有時間，達到優化多線程同步性能的目的。

鎖粗化

雖然說，減少鎖的占有時間可以提高性能，但是有時候，這種方式並不適用。

例如，一個循環中，我們在循環體中，使用瞭鎖，這樣反而會降低性能，這時我們應該在循環開始之前加鎖，結束之後釋放，也就是將鎖粗化。

這是為什麼呢？

這是因為，頻繁的對鎖進行請求、釋放、狀態修改等操作，會造成大量系統資源的消耗，從而降低性能。

ThreadLocal

同步效率低，是因為多線程同步等待造成的，那麼我們可以換一個思路，如果讓每個線程都持有一份數據，那這樣就不會存在競爭的問題瞭，也就不需要同步鎖瞭。這樣就會很大程度上提高多線程並發的性能。

關於ThreadLocal相關實現原理及使用可以參考之前的文章《ThreadLocal線程本地對象原理分析》。

總結

Java中可以使用鎖來解決多線程的同步問題，保障瞭數據的一致性，但也會代理很多問題，本章總結瞭多線程同步的幾種優化方案：

  • 某些特定的場景（大多是讀多、寫少的場景），使用讀寫鎖會極大的提高多線程並發操作的效率。因為，讀寫鎖中，讀鎖不是排它鎖，所以可以並發執行，可以非常顯著的提高讀取效率；隻有在寫鎖時，是排它鎖，這時需要等待寫鎖的釋放。
  • Java並發庫中ReetrantReadWriteLock實現瞭ReadWriteLock接口並添加瞭可重入的特性。
  • 寫時復制機制可以顯著提高並發效率，在並發訪問的情景下，當需要修改JAVA中Containers的元素時，不直接修改該容器，而是先復制一份副本，在副本上進行修改。修改完成之後，將指向原來容器的引用指向新的容器（副本容器）。CopyOnWrite容器適用於讀多寫少的場景。寫操作時，需要復制一個容器，會造成很大的內存開銷。
  • 通過減小鎖的粒度，來提高同步效率。
  • 減小鎖的占有時間是指，通過將同步塊的代碼范圍減小，從而降低鎖的持有時間，達到優化多線程同步性能的目的。
  • 有時，大量的鎖和鎖狀態修改會造成系統資源的消耗，我們可以通過鎖粗化來優化性能。
  • 我們可以換一個思路，使用ThreadLocal來提高多線程並發的性能。

到此這篇關於Java多線程的同步優化的6種方案的文章就介紹到這瞭,更多相關Java多線程同步優化內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：