我們都知道，磁盤IO以塊為單位讀取數(shù)據(jù)，如果你所需要的數(shù)據(jù)都存儲(chǔ)在一個(gè)塊呢，一次IO即可返回。如果跨越多個(gè)塊，只要你的塊是連續(xù)的，類似MySQL，基于預(yù)讀機(jī)制，一次讀取多個(gè)塊的數(shù)據(jù)。這明顯利好數(shù)組，因?yàn)閿?shù)組申請(qǐng)內(nèi)存的時(shí)候，大小是固定且連續(xù)的。如果是鏈表，它的數(shù)據(jù)隨機(jī)散落在不同的塊，意味著磁盤IO很快。
年少往事
記得剛學(xué)數(shù)據(jù)鏈表的時(shí)候，老師是不是說，讀多寫少用數(shù)組，寫多讀少用鏈表，但你有沒有想過多少才算多？我也有這個(gè)疑問，剛好今天有時(shí)間，借這個(gè)話題一起探討，ArrayList和LinkedList選擇之寫操作。
磁盤IO
我們都知道，磁盤IO以塊為單位讀取數(shù)據(jù)，如果你所需要的數(shù)據(jù)都存儲(chǔ)在一個(gè)塊呢，一次IO即可返回。如果跨越多個(gè)塊，只要你的塊是連續(xù)的，類似MYSQl，基于預(yù)讀機(jī)制，一次讀取多個(gè)塊的數(shù)據(jù)。這明顯利好數(shù)組，因?yàn)閿?shù)組申請(qǐng)內(nèi)存的時(shí)候，大小是固定且連續(xù)的。如果是鏈表，它的數(shù)據(jù)隨機(jī)散落在不同的塊，意味著磁盤IO很快。
小結(jié)
- 數(shù)組讀性能好是因?yàn)閿?shù)據(jù)順序存儲(chǔ)，一次IO即可返回
- 鏈表讀性能差是因?yàn)閿?shù)據(jù)隨機(jī)存儲(chǔ)，多次IO才能返回
擴(kuò)容
我們都知道，ArrayList存在擴(kuò)容問題，在頻繁寫入的時(shí)候，會(huì)因?yàn)槿萘坎蛔阈枰貙戦_辟新的數(shù)組空間，然后復(fù)制原數(shù)組數(shù)據(jù)到新的數(shù)組，這個(gè)過程消耗大量內(nèi)存，這也是提出寫多用鏈表的原因。
那么，是不是只要寫多就用鏈表？這個(gè)回答顯然是否定的，不然沒有探討的意義。下面我們看看大數(shù)據(jù)量下兩者寫入差異。
小試牛刀，500萬數(shù)據(jù)看看
ArrayList初始容量1萬，循環(huán)插入500萬數(shù)據(jù)，擴(kuò)容9次，用時(shí)138ms，LinkedList只需要不停創(chuàng)建節(jié)點(diǎn)，將節(jié)點(diǎn)next綁定即可，但用時(shí)724ms，差距5倍多。
小結(jié)
500萬數(shù)據(jù)寫入，用ArrayList是上策。不過能接觸到這么多數(shù)據(jù)量的情況并不多，實(shí)際使用以實(shí)際情況為準(zhǔn)，多測(cè)測(cè)你的業(yè)務(wù)和機(jī)器選擇比較好，不過對(duì)于我來說，優(yōu)先考慮ArrayList，因?yàn)閺腉C的角度來說，順序存儲(chǔ)利于GC，不管是CMS還是G1。
加量-1千萬
可以看到，一千萬數(shù)據(jù)量依然有接近3倍的差異，看到這你還猶豫什么，無腦ArrayList
2千萬
沒想到2千萬就被反超了，但是你以為這樣會(huì)說服我使用LinkedList嗎，我只能說Naive
3千萬
已持平！
4千萬
重新反超，這么大的數(shù)據(jù)量下，linkedList創(chuàng)建大量node，比需要開辟新數(shù)組內(nèi)存的arrayList消耗的時(shí)間更多，內(nèi)存也更多，不信Jmap看看？而arrayList可是擴(kuò)容了12次
結(jié)論
沒得出什么牛逼結(jié)論，反而看出兩個(gè)list在大數(shù)據(jù)量情況下，性能不是一定誰更好，可能是兩條有多個(gè)交點(diǎn)的曲線。在選擇上，無腦arrayList，如果是重要場景，最好根據(jù)業(yè)務(wù)和機(jī)器配置選擇合適的。但業(yè)務(wù)會(huì)增長，摸著良心問自己，業(yè)務(wù)增長到另一個(gè)交點(diǎn)的時(shí)候，你會(huì)改過來嗎！
