HashMap 類
原碼中的文檔解釋:
一
- 允許null value和null key
- 幾乎與Hashtable等價(jià),但它不是unsynchronized的(允許不同線程同時(shí)訪問, 非線程安全)并且允許null出現(xiàn)在鍵值對(duì)中(只允許一個(gè)key為null)
- HashMap并不保證map的有序性
二
- (hash 函數(shù)將元素適當(dāng)?shù)胤峙涞絙ucket中時(shí))基本的get和put操作的時(shí)間是常量級(jí)別的
- 集合的迭代(iteration)與HashMap實(shí)例的''capacity''大小(bucket的數(shù)量)加上大小(key-value鍵值對(duì)的映射數(shù)量)是成比例的. 因此, 初始的capacity值不能設(shè)置的很高(或者使負(fù)載因子很小)如果想要使迭代性能比較高的話
三
? 一個(gè)HashMap有兩個(gè)參數(shù)影響它的性能:
- 初始容量(initial capacity)
- 負(fù)載因子(load factor)
capacity是hash table中bucket的數(shù)量, initial capacity是hash table創(chuàng)建時(shí)的容量
load factor 是對(duì)capacity自動(dòng)增長前對(duì)hash table大小的衡量(a measure of how full the hash table is allowed to* get before its capacity is automatically increased). 當(dāng)在hash table 中的內(nèi)容大小(size)超過load factor和當(dāng)前capacity的乘積(product)時(shí), hash table會(huì)被再哈希(rehashed) (也就是說, 內(nèi)部的數(shù)據(jù)結(jié)構(gòu)會(huì)被重建, 會(huì)使hash table的bucket數(shù)量變?yōu)榻咏瓉淼膬杀洞笮?
四
? 一般來說, 默認(rèn)的load factor (0.75)在空間和時(shí)間花費(fèi)上達(dá)到了較好的平衡. 取值較高時(shí)會(huì)降低空間上的開銷但是會(huì)增加查找上的開銷(這點(diǎn)體現(xiàn)在HashMap的大多數(shù)操作上, 包括get和put). 設(shè)定initial capacity時(shí)應(yīng)當(dāng)考慮map中會(huì)有的記錄條數(shù)(The expected number of entries in* the map)以及它的load factor的大小從而最小化rehash的操作次數(shù). 如果initial capacity比entries/load factor的最大值大, rehash操作就不會(huì)發(fā)生了.
五
? 如果許多鍵值對(duì)映射被存儲(chǔ)到HashMap實(shí)例中, 在創(chuàng)建這個(gè)實(shí)例時(shí)賦予足夠大的capacity能使映射存儲(chǔ)得更加高效(相比于自動(dòng)rehash的來擴(kuò)容的角度來說). 注意, 多個(gè)key的hashCode()值相同肯定會(huì)降低hash table的性能的. 為了改良這種影響, 當(dāng)key是Comparable時(shí), 會(huì)通過keys間的比較順序來幫助打破這種情況.
六
? HashMap類的實(shí)現(xiàn)不是synchronized的, 如果多線程并發(fā)訪問一個(gè)hash map, 至少會(huì)有一個(gè)線程改變map的結(jié)構(gòu), 它的外部必須是synchronized的. (結(jié)構(gòu)上的改動(dòng)-structural modification)是任意的添加或者刪除一個(gè)或多個(gè)映射(mappings); 僅僅改變已經(jīng)存在于某個(gè)實(shí)例當(dāng)中的某個(gè)key的值不是結(jié)構(gòu)上的改動(dòng).) 這榮昌通過在某個(gè)object上進(jìn)行synchronizing來對(duì)map進(jìn)行封裝進(jìn)行解決.
? 如果沒有這樣的object存在, 那么map應(yīng)當(dāng)通過使用Collections.synchronizedMap方法進(jìn)行包裹(wrapped). 這最好在創(chuàng)建時(shí)就使用, 從而能夠避免意外地unsynchronized訪問map,如:
? Map m = Collections.synchronizedMap(new HashMap(...));
? 所有這個(gè)類的"collection view methods"返回的迭代器(iterator)都是fail-fast(快速失敗的)砰逻，如果在iterator創(chuàng)建后map被structurally modified, 那么除了iterator自身調(diào)用remove方法外, 在調(diào)用其他方法時(shí)iterator會(huì)拋出ConcurrentModificationException異常. 因此, 在面臨并發(fā)改動(dòng)時(shí), iterator會(huì)的迭代會(huì)很快失敗.
? iterator的fail-fast behavior并不能被保證, 一般來說, 不可能在unsynchronized concurrent modification出現(xiàn)時(shí)進(jìn)行任何保證. <u>Fail-fast iterator在best-effort的基礎(chǔ)上拋出ConcurrentModificationException</u>(沒懂,原文:Fail-fast iterators throw ConcurrentModificationException on a best-effort basis.)因此, fail-fast behavior的特點(diǎn)在測(cè)試bugs使用尚可, 依賴于此而編寫程序就不可取.
官網(wǎng)的集合接口的tutorial
源碼分析的文章
