一直知道HashMap有默認(rèn)的容量和加載因子婿失，今天想看看源代碼兔乞，希望能了解的更清楚一些。
我們先看看默認(rèn)的構(gòu)造器吧婆廊，以下為我本機(jī)的JDK6.0的源代碼.
歡迎訪問(wèn)老紫竹的網(wǎng)站(http://www.java2000.net)和我在CSDN的博客(http://blog.csdn.net/java
/**
*?默認(rèn)的初始化的容量饼疙，必須是2的冪次數(shù)
*?The?default?initial?capacity?-?MUST?be?a?power?of?two.
*/
staticfinalintDEFAULT_INITIAL_CAPACITY?=16;
/**
*?默認(rèn)的加載因子
*/
staticfinalfloatDEFAULT_LOAD_FACTOR?=0.75f;
/**
*?下一個(gè)需要重新分配的尺寸值溺森。等于容量乘以加載因子。
*?也就是說(shuō)宏多，一旦容量到了這個(gè)數(shù)值儿惫，將重新分配容器的尺寸。
*?The?next?size?value?at?which?to?resize?(capacity?*?load?factor).
*?@serial
*/
intthreshold;
publicHashMap()?{
this.loadFactor?=?DEFAULT_LOAD_FACTOR;
threshold?=?(int)(DEFAULT_INITIAL_CAPACITY?*?DEFAULT_LOAD_FACTOR);
table?=newEntry[DEFAULT_INITIAL_CAPACITY];
init();
}
歡迎訪問(wèn)老紫竹的網(wǎng)站(http://www.java2000.net)和我在CSDN的博客(http://blog.csdn.net/java
從代碼可以看出伸但，默認(rèn)的容量是16肾请，而 threshold是16*0.75 = 12;
我們來(lái)看看增加的部分代碼。
publicV?put(K?key,?V?value)?{
//?我們忽略掉這部分的代碼更胖，只看我們這里最關(guān)心的部分
addEntry(hash,?key,?value,?i);//?這里增加了一個(gè)Entry,我們看看代碼
returnnull;
}
voidaddEntry(inthash,?K?key,?V?value,intbucketIndex)?{
Entry?e?=?table[bucketIndex];
table[bucketIndex]?=newEntry(hash,?key,?value,?e);
if(size++?>=?threshold)//?這里是關(guān)鍵铛铁，一旦大于等于threshold的數(shù)值
resize(2*?table.length);//?將會(huì)引起容量2倍的擴(kuò)大
}
voidresize(intnewCapacity)?{
Entry[]?oldTable?=?table;
intoldCapacity?=?oldTable.length;
if(oldCapacity?==?MAXIMUM_CAPACITY)?{
threshold?=?Integer.MAX_VALUE;
return;
}
Entry[]?newTable?=newEntry[newCapacity];//?新的容器空間
transfer(newTable);//?復(fù)制數(shù)據(jù)過(guò)去
table?=?newTable;
threshold?=?(int)(newCapacity?*?loadFactor);//?重新計(jì)算threshold的值
}
好了，我想我們已經(jīng)清楚大部分了却妨。
其中有一點(diǎn)饵逐，起始容量必須是2的冪次，這如何保證呢彪标？我們來(lái)看看其構(gòu)造方法
publicHashMap(intinitialCapacity,floatloadFactor)?{
//?忽略掉一部分代碼....
//?Find?a?power?of?2?>=?initialCapacity
//?重新查找不比指定數(shù)值大的最大的2的冪次數(shù)
intcapacity?=1;
while(capacity?<?initialCapacity)
capacity?<<=1;
//?其它的初始化代碼?...
}
好了倍权，關(guān)于起始容量和加載因子的探討我們就到這里了。我們應(yīng)該有了一定的了解了捞烟。
總結(jié)：
相對(duì)準(zhǔn)確的估算數(shù)據(jù)量薄声，將極大的影響HashMap的性能当船，因?yàn)閞esize是一個(gè)重新分配的過(guò)程，耗時(shí)應(yīng)該是里面最大的默辨。
加載因子較小德频，會(huì)有更多的空間空閑，我不知道這個(gè)0.75是不是一個(gè)折中方案缩幸。也許0.9也是一個(gè)不錯(cuò)的選擇壹置，特別是那些數(shù)據(jù)量雖然很大，但不是經(jīng)常變化的地方表谊，比如公司人員钞护，城市列表等相對(duì)比較固定的數(shù)據(jù)
