哈希表
1.介紹
哈希表就是一種以 鍵-值(key-indexed) 存儲數據的結構，我們只要輸入待查找的值即key，即可查找到其對應的值。
哈希的思路很簡單，如果所有的鍵都是整數，那麼就可以使用一個簡單的無序數組來實現：將鍵作爲索引，值即爲其對應的值，這樣就可以快速訪問任意鍵的值。這是對於簡單的鍵的情況，我們將其擴展到可以處理更加複雜的類型的鍵。
2.鏈式哈希表
鏈式哈希表從根本上說是由一組鏈表構成。每個鏈表都可以看做是一個“桶”，我們將所有的元素通過散列的方式放到具體的不同的桶中。插入元素時，首先將其鍵傳入一個哈希函數（該過程稱爲哈希鍵），函數通過散列的方式告知元素屬於哪個“桶”，然後在相應的鏈表頭插入元素。查找或刪除元素時，用同們的方式先找到元素的“桶”，然後遍歷相應的鏈表，直到發現我們想要的元素。因爲每個“桶”都是一個鏈表，所以鏈式哈希表並不限制包含元素的個數。然而，如果表變得太大，它的性能將會降低。
3.應用場景
我們熟知的緩存技術（比如redis、memcached）的核心其實就是在內存中維護一張巨大的哈希表，還有大家熟知的HashMap、CurrentHashMap等的應用。
ConcurrentHashMap與HashMap等的區別
1.HashMap
我們知道HashMap是線程不安全的，在多線程環境下，使用Hashmap進行put操作會引起死循環，導致CPU利用率接近100%，所以在併發情況下不能使用HashMap。
2.HashTable
HashTable和HashMap的實現原理幾乎一樣，差別無非是
- HashTable不允許key和value爲null
- HashTable是線程安全的
但是HashTable線程安全的策略實現代價卻太大了，簡單粗暴，get/put所有相關操作都是synchronized的，這相當於給整個哈希表加了一把大鎖。
多線程訪問時候，只要有一個線程訪問或操作該對象，那其他線程只能阻塞，相當於將所有的操作串行化，在競爭激烈的併發場景中性能就會非常差。
3.ConcurrentHashMap
主要就是爲了應對hashmap在併發環境下不安全而誕生的，ConcurrentHashMap的設計與實現非常精巧，大量的利用了volatile，final，CAS等lock-free技術來減少鎖競爭對於性能的影響。
我們都知道Map一般都是數組+鏈表結構（JDK1.8該爲數組+紅黑樹）。
ConcurrentHashMap避免了對全局加鎖改成了局部加鎖操作，這樣就極大地提高了併發環境下的操作速度，由於ConcurrentHashMap在JDK1.7和1.8中的實現非常不同，接下來我們談談JDK在1.7和1.8中的區別。
JDK1.7版本的CurrentHashMap的實現原理
在JDK1.7中ConcurrentHashMap採用了數組+Segment+分段鎖的方式實現。
1.Segment(分段鎖)
ConcurrentHashMap中的分段鎖稱爲Segment，它即類似於HashMap的結構，即內部擁有一個Entry數組，數組中的每個元素又是一個鏈表,同時又是一個ReentrantLock（Segment繼承了ReentrantLock）。
2.內部結構
ConcurrentHashMap使用分段鎖技術，將數據分成一段一段的存儲，然後給每一段數據配一把鎖，當一個線程佔用鎖訪問其中一個段數據的時候，其他段的數據也能被其他線程訪問，能夠實現真正的併發訪問。如下圖是ConcurrentHashMap的內部結構圖：
從上面的結構我們可以瞭解到，ConcurrentHashMap定位一個元素的過程需要進行兩次Hash操作。
第一次Hash定位到Segment，第二次Hash定位到元素所在的鏈表的頭部。
3.該結構的優劣勢
壞處
這一種結構的帶來的副作用是Hash的過程要比普通的HashMap要長
好處
寫操作的時候可以只對元素所在的Segment進行加鎖即可，不會影響到其他的Segment，這樣，在最理想的情況下，ConcurrentHashMap可以最高同時支持Segment數量大小的寫操作（剛好這些寫操作都非常平均地分佈在所有的Segment上）。
所以，通過這一種結構，ConcurrentHashMap的併發能力可以大大的提高。
JDK1.8版本的CurrentHashMap的實現原理
JDK8中ConcurrentHashMap參考了JDK8 HashMap的實現，採用了數組+鏈表+紅黑樹的實現方式來設計，內部大量採用CAS操作，這裏我簡要介紹下CAS。
CAS是compare and swap的縮寫，即我們所說的比較交換。cas是一種基於鎖的操作，而且是樂觀鎖。在java中鎖分爲樂觀鎖和悲觀鎖。悲觀鎖是將資源鎖住，等一個之前獲得鎖的線程釋放鎖之後，下一個線程纔可以訪問。而樂觀鎖採取了一種寬泛的態度，通過某種方式不加鎖來處理資源，比如通過給記錄加version來獲取數據，性能較悲觀鎖有很大的提高。
CAS 操作包含三個操作數 —— 內存位置（V）、預期原值（A）和新值(B)。如果內存地址裏面的值和A的值是一樣的，那麼就將內存裏面的值更新成B。CAS是通過無限循環來獲取數據的，若果在第一輪循環中，a線程獲取地址裏面的值被b線程修改了，那麼a線程需要自旋，到下次循環纔有可能機會執行。
JDK8中徹底放棄了Segment轉而採用的是Node，其設計思想也不再是JDK1.7中的分段鎖思想。
Node：保存key，value及key的hash值的數據結構。其中value和next都用volatile修飾，保證併發的可見性。
<strong>class Node<K,V> implements Map.Entry<K,V> {
final int hash;
final K key;
volatile V val;
volatile Node<K,V> next;
//... 省略部分代碼
} </strong>
Java8 ConcurrentHashMap結構基本上和Java8的HashMap一樣，不過保證線程安全性。
在JDK8中ConcurrentHashMap的結構，由於引入了紅黑樹，使得ConcurrentHashMap的實現非常複雜，我們都知道，紅黑樹是一種性能非常好的二叉查找樹，其查找性能爲O（logN），但是其實現過程也非常複雜，而且可讀性也非常差，Doug
Lea的思維能力確實不是一般人能比的，早期完全採用鏈表結構時Map的查找時間複雜度爲O（N），JDK8中ConcurrentHashMap在鏈表的長度大於某個閾值的時候會將鏈表轉換成紅黑樹進一步提高其查找性能。
總結
其實可以看出JDK1.8版本的ConcurrentHashMap的數據結構已經接近HashMap，相對而言，ConcurrentHashMap只是增加了同步的操作來控制併發，從JDK1.7版本的ReentrantLock+Segment+HashEntry，到JDK1.8版本中synchronized+CAS+HashEntry+紅黑樹。
1.數據結構：取消了Segment分段鎖的數據結構，取而代之的是數組+鏈表+紅黑樹的結構。
2.保證線程安全機制：JDK1.7採用segment的分段鎖機制實現線程安全，其中segment繼承自ReentrantLock。JDK1.8採用CAS+Synchronized保證線程安全。
3.鎖的粒度：原來是對需要進行數據操作的Segment加鎖，現調整爲對每個數組元素加鎖（Node）。
4.鏈表轉化爲紅黑樹:定位結點的hash算法簡化會帶來弊端,Hash衝突加劇,因此在鏈表節點數量大於8時，會將鏈表轉化爲紅黑樹進行存儲。
5.查詢時間複雜度：從原來的遍歷鏈表O(n)，變成遍歷紅黑樹O(logN)。