Java 併發編程（二）對象的不變性和安全的公佈對象

時間 2019-11-05

原文原文鏈接

1、不變性

知足同步需求的還有一種方法是使用不可變對象（Immutable Object）。java

到眼下爲止，咱們介紹了不少與原子性和可見性相關的問題，好比獲得失效數據。丟失更新操做或光查到某個對象處於不一致的狀態等等，都與多線程視圖同一時候訪問同一個可變的狀態相關。假設對象的狀態不會改變，那麼這些問題與複雜性也就天然消失了。緩存

假設某個對象在被建立後其狀態就不能被改動，那麼這個對象就被成爲不可變對象。線程安全型是不可變對象的固有屬性之中的一個，他們的不變性條件是由構造函數建立的，僅僅要他們的狀態不改變，那麼這些不變性條件就能得以維持。安全

不可變對象很是easy。他們僅僅有一種狀態，並且該狀態由構造函數來控制。在程序設計中一個最困難的地方就是推斷複雜對象的可能狀態。然而，推斷不可變對象的狀態卻很是easy。多線程

儘管在 Java 規範和 Java 內存模型中都沒有給出不可變性的正式定義，但不可變性並不等於將對象中所有的域都聲明爲 final 類型，即便對象中所有的域都是 final 類型的，這個對象也仍然是可變的，因爲在 final 類型的域中可以保存對可變對象的引用。併發

當知足下面條件時，對象纔是不可變的：函數

對象建立完以後其狀態就不能改動
對象的所有與都是 final 類型
對象時正確建立的（建立期間沒有 this 的逸出）

咱們來分析如下這個類。

@Immutable
public final class ThreeStooges {
    private final Set<String> stooges = new HashSet<String>();

    public ThreeStooges() {
        stooges.add("Moe");
        stooges.add("Larry");
        stooges.add("Curly");
    }

    public boolean isStooge(String name) {
        return stooges.contains(name);
    }
}

在不可變對象的內部仍可以使用可變對象來管理它們的狀態。如 ThreeStooges 所看到的。雖然保存姓名的Set對象是可變的，但從ThreeStooges的設計中可以看到。在Set對象構造完畢後沒法對其進行改動。stooges是一個final類型的引用變量，所以所有的對象狀態都經過一個final域來訪問。最後一個要求是「正確地構造對象」。這個要求很是easy知足，因爲構造函數能使該引用由除了構造函數及其調用者以外的代碼來訪問。

由於程序的狀態總在不斷地變化，你可能會以爲需要使用不可變對象的地方很少。但實際狀況並非如此。post

在「不可變的對象」與「不可變的對象引用」之間存在着差別。性能

保存在不可變對象中的程序狀態仍然可以更新，即經過將一個保存新狀態的實例來「替換」原有的不可變對象。this

Final 域

keyword final 可以視爲 C++ 中 const 機制的一種受限版本號，用於構造不可變對象。final 類型的域是不能改動的（但假設 final 域所引用的對象時可變的，那麼這些被引用的對象是可以改動的）。然而，在 Java 內存模型中，final 域還有着特殊的語義。final 域能確保初始化過程的安全性。從而可以不受限制的訪問不可變對象，並在共享這些對象時無需同步。url

注：我的理解爲，final 字段一旦被初始化完畢。而且構造器沒有把 this 引用傳遞出去，那麼在其它線程中就能看到 final 字段的值（域內變量可見性，和 volatile 相似），而且其外部可見狀態永遠也不會改變。它所帶來的安全性是最簡單最純粹的。

注：即便對象是可變的，經過將對象的某些域聲明爲final類型。仍然可以簡化對狀態的推斷。所以限制對象的可變性也就至關於限制了該對象可能的狀態集合。僅包括一個或兩個可變狀態的「基本不可變」對象仍然比包括多個可變狀態的對象簡單。經過將域聲明爲final類型，也至關於告訴維護人員這些域是不會變化的。

正如「除非需要更高的可見性，不然應將所有的餓域都聲明爲私有域」[EJ Item 12]是一個良好的變成習慣，「除非需要某個域是可變的，不然應將其聲明爲final域」也是一個良好的變成習慣。

演示樣例：使用 Volatile 類型來公佈不可變對象

以前咱們講過， volatile 可以用來保證域的可見性而不能保證變量操做的原子性，更爲準確的講。僅僅能保證讀寫操做具備原子性，而不能保證自增 i++ 等運算操做的原子性。

在前面的UnsafeCachingFactorizer類中，咱們嘗試用兩個AtomicReferences變量來保存最新的數值及其因數分解結果，但這樣的方式並非是線程安全的，因爲咱們沒法以原子方式來同一時候讀取或更新這兩個相關的值。相同。用volatile類型的變量來保存這些值也不是線程安全的。然而，在某些狀況下，不可變對象能提供一種弱形式的原子性。

