Java併發-組合對象

可見性

可見性至關微妙，發生的錯誤可能與直覺截然不同。在單線程環境中，向一個變量寫入值，而後在沒有干涉的狀況下讀取這個值，很天然的會但願獲得相同的值。可是當讀寫發生在不一樣的線程中，狀況可能就不同了。爲了確保跨線程的內存可見性，必須使用同步機制。

public class NonVisibility {

	static boolean ready = false;
	static int num = 0;

	static class ReadThread extends Thread {
		@Override
		public void run() {
			while (!ready) {
				Thread.yield();
			}
			System.err.println(num);
		}
	}

	public static void main(String[] args) {
		new ReadThread().start();
		num = 42;
		ready = true;
	}
}
複製代碼

**「重排序」**現象，在單個線程中，只要對結果不會產生影響，就不能保證其中的操做會嚴格按照寫定的順序執行-即便重排序會對其餘線程形成影響。

過時數據

在NonVisibility中，過時數據致使打印錯誤，在生產環境中，過時值可能致使程序的崩潰，髒數據的產生，錯誤的計算或者無限的循環。

非原子的64位操做

非volitile的long和double數據在JVM中容許分開成兩個32位進行操做，這時使用volitile或者同步機制能夠解決。

鎖和可見性

內置鎖能夠用來確保一個線程以某種可預見的方式看到另外一個線程的影響，當B執行到與A相同的鎖監視的同步塊時，A同步塊以前所作的事情，對B都是可見的。若是沒有同步，就沒有這樣的保證。

鎖不只僅是同步互斥的，也能夠是內存可見的。
爲了保證全部線程都能看到共享的、可變變量的最新值，讀取和寫入線程必須使用公共的鎖進行同步。
複製代碼

{% asset_img 1561172279707.png 同步對可見性的保證 %}

volitile變量

當一個域聲明爲volatile類型後，編譯器和運行時會監視這個變量：它是共享的，對它的操做不會與其餘內存操做一塊兒被重排序。volatile變量不會緩存到寄存器或處理器其餘地方。因此讀取volatile變量時，老是返回最新的數據。

理解volatile變量時，能夠想象其與下面的代碼功能大體相似。只不過get和set方法取代了對volatile變量的讀寫操做。可是訪問volatile變量的操做不會加鎖，也不會有執行線程的阻塞，因此volatile相對sychronized而言只是一種輕量級的同步機制。

public int value;
public sychronized int get() {
	return value;
}
public sychronized void set(int value) {
	this.value = value;
}
複製代碼

從內存可見角度看，寫入volatile變量就像退出了同步塊，讀取volatile變量就像進入同步塊。可是不推薦依賴volatile變量來控制可見性，volatile極其脆弱並且並不直觀。

只有當volatile變量可以簡化實現和同步策略的驗證，才使用它們。
正確使用volatile變量的方式：
用於確保它們所引用的對象狀態的可見性，或者用於表示重要的生命週期事件的發生。
複製代碼

volatile變量當然方面，但也存在限制。一般volatile被當作標識完成、中斷、狀態的標記使用。使用volatile必須格外當心，好比volatile不能讓自增操做（count++）原子化，除非只有一個線程進行操做。

加鎖能夠保證可見性和原子性，可是volatile只能保證可見性。
複製代碼

發佈和溢出

發佈（publish）一個對象是其可以被當前範圍以外的代碼所使用。又是須要確保對象內部狀態不被暴露。若是變量發佈了內部狀態可能危及到封裝性，並使程序難以維持穩定；若是發佈對象，尚未完成構造，一樣危及線程安全。一個對象在還沒有準備好就進行發佈，就稱爲溢出。下面爲對象溢出的例子。

// 發佈對象
public static final Map<Integer, String> map;
public void init() {
	map = new HashMap<>();
}
複製代碼

// 容許內部可變數據溢出
class UsafeState{
    private String[] states = new String[]{"XA", "TCC"};
    public String[] getStates() {
        return states;
    }
}
複製代碼

// 隱式地容許this引用溢出，由於內部被包含了隱式的引用
class Escape {
    public Escape(EventSource source) {
   		source.addEventListener(new EventListener() {
          	public void onClick(Event event) {
                doSomethine(event);
            }  
        });    
    }
}
複製代碼

