基於Java HashMap的逝世輪回的啟發詳解

1、單線程改革為多線程也是個技巧活

正如我們看到耗子叔叔博客裡寫的那樣，本來是單線程的運用法式，”後來，我們的法式機能有成績，所以須要釀成多線程的，因而，釀成多線程後到了線上，發明法式常常占了100%的CPU“。

斟酌到是淘寶的工程師曝出來的成績，他們的技巧基本普通都很扎實，連他們都用錯了，所以把單線程改革為多線程其實不是想象中的那末簡略，我以為。

你能夠很不信服地反問，淘寶的工程師又怎樣了，單線程改成多線程有甚麼難的？不過就是運用現有的多線程技巧嘛，你看，我有異常激烈的線程平安認識，我曉得同步、逝世鎖、競態前提，還曉得lock free和線程平安容器，還曉得各類線程平安同步結構……豈非還寫不出線程平安的運用法式？

現實情形是，線程平安的運用法式其實不必定由於你有扎實的線程平安基本和開辟經歷就可以夠寫好的。

試著舉兩個例子：

1、應用線程平安容器經由過程索引取數據

許多人曉得的線程平安容器，現實應用的時刻其實不必定不湧現BUG，上面的（有隱患的）代碼就比擬典范：

        static int GetFirstOrDefault(ThreadSafeList<int> list)
        {
            if (list.Count > 0)
            {
                return list[0];
            }
            return 0;
        }

下面的函數參數list假如一開端傳入一個元素總數為1的列表，年夜家能剖析出下面的代碼會有甚麼成績嗎？

關於線程平安容器，之前我正好也總結過一篇文章<深刻線程平安容器的完成辦法>。線程平安容器其實不真正平安，下面有成績的代碼就是出自於這裡。

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

還有就是多線程運用場景的剖析能夠不准確，已經由於一個郵件收發法式的機能成績，我也年夜膽改革過運用法式，改來改去就湧現了嚴重BUG，

年夜家可以看看我咬牙切齒總結過的<基於一個運用法式多線程誤用的剖析詳解>。

下面舉的這兩個例子，我只是想解釋，多線程運用法式中，由於線程平安發生的BUG實際上是很奧妙的，一個斟酌不周或許熟悉不敷深入，湧現成績的能夠性的確防不堪防。

2、ReHash的價值

下面第一點重要是閒談線程平安，接著我們也說說哈希表，深入懂得消費本錢很年夜的ReHash。

我們平凡懂得中的哈希表是“以空間換時光的一種數據構造”。如許說的太久了，年夜家能夠會有一種直不雅上的錯覺，就是哈希表就義的是空間，爭奪的是時光。

然則，ReHash的進程實際上是空間和時光的兩重嚴重喪失，由於剖析源代碼，我們曉得ReHash的進程其實就是一個靜態擴容的進程，而哈希表的擴容是個空間和時光消費都異常驚人的外部操作。

為何說ReHash是個空間和時光消費都異常驚人的外部操作呢？

1、本來當我們對哈希構造的容器停止擴容時，散列表外部要從新new一個更年夜的數組，然後把本來數組的內容拷貝到新數組，並停止從新散列；

2、new出來的這個更年夜的新數組容量有多年夜也是一門學問，普通來講，新數組的年夜小會設置成原數組雙倍年夜小的鄰近的一個素數（.NET中這個素數的生成還有必定的技能）。

從1和2這兩點可以看出，ReHash的價值確切異常高。在不久之前我恰巧寫過一篇關於.NET容器的靜態擴容的文章<解析從源碼剖析罕見的基於Array的數據構造靜態擴容機制的詳解>，個中也淺易總結了.NET的HashTable的擴容機制，如今對比Java中的HashMap源碼，看到熟習的ReHash函數定名，再看一遍.NET中的完成，果真有比擬能力有進步。

至於我們日常平凡所懂得的“以空間換時光“，實際上是指哈希具有O(1)龐雜度的數據檢索效力，但它受填充因子影響，空間開支平日很年夜，空間應用率不高。

所以我們經常說哈希表實用於讀操作頻仍，寫操作較少運用場景，好比把哈希表當作緩存容器，於我心有戚戚焉。

最初看到這句“有人把這個成績報給了Sun，不外Sun不以為這個是一個成績。由於HashMap原來就不支撐並發。要並發就用ConcurrentHashmap…”

依據現實開辟經歷，線程平安的容器其實不真正線程平安，會用ConcurrentHashmap也只是進入低級階段，同時不由得要感歎下昔時如日中天風景無窮的Sun。