因式分解Servlet將運行兩個原子操做：更新緩存的結果，以及經過推斷緩存中的數值是否等於請求的數值來決定是否直接讀取緩存中的因數分解結果。

每當需要對一組相關數據以原子方式運行某個操做時，就可以考慮建立一個不可變的類來包括這些數據，好比 OneValueCache。

@Immutable
class OneValueCache {
    private final BigInteger lastNumber;
    private final BigInteger[] lastFactors;

    /**
     * 假設在構造函數中沒有使用 Arrays.copyOf()方法。那麼域內不可變對象 lastFactors卻能被域外代碼改變
     * 那麼 OneValueCache 就不是不可變的。
     */
    public OneValueCache(BigInteger i,
                         BigInteger[] factors) {
        lastNumber  = i;
        lastFactors = Arrays.copyOf(factors, factors.length);
    }

    public BigInteger[] getFactors(BigInteger i) {
        if (lastNumber == null || !lastNumber.equals(i))
            return null;
        else
            return Arrays.copyOf(lastFactors, lastFactors.length);
    }
}

對於在訪問和更新多個相關變量時出現的競爭條件問題，可以經過將這些變量全部保存在一個不可變對象中來消除。

假設是一個可變的對象，那麼就必須使用鎖來確保原子性。

假設是一個不可變對象，那麼當線程得到了對該對象的引用後，就沒必要操心還有一個線程會改動對象的狀態。假設要更新這些變量。那麼可以建立一個新的容器對象。但其它使用原有對象的線程仍然會看到對象處於一致的狀態。

在 VolatileCachedFactorizer使用了OneValueCache來保存緩存的數值及其因數。咱們將 OneValueCache 聲明爲 volatile，這樣當一個線程將cache設置爲引用一個新的OneValueCache時，其它線程就會立刻看到新緩存的數據。

@ThreadSafe
public class VolatileCachedFactorizer implements Servlet {
    private volatile OneValueCache cache =
        new OneValueCache(null, null);

    public void service(ServletRequest req, ServletResponse resp) {
        BigInteger i = extractFromRequest(req);
        BigInteger[] factors = cache.getFactors(i);
        if (factors == null) {
            factors = factor(i);
            cache = new OneValueCache(i, factors);//聲明爲 volatile 。防止指令重排序，保證可見性
        }
        encodeIntoResponse(resp, factors);
    }
}

與cache相關的操做不會相互干擾。因爲OneValueCache是不可變的。並且在每條對應的代碼路徑中僅僅會訪問它一次。經過使用包括多個狀態變量的容器對象來維持不變性條件。並使用一個volatile類型的引用來確保可見性，使得Volatile Cached Factorizer在沒有顯式地使用鎖的狀況下仍然是線程安全的。

2、安全公佈

到眼下爲止，咱們重點討論的是怎樣確保對象不被公佈，好比讓對象封閉在線程或還有一個對象的內部。固然，在某些狀況下咱們但願在多個線程間共享對象，此時必須確保安全地進行共享。然而，假設僅僅是像如下程序那樣將對象引用保存到公有域中，那麼還不足以安全地公佈這個對象。

//不安全的公佈
public Holder holder;

public void initialize() {
    holder = new Holder(42);
}

你可能會奇怪。這個看似沒有問題的演示樣例何以會執行失敗。

由於存在可見性問題，其它線程看到的Holder對象將處於不一致的狀態，即使在該對象的構造函數中已經正確地構建了不變性條件。這樣的不對的公佈致使其它線程看到還沒有建立完畢的對象。

不對的公佈：正確的對象被破壞

你不能期望一個還沒有被全然建立的對象擁有完整性。某個觀察該對象的線程將看到對象處於不一致的狀態。而後看到對象的狀態忽然發生變化，即便線程在對象公佈後尚未改動過它。其實，假設如下程序中的Holder使用前面程序中的不安全公佈方式，那麼還有一個線程在調用assertSanity時將拋出AssertionError。

public class Holder {
    private int n;

    public Holder(int n) { this.n = n; }

    public void assertSanity() {
        if (n != n)
            throw new AssertionError("This statement is false.");
    }
}

由於沒有使用同步來確保Holder對象對其它線程可見，所以將Holder稱爲「未被正確公佈」。在未被正確公佈的對象中存在兩個問題。

首先，除了公佈對象的線程外，其它線程可以看到的Holder域是一個失效值。所以將看到一個空引用或者以前的舊值。

然而，更糟糕的狀況是，線程看到Holder引用的值是最新的，但Holder狀態的值倒是失效的。狀況變得更加不可預測的是，某個線程在第一次讀取域時獲得失效值，而再次讀取這個域時會獲得一個更新值。這也是assertSainty拋出AssertionError的緣由。

假設沒有足夠的同步，那麼當在多個線程間共享數據時將發生一些很奇怪的事情。

不可變對象與初始化安全性

由於不可變對象是一種很重要的對象，所以Java內存模型爲不可變對象的共享提供了一種特殊的初始化安全性保證。咱們已經知道，即便某個對象的引用對其它線程是可見的，也並不意味着對象狀態對於使用該對象的線程來講必定是可見的。爲了確保對象狀態能呈現出一致的視圖，就必須使用同步。

還有一方面。即便在公佈不可變對象的引用時沒有使用同步，也仍然可以安全地訪問該對象。

爲了維持這樣的初始化安全性的保證。必須知足不可變性的所有需求：狀態不可改動，所有域都是final類型。以及正確的構造過程。（假設Holder對象是不可變的，那麼即便Holder沒有被正確地公佈。在assertSanity中也不會拋出AssertionError。

）

不論什麼線程都可以在不需要額外同步的狀況下安全地訪問不可改變對象，即便在公佈這些對象時沒有使用同步。

這樣的保證還將延伸到被正確建立對象中所有final類型的域。在沒有額外同步的狀況下，也可以安全地訪問final類型的域。然而。假設final類型的域所指向的是可變對象。那麼在訪問這些域所指向的對象的狀態時仍然需要同步。

安全公佈的常用模式

可變對象必須經過安全的方式來公佈，這一般意味着在公佈和使用該對象的線程時都必須使用同步。

現在，咱們將重點介紹怎樣確保使用對象的線程能夠看到該對象處於已公佈的狀態。並稍後介紹怎樣在對象公佈後對其可見性進行改動。

安全地公佈一個對象。對象的應用以及對象的狀態必須同一時候對其它線程可見。一個正確構造的對象可以經過下面方式來安全地公佈：

在靜態初始化函數中初始化一個對象引用
將對象的應用保存到volatile類型的域或者AtomicReferance對象中
將對象的引用保存到某個正確構造對象的final類型域中
將對象的引用保存到一個由鎖保護的域中。

在線程安全容器內部的同步意味着，在將對象放入到某個容器。好比Vector或synchronizedList時，將知足上述最後一條需求。假設線程A將對象X放入一個線程安全的容器。隨後線程B讀取這個對象，那麼可以確保B看到A設置的X狀態，即使在這段讀/寫X的應用程序代碼中沒有包括顯式的同步。雖然Javadoc在這個主題上沒有給出很是清晰的說明，但線程安全庫中的容器類提供了下面的安全公佈保證：

經過將一個鍵或者值放入Hashtable、synchronizedMap或者ConcurrentMap中，可以安全地將它公佈給不論什麼從這些容器中訪問它的線程（不論是直接訪問仍是經過迭代器訪問）
經過將某個元素放入Vector、CopyOnWriteArrayList、CopyOnWriteArraySet、synchronizedList或synchronizedSet中，可以將該元素安全地公佈到不論什麼從這些容器中訪問該元素的線程
經過將某個元素放入BlockingQueue或者ConcurrentLinkedQueue中，可以將該元素安全地公佈到不論什麼從這些隊列中訪問該元素的線程。

類庫中的其它數據傳遞機制（好比Future和Exchanger）相同能實現安全公佈。在介紹這些機制時將討論它們的安全公佈功能。

一般，要公佈一個靜態構造的對象，最簡單和最安全的方式是使用靜態的初始化器：
public static Holder holder = new Holder(42);

靜態初始化器由JVM在類的初始化階段運行。

由於在JVM內部存在着同步機制，所以經過這樣的方式初始化的不論什麼對象都可以被安全地公佈[JLS 12.4.2]。

事實不可變對象

假設對象在公佈後不會被改動，那麼對於其它在沒有額外同步的狀況下安全地訪問這些對象的線程來講，安全公佈是足夠的。所有的安全公佈機制都能確保。當對象的引用對所有訪問該對象的線程可見時，對象公佈時的狀態對於所有線程也將是可見的，並且假設對象狀態不會再改變，那麼就足以確保不論什麼訪問都是安全的。

假設對象從技術上來看是可變的，但其狀態在公佈後不會再改變。那麼把這樣的對象稱爲「事實不可變對象（Effectively Immutable Object）」。這些對象不需要知足以前提出的不可變性的嚴格定義。在這些對象公佈後。程序僅僅需將它們視爲不可變對象就能夠。經過使用事實不可變對象。不只可以簡化開發過程，而且還能由於下降了同步而提升性能。

在沒有額外的同步的狀況下，不論什麼線程都可以安全地使用被安全公佈的事實不可變對象。

好比，Date自己是可變的，但若是將它做爲不可變對象來使用，那麼在多個線程之間共享Date對象時，就可以省去對鎖的使用。

若是需要維護一個Map對象，當中保存了每位用戶的近期登陸時間：
public Map<String, Date> lastLogin =Collections.synchronizedMap(new HashMap<String, Date>());

假設Date對象的值在被放入Map後就不會改變，那麼synchronizedMap中的同步機制就足以使Date值被安全地公佈。並且在訪問這些Date值時不需要額外的同步。