关于Java集合的小抄--转
原文地址：http://calvin1978.blogcn.com/articles/collection.html
在盡可能短的篇幅里，將所有集合與并發集合的特征、實現方式、性能捋一遍。適合所有"精通Java"，其實還不那么自信的人閱讀。
?
期望能不止用于面試時，平時選擇數據結構，也能考慮一下其成本與效率，不要看著API合適就用了。
?
1.List
?
1.1 ArrayList
以數組實現。節約空間，但數組有容量限制。超出限制時會增加50%容量，用System.arraycopy（）復制到新的數組。因此最好能給出數組大小的預估值。默認第一次插入元素時創建大小為10的數組。
?
按數組下標訪問元素－get（i）、set（i,e） 的性能很高，這是數組的基本優勢。
如果按下標插入元素、刪除元素－add（i,e）、 remove（i）、remove（e），則要用System.arraycopy（）來復制移動部分受影響的元素，性能就變差了。
越是前面的元素，修改時要移動的元素越多。直接在數組末尾加入元素－常用的add（e），刪除最后一個元素則無影響。
?
1.2 LinkedList
以雙向鏈表實現。鏈表無容量限制，但雙向鏈表本身使用了更多空間，每插入一個元素都要構造一個額外的Node對象，也需要額外的鏈表指針操作。
?
按下標訪問元素－get（i）、set（i,e） 要悲劇的部分遍歷鏈表將指針移動到位 （如果i>數組大小的一半，會從末尾移起）。
插入、刪除元素時修改前后節點的指針即可，不再需要復制移動。但還是要部分遍歷鏈表的指針才能移動到下標所指的位置。
只有在鏈表兩頭的操作－add（）、addFirst（）、removeLast（）或用iterator（）上的remove（）倒能省掉指針的移動。
Apache Commons 有個TreeNodeList，里面是棵二叉樹，可以快速移動指針到位。
?
1.3 CopyOnWriteArrayList
并發優化的ArrayList。基于不可變對象策略，在修改時先復制出一個數組快照來修改，改好了，再讓內部指針指向新數組。
因為對快照的修改對讀操作來說不可見，所以讀讀之間不互斥，讀寫之間也不互斥，只有寫寫之間要加鎖互斥。但復制快照的成本昂貴，典型的適合讀多寫少的場景。
雖然增加了addIfAbsent（e）方法，會遍歷數組來檢查元素是否已存在，性能可想像的不會太好。
?
1.4 遺憾
無論哪種實現，按值返回下標contains（e）, indexOf（e）, remove（e） 都需遍歷所有元素進行比較，性能可想像的不會太好。
沒有按元素值排序的SortedList。
除了CopyOnWriteArrayList，再沒有其他線程安全又并發優化的實現如ConcurrentLinkedList。湊合著用Set與Queue中的等價類時，會缺少一些List特有的方法如get（i）。如果更新頻率較高，或數組較大時，還是得用Collections.synchronizedList（list），對所有操作用同一把鎖來保證線程安全。
2.Map
2.1 HashMap
?
以Entry[]數組實現的哈希桶數組，用Key的哈希值取模桶數組的大小可得到數組下標。
插入元素時，如果兩條Key落在同一個桶（比如哈希值1和17取模16后都屬于第一個哈希桶），我們稱之為哈希沖突。
JDK的做法是鏈表法，Entry用一個next屬性實現多個Entry以單向鏈表存放。查找哈希值為17的key時，先定位到哈希桶，然后鏈表遍歷桶里所有元素，逐個比較其Hash值然后key值。
在JDK8里，新增默認為8的閾值，當一個桶里的Entry超過閥值，就不以單向鏈表而以紅黑樹來存放以加快Key的查找速度。
當然，最好還是桶里只有一個元素，不用去比較。所以默認當Entry數量達到桶數量的75%時，哈希沖突已比較嚴重，就會成倍擴容桶數組，并重新分配所有原來的Entry。擴容成本不低，所以也最好有個預估值。
取模用與操作（hash & （arrayLength-1））會比較快，所以數組的大小永遠是2的N次方， 你隨便給一個初始值比如17會轉為32。默認第一次放入元素時的初始值是16。
iterator（）時順著哈希桶數組來遍歷，看起來是個亂序。
?
2.2 LinkedHashMap
擴展HashMap，每個Entry增加雙向鏈表，號稱是最占內存的數據結構。
支持iterator（）時按Entry的插入順序來排序（如果設置accessOrder屬性為true，則所有讀寫訪問都排序）。
插入時，Entry把自己加到Header Entry的前面去。如果所有讀寫訪問都要排序，還要把前后Entry的before/after拼接起來以在鏈表中刪除掉自己，所以此時讀操作也是線程不安全的了。
?
2.3 TreeMap
以紅黑樹實現，紅黑樹又叫自平衡二叉樹：
對于任一節點而言，其到葉節點的每一條路徑都包含相同數目的黑結點。上面的規定，使得樹的層數不會差的太遠，使得所有操作的復雜度不超過 O（lgn），但也使得插入，修改時要復雜的左旋右旋來保持樹的平衡。
支持iterator（）時按Key值排序，可按實現了Comparable接口的Key的升序排序，或由傳入的Comparator控制。可想象的，在樹上插入/刪除元素的代價一定比HashMap的大。
支持SortedMap接口，如firstKey（），lastKey（）取得最大最小的key，或sub（fromKey, toKey）, tailMap（fromKey）剪取Map的某一段。
?
2.4 EnumMap
EnumMap的原理是，在構造函數里要傳入枚舉類，那它就構建一個與枚舉的所有值等大的數組，按Enum. ordinal（）下標來訪問數組。性能與內存占用俱佳。
美中不足的是，因為要實現Map接口，而 V get（Object key）中key是Object而不是泛型K，所以安全起見，EnumMap每次訪問都要先對Key進行類型判斷，在JMC里錄得不低的采樣命中頻率。
?
2.5 ConcurrentHashMap
并發優化的HashMap。
在JDK5里的經典設計，默認16把寫鎖（可以設置更多），有效分散了阻塞的概率。數據結構為Segment[]，每個Segment一把鎖。Segment里面才是哈希桶數組。Key先算出它在哪個Segment里，再去算它在哪個哈希桶里。
也沒有讀鎖，因為put/remove動作是個原子動作（比如put的整個過程是一個對數組元素/Entry 指針的賦值操作），讀操作不會看到一個更新動作的中間狀態。
但在JDK8里，Segment[]的設計被拋棄了，改為精心設計的，只在需要鎖的時候加鎖。
支持ConcurrentMap接口，如putIfAbsent（key，value）與相反的replace（key，value）與以及實現CAS的replace（key, oldValue, newValue）。
?
2.6 ConcurrentSkipListMap
JDK6新增的并發優化的SortedMap，以SkipList結構實現。Concurrent包選用它是因為它支持基于CAS的無鎖算法，而紅黑樹則沒有好的無鎖算法。
原理上，可以想象為多個鏈表組成的N層樓，其中的元素從稀疏到密集，每個元素有往右與往下的指針。從第一層樓開始遍歷，如果右端的值比期望的大，那就往下走一層，繼續往前走。
?
典型的空間換時間。每次插入，都要決定在哪幾層插入，同時，要決定要不要多蓋一層樓。
它的size（）同樣不能隨便調，會遍歷來統計。
?
3.Set
?
所有Set幾乎都是內部用一個Map來實現, 因為Map里的KeySet就是一個Set，而value是假值，全部使用同一個Object即可。
Set的特征也繼承了那些內部的Map實現的特征。
HashSet：內部是HashMap。
LinkedHashSet：內部是LinkedHashMap。
TreeSet：內部是TreeMap的SortedSet。
ConcurrentSkipListSet：內部是ConcurrentSkipListMap的并發優化的SortedSet。
CopyOnWriteArraySet：內部是CopyOnWriteArrayList的并發優化的Set，利用其addIfAbsent（）方法實現元素去重，如前所述該方法的性能很一般。
好像少了個ConcurrentHashSet，本來也該有一個內部用ConcurrentHashMap的簡單實現，但JDK偏偏沒提供。Jetty就自己簡單封了一個，Guava則直接用java.util.Collections.newSetFromMap（new ConcurrentHashMap（）） 實現。
?
?
4.Queue
Queue是在兩端出入的List，所以也可以用數組或鏈表來實現。
4.1 普通隊列
4.1.1 LinkedList
是的，以雙向鏈表實現的LinkedList既是List，也是Queue。
4.1.2 ArrayDeque
以循環數組實現的雙向Queue。大小是2的倍數，默認是16。
為了支持FIFO，即從數組尾壓入元素（快），從數組頭取出元素（超慢），就不能再使用普通ArrayList的實現了，改為使用循環數組。
有隊頭隊尾兩個下標：彈出元素時，隊頭下標遞增；加入元素時，隊尾下標遞增。如果加入元素時已到數組空間的末尾，則將元素賦值到數組[0]，同時隊尾下標指向0，再插入下一個元素則賦值到數組[1]，隊尾下標指向1。如果隊尾的下標追上隊頭，說明數組所有空間已用完，進行雙倍的數組擴容。
4.1.3 PriorityQueue
用平衡二叉最小堆實現的優先級隊列，不再是FIFO，而是按元素實現的Comparable接口或傳入Comparator的比較結果來出隊，數值越小，優先級越高，越先出隊。但是注意其iterator（）的返回不會排序。
平衡最小二叉堆，用一個簡單的數組即可表達，可以快速尋址，沒有指針什么的。最小的在queue[0] ，比如queue[4]的兩個孩子，會在queue[2*4+1] 和 queue[2*（4+1）]，即queue[9]和queue[10]。
入隊時，插入queue[size]，然后二叉地往上比較調整堆。
出隊時，彈出queue[0]，然后把queque[size]拿出來二叉地往下比較調整堆。
初始大小為11，空間不夠時自動50%擴容。
?
4.2 線程安全的隊列
4.2.1 ConcurrentLinkedQueue/Deque
無界的并發優化的Queue，基于鏈表，實現了依賴于CAS的無鎖算法。
ConcurrentLinkedQueue的結構是單向鏈表和head/tail兩個指針，因為入隊時需要修改隊尾元素的next指針，以及修改tail指向新入隊的元素兩個CAS動作無法原子，所以需要的特殊的算法。
4.3 線程安全的阻塞隊列
BlockingQueue，一來如果隊列已空不用重復的查看是否有新數據而會阻塞在那里，二來隊列的長度受限，用以保證生產者與消費者的速度不會相差太遠。當入隊時隊列已滿，或出隊時隊列已空，不同函數的效果見下表：
| ? | 立刻報異常 | 立刻返回布爾 | 阻塞等待 | 可設定等待時間 |
| 入隊 | add（e） | offer（e） | put（e） | offer（e, timeout, unit） |
| 出隊 | remove（） | poll（） | take（） | poll（timeout, unit） |
| 查看 | element（） | peek（） | 無 | 無 |
?
4.3.1 ArrayBlockingQueue
定長的并發優化的BlockingQueue，也是基于循環數組實現。有一把公共的鎖與notFull、notEmpty兩個Condition管理隊列滿或空時的阻塞狀態。
4.3.2 LinkedBlockingQueue/Deque
可選定長的并發優化的BlockingQueue，基于鏈表實現，所以可以把長度設為Integer.MAX_VALUE成為無界無等待的。
利用鏈表的特征，分離了takeLock與putLock兩把鎖，繼續用notEmpty、notFull管理隊列滿或空時的阻塞狀態。
4.3.3 PriorityBlockingQueue
無界的PriorityQueue，也是基于數組存儲的二叉堆（見前）。一把公共的鎖實現線程安全。因為無界，空間不夠時會自動擴容，所以入列時不會鎖，出列為空時才會鎖。
?
4.3.4 DelayQueue
內部包含一個PriorityQueue，同樣是無界的，同樣是出列時才會鎖。一把公共的鎖實現線程安全。元素需實現Delayed接口，每次調用時需返回當前離觸發時間還有多久，小于0表示該觸發了。
pull（）時會用peek（）查看隊頭的元素，檢查是否到達觸發時間。ScheduledThreadPoolExecutor用了類似的結構。
?
4.4 同步隊列
SynchronousQueue同步隊列本身無容量，放入元素時，比如等待元素被另一條線程的消費者取走再返回。JDK線程池里用它。
JDK7還有個LinkedTransferQueue，在普通線程安全的BlockingQueue的基礎上，增加一個transfer（e） 函數，效果與SynchronousQueue一樣。
?
5. 參考文檔
- 紅黑樹：?https://github.com/julycoding/The-Art-Of-Programming-By-July/blob/master/ebook/zh/03.01.md
- 跳表：http://blog.sina.com.cn/s/blog_72995dcc01017w1t.html
- 二叉堆：http://blog.csdn.net/lcore/article/details/9100073
- ConcurrentLinkedQueue：http://www.ibm.com/developerworks/cn/java/j-jtp04186/
轉載于:https://www.cnblogs.com/davidwang456/p/6932712.html
總結
以上是生活随笔為你收集整理的关于Java集合的小抄--转的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： chrome的全局搜索快捷键
- 下一篇： Resolving Problems i