安全構建實踐

對象至於在構造函數返回後，纔是一個可預言、穩定的狀態。若是this引用在構造過程當中溢出，這樣的對象被認爲是"沒有正確構建的"。

不要讓this引用在構造期間溢出。
複製代碼

一個常見的致使this引用在構造期間溢出的常見錯誤，是在構造函數中啓動一個線程。不管是顯示的（經過它傳遞給構造函數）仍是隱式的，this引用幾乎總被新線程共享。在構造函數建立線程沒有錯，可是最好不要先啓動它，在構造函數結束後經過一個start方法進行啓動。

若是要在構造器中增長監聽或者啓動線程，可使用一個私有函數或者工廠方法。

public class SafeListener {
    private final EventListener listener;
    public SafeListener() {
        this.listener = new EventListener() {
            public void onClick(Event e) {
                doSomethin(e);
            }
        };
    }
    public static SafeListener newInstance(EventSource source) {
        SafeListener sl = new SafeListener();
        source.addListener(sl.listener);
        return sl;
    }
}
複製代碼

線程封閉

線程封閉是實現線程安全的最簡單的方式之一。當對象封閉在一個線程中，這種作法自動稱爲線程安全的。

Swing發展了線程封閉技術。Swing的可視化組件和數據模型並非線程安全的，經過將它們限制到Swing的事件分發線程中實現線程安全。

Ad-hoc線程限制

指維護線程限制性的任務所有落在實現上。由於沒有可見性修飾符與本地變量等語言特性協助將對象限制在目標線程上，因此這種方法很容易出錯。鑑於ad-hoc線程限制具備易損性，應當節制使用它。用一種線程限制的強形式（棧限制或ThreadLocal）取代它。

棧限制是線程限制的一種特例，只能經過本地變量才能觸及對象。其餘線程沒法訪問。與ad-hoc相比更容易維護，更健壯。

public int loadTheArk(Collection<Animal> candidates) {
	SortedSet<Animal> animals;
    int numPairs=0;
    // animals 限制在方法中，不要讓它們逸出！
    animals = new TreeSet<>();
    animals.addAll(candidates);
    .....
}
複製代碼

維護對象引用的棧限制，須要保證引用的對象沒有逸出。在線程內部上下文使用非線程安全的對象仍然能夠保證線程的安全性。可是一線開發任務編碼的那一刻須要清楚的文檔化，防止後期維護人員錯誤的聽任對象溢出。

ThreadLocal

一般用於可變的單例或全局變量設計中，出現共享。每一個線程單獨維護一個變量，這樣就能夠防止併發問題。

private static ThreadLocal<Connection> connectionHolder = new ThreadLocal<>() {
	public Connection initialValue() {
		return DriverManager.getConnection(DB_URL);
	}
}
public static Connection getConnection() {
	return connectionHolder.get();
}
複製代碼

在Netty的ByteBuf中，就是利用ThreadLocal去進行byte數組的分配，防止接受請求頻繁建立byte數組，這樣既能夠節省內存、又能夠併發問題。

ThreadLocal很容易濫用：好比將他們所封閉的數據做爲全局變量的許可證。線程本地變量會下降重用性，引入隱晦的類間耦合，應當謹慎的使用。

不可變性

不可變對象永遠是線程安全的。final關鍵字是構成不可變對象的一部分，被final修飾的對象仍然多是可變的。

即時發佈對象的時沒有使用同步，不可變對象仍然能夠被安全地訪問。

安全發佈模式

• 靜態初始化生成的對象。
• 引用存儲到volatile或AtomicReference中。
• 引用正確的存儲到final域中。
• 引用存儲由鎖正確保護的域中。

高效不可變對象

一個對象在技術上不是不可變的，可是它的狀態在發佈後不會發生變化，被稱爲有效不可變對象。

// Date自己是可變的，把它當作不可變對象就能夠忽略鎖。
// 放入到同步化的Map中訪問Date就不須要考慮同步的問題了。
Collections.sychronizedMap(new HashMap<String, Date>);
複製代碼