![](http://img.blog.itpub.net/blog/2020/04/09/6d0665c9ce96a9ef.png?x-oss-process=style/bb)

如果沒有特別說明，以下原始碼分析基於 JDK 1.8。

# CopyOnWriteArrayList

**1.讀寫分離**

寫操作在一個複製的陣列上進行，讀操作還是在原始陣列中進行，讀寫分離，互不影響。

寫操作需要加鎖，防止併發寫入時導致寫入資料丟失。

寫操作結束之後需要把原始陣列指向新的複製陣列。
```
public Boolean add(E e) {
	//加鎖
	final ReentrantLock lock = this.lock;
	lock.lock();
	try {
		Object[] elements = getArray();
		int len = elements.length;
		// newElements 是一個複製的陣列
		Object[] newElements = Arrays.copyOf(elements, len + 1);
		newElements[len] = e;
		// 寫操作在一個複製的陣列上進行
		setArray(newElements);
		return true;
	}
	finally {
		lock.unlock();
	}
}
final void setArray(Object[] a) {
	array = a;
}
```

```
@SuppressWarnings("unchecked")
private E get(Object[] a, int index) {
	//讀取操作仍然在原始的陣列中
	return (E) a[index];
}
```
**2.適用場景**

CopyOnWriteArrayList 在寫操作的同時允許讀操作，大大提高了讀操作的效能，很適合讀多寫少的應用場景。

CopyOnWriteArrayList 有其缺陷：

- 記憶體佔用：在寫操作時需要複製一個新的陣列，使得記憶體佔用為原來的兩倍左右；
- 資料不一致：讀操作不能讀取實時性的資料，因為部分寫操作的資料還未同步到讀陣列中。

所以 CopyOnWriteArrayList 不適合記憶體敏感以及對實時性要求很高的場景。

# 二、ConcurrentHashMap

**1. 儲存結構**
```
static final class HashEntry<k> {
    final int hash;
    final K key;
    volatile V value;
    volatile HashEntry<k> next;
}
```
ConcurrentHashMap 和 HashMap 實現上類似，最主要的差別是 ConcurrentHashMap 採用了分段鎖（Segment），每個分段鎖維護著幾個桶（HashEntry），多個執行緒可以同時訪問不同分段鎖上的桶， 從而使其併發度更高（併發度就是 Segment 的個數）。

Segment 繼承自 ReentrantLock。
```
static final class Segment<k> extends ReentrantLock implements Serializable {
	private static final long serialVersionUID = 2249069246763182397L;
	static final int MAX_SCAN_RETRIES =
	        Runtime.getRuntime().availableProcessors() > 1 ? 64 : 1;
	transient volatile HashEntry<k>[] table;
	transient int count;
	transient int modCount;
	transient int threshold;
	final float loadFactor;
}
```

```
final Segment<k>[] segments;
```
預設的併發級別為 16，也就是說預設建立 16 個 Segment。
```
static final int DEFAULT_CONCURRENCY_LEVEL = 16;
```
**2. size 操作**
每個 Segment 維護了一個 count 變數來統計該 Segment 中的鍵值對個數。
```
/**
 * The number of elements. Accessed only either within locks
 * or among other volatile reads that maintain visibility.
 */
transient int count;
```
在執行 size 操作時，需要遍歷所有 Segment 然後把 count 累計起來。

ConcurrentHashMap 在執行 size 操作時先嚐試不加鎖，如果連續兩次不加鎖操作得到的結果一致，那麼可以認為這個結果是正確的。

嘗試次數使用 RETRIES_BEFORE_LOCK 定義，該值為 2，retries 初始值為 -1，因此嘗試次數為 3。

如果嘗試的次數超過 3 次，就需要對每個 Segment 加鎖。
```
/**
 * Number of unsynchronized retries in size and containsValue
 * methods before resorting to locking. This is used to avoid
 * unbounded retries if tables undergo continuous modification
 * which would make it impossible to obtain an accurate result.
 */
static final int RETRIES_BEFORE_LOCK = 2;
public int size() {
	// Try a few times to get accurate count. On failure due to
	// continuous async changes in table, resort to locking.
	final Segment<k>[] segments = this.segments;
	int size;
	Boolean overflow;
	// true if size overflows 32 bits
	long sum;
	// sum of modCounts
	long last = 0L;
	// previous sum
	int retries = -1;
	// first iteration isn't retry
	try {
		for (;;) {
			// 超過嘗試次數，則對每個 Segment 加鎖
			if (retries++ == RETRIES_BEFORE_LOCK) {
				for (int j = 0; j < segments.length; ++j)
				                    ensureSegment(j).lock();
				// force creation
			}
			sum = 0L;
			size = 0;
			overflow = false;
			for (int j = 0; j < segments.length; ++j) {
				Segment<k> seg = segmentAt(segments, j);
				if (seg != null) {
					sum += seg.modCount;
					int c = seg.count;
					if (c < 0 || (size += c) < 0)
					                        overflow = true;
				}
			}
			// 連續兩次得到的結果一致，則認為這個結果是正確的
			if (sum == last)
			                break;
			last = sum;
		}
	}
	finally {
		if (retries > RETRIES_BEFORE_LOCK) {
			for (int j = 0; j < segments.length; ++j)
			                segmentAt(segments, j).unlock();
		}
	}
	return overflow ? Integer.MAX_VALUE : size;
}
```
**3. JDK 1.8 的改動**

ConcurrentHashMap 取消了 Segment 分段鎖。

JDK 1.8 使用 CAS 操作來支援更高的併發度，在 CAS 操作失敗時使用內建鎖 synchronized。

資料結構與HashMap 1.8 的結構類似，陣列+連結串列 / 紅黑二叉樹（連結串列長度 > 8 時，轉換為紅黑樹 ）。synchronized 只鎖定當前連結串列或紅黑二叉樹的首節點，這樣只要 Hash 值不衝突，就不會產生併發。

**4. JDK 1.8 中的 put 方法**

①. hash 演算法
```
static final int spread(int h) {
    return (h ^ (h >>> 16)) & HASH_BITS;
}
```

②. 定位索引位置
```
i = (n - 1) & hash
```

③. 獲取 table 中對應索引的元素 f
```
f = tabAt(tab, i = (n - 1) & hash
// Unsafe.getObjectVolatile 獲取 f
// 因為可以直接指定記憶體中的資料，保證了每次拿到的資料都是新的
static final <k> Node<k> tabAt(Node<k>[] tab, int i) {
    return (Node<k>)U.getObjectVolatile(tab, ((long)i << ASHIFT) + ABASE);
}Copy to clipboardErrorCopied
```

④. 如果 f 是 null，說明 table 中是第一次插入資料，利用

- 如果 CAS 成功，說明 Node 節點插入成功
- 如果 CAS 失敗，說明有其他執行緒提前插入了節點，自旋重新嘗試在該位置插入 Node

⑤. 其餘情況把新的 Node 節點按連結串列或紅黑樹的方式插入到合適位置，這個過程採用內建鎖實現併發。

**5. 和 Hashtable 的區別**

①. 底層資料結構：

- JDK1.7 的ConcurrentHashMap底層採用分段的陣列+連結串列實現， JDK1.8 的ConcurrentHashMap底層採用的資料結構與JDK1.8 的HashMap的結構一樣，陣列+連結串列/紅黑二叉樹。
- Hashtable和JDK1.8 之前的HashMap的底層資料結構類似都是採用陣列+連結串列的形式， 陣列是 HashMap 的主體，連結串列則是主要為了解決雜湊衝突而存在的。

②. 實現執行緒安全的方式

- JDK1.7的ConcurrentHashMap（分段鎖）對整個桶陣列進行了分割分段(Segment)， 每一把鎖只鎖容器其中一部分資料，多執行緒訪問容器裡不同資料段的資料，就不會存在鎖競爭，提高併發訪問度。 JDK 1.8 採用陣列+連結串列/紅黑二叉樹的資料結構來實現，併發控制使用synchronized和CAS來操作。
- Hashtable:使用 synchronized 來保證執行緒安全，效率非常低下。 當一個執行緒訪問同步方法時，其他執行緒也訪問同步方法，可能會進入阻塞或輪詢狀態， 如使用 put 新增元素，另一個執行緒不能使用 put 新增元素，也不能使用 get，競爭會越來越激烈。</k></k></k></k></k></k></k></k></k></k></k>

詳解Java 容器（第⑤篇）——容器原始碼分析 - 併發容器

相關文章