一、單線程改造為多線程也是個技術(shù)活

正如我們看到耗子叔叔博客里寫的那樣，原來是單線程的應(yīng)用程序，”后來，我們的程序性能有問題，所以需要變成多線程的，于是，變成多線程后到了線上，發(fā)現(xiàn)程序經(jīng)常占了100%的CPU“。

考慮到是淘寶的工程師曝出來的問題，他們的技術(shù)基礎(chǔ)一般都很扎實，連他們都用錯了，所以把單線程改造為多線程并不是想象中的那么簡單，我認為。

你可能很不服氣地反問，淘寶的工程師又怎么了，單線程改為多線程有什么難的？無非就是應(yīng)用現(xiàn)有的多線程技術(shù)嘛，你看，我有非常強烈的線程安全意識，我知道同步、死鎖、競態(tài)條件，還知道lock free和線程安全容器，還知道各種線程安全同步構(gòu)造……難道還寫不出線程安全的應(yīng)用程序？

實際情況是，線程安全的應(yīng)用程序并不一定因為你有扎實的線程安全基礎(chǔ)和開發(fā)經(jīng)驗就能夠?qū)懞玫摹?/P>

試著舉兩個例子：

1、使用線程安全容器通過索引取數(shù)據(jù)

很多人知道的線程安全容器，實際使用的時候并不一定不出現(xiàn)BUG，下面的（有隱患的）代碼就比較典型：

關(guān)于線程安全容器，之前我恰好也總結(jié)過一篇文章<深入線程安全容器的實現(xiàn)方法>。線程安全容器并不真正安全，上面有問題的代碼就是出自于這里。

2、多線程操作郵件的失誤

還有就是多線程應(yīng)用場景的分析可能不正確，曾經(jīng)因為一個郵件收發(fā)程序的性能問題，我也大膽改造過應(yīng)用程序，改來改去就出現(xiàn)了重大BUG，

大家可以看看我痛心疾首總結(jié)過的<基于一個應(yīng)用程序多線程誤用的分析詳解>。

上面舉的這兩個例子，我只是想說明，多線程應(yīng)用程序中，因為線程安全產(chǎn)生的BUG其實是很微妙的，一個考慮不周或者認識不夠深刻，出現(xiàn)問題的可能性簡直防不勝防。

二、ReHash的代價

上面第一點主要是閑談線程安全，接著我們也說說哈希表，深刻理解消耗成本很大的ReHash。

我們平常理解中的哈希表是“以空間換時間的一種數(shù)據(jù)結(jié)構(gòu)”。這樣說的太久了，大家可能會有一種直觀上的錯覺，就是哈希表犧牲的是空間，爭取的是時間。

但是，ReHash的過程其實是空間和時間的雙重重大損失，因為分析源代碼，我們知道ReHash的過程其實就是一個動態(tài)擴容的過程，而哈希表的擴容是個空間和時間消耗都非常驚人的內(nèi)部操作。

為什么說ReHash是個空間和時間消耗都非常驚人的內(nèi)部操作呢？

1、原來當我們對哈希結(jié)構(gòu)的容器進行擴容時，散列表內(nèi)部要重新new一個更大的數(shù)組，然后把原來數(shù)組的內(nèi)容拷貝到新數(shù)組，并進行重新散列；

2、new出來的這個更大的新數(shù)組容量有多大也是一門學(xué)問，一般來說，新數(shù)組的大小會設(shè)置成原數(shù)組雙倍大小的相近的一個素數(shù)（.NET中這個素數(shù)的生成還有一定的技巧）。

從1和2這兩點可以看出，ReHash的代價確實非常高。在不久以前我碰巧寫過一篇關(guān)于.NET容器的動態(tài)擴容的文章<解析從源碼分析常見的基于Array的數(shù)據(jù)結(jié)構(gòu)動態(tài)擴容機制的詳解>，其中也淺顯總結(jié)了.NET的HashTable的擴容機制，現(xiàn)在對照Java中的HashMap源碼，看到熟悉的ReHash函數(shù)命名，再看一遍.NET中的實現(xiàn)，果然有比較才能有提高。

至于我們平時所理解的“以空間換時間“，其實是指哈希具有O(1)復(fù)雜度的數(shù)據(jù)檢索效率，但它受填充因子影響，空間開銷通常很大，空間利用率不高。

所以我們常常說哈希表適用于讀操作頻繁，寫操作較少應(yīng)用場景，比如把哈希表當做緩存容器，于我心有戚戚焉。

最后看到這句“有人把這個問題報給了Sun，不過Sun不認為這個是一個問題。因為HashMap本來就不支持并發(fā)。要并發(fā)就用ConcurrentHashmap…”

根據(jù)實際開發(fā)經(jīng)驗，線程安全的容器并不真正線程安全，會用ConcurrentHashmap也只是進入初級階段，同時忍不住要感慨下當年如日中天風(fēng)光無限的Sun。

最新評論