噶嗚~先來了解一下什麼是雜湊吧？
當我們要在一堆東西中找到想要的那乙個東西，我們常常通過比較來找，理想的情況是不經過任何比較，一次就能找到，怎麼才能做到這樣呢？那就在記錄的儲存位置和他的關鍵字之間建立乙個確定的對應關係,我們稱這種對應關係為雜湊函式~小盆友們應該對雜湊有了乙個初步的印象了吧？其實，雜湊函式就是乙個映像，設定很靈活，只要使任何關鍵字由這個雜湊函式所得的雜湊函式值都落在一定範圍內即可。當然，不同的關鍵字可能得到同一雜湊位址，這就出現了所謂的衝突，至於怎麼解決這種衝突，稍後就會了解到。
如何構造雜湊函式呢？
1.直接定址法：取關鍵字或關鍵字的某個線性函式值為雜湊位址，這種方法所得的位址集合和關鍵自己和大小相同，因此，對不同的關鍵字不會發生衝突，但實際應用中使用很少。
2.除法雜湊法最直觀的一種，公式：index = value % 16，學過彙編的都知道，求模數其實是通過乙個除法運算得到的，所以叫「除法雜湊法」。
3.平方雜湊法求index是非常頻繁的操作，而乘法的運算要比除法來得省時（對現在的cpu來說，估計我們感覺不出來），所以我們考慮把除法換成乘法和乙個位移操作。公式：index = (value * value) >> 28（右移，除以2^28。記法：左移變大，是乘。右移變小，是除。）如果數值分配比較均勻的話這種方法能得到不錯的結果，但我上面畫的那個圖的各個元素的值算出來的index都 是0——非常失敗。也許你 還有個問題，value如果很大，value * value不會溢位嗎？答案是會的，但我們這個乘法不關心溢位，因為我們根本不是為了獲取相乘結果，而是為了獲取index。
4.斐波那契（fibonacci）雜湊法,平方雜湊法的缺點是顯而易見的，所以我們能不能找出乙個理想的乘數，而不是拿value本身當作乘數呢？答案是肯定的。
1，對於16位整數而言，這個乘數是40503
2，對於32位整數而言，這個乘數是2654435769
3，對於64位整數而言，這個乘數是11400714819323198485
這幾個「理想乘數」是如何得出來的呢？這跟乙個法則有關，叫**分割法則，而描述**分割法則的最經典表示式無疑就是著名的斐波那契數列，即如此形 式的序列：0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144,233, 377, 610， 987, 1597, 2584, 4181, 6765, 10946，…。另外，斐波那契數列的值和太陽系八大行星的軌道半徑的比例出奇吻合。對我們常見的32位整數而言，公式：index = (value * 2654435769) >> 28.
暫時就寫這麼多了，有不足的還望各位大神多多補充~！
處理衝突的方法：
（1）線性再雜湊法，簡單的按順序遍歷hash表，尋找下乙個可用的槽；
（2）非線性再雜湊法，計算乙個新的hash值；
（3）鏈位址法。
鏈位址法解決衝突的做法是：如果雜湊表空間為 0 ～ m - 1 ，設定乙個由 m 個指標分量組成的一維陣列 st[ m ], 凡雜湊位址為 i 的資料元素都插入到頭指標為 st[ i ] 的鍊錶中。這種方法有點近似於鄰接表的基本思想，且這種方法適合於衝突比較嚴重的情況。
例： 設有 8 個元素 ，採用某種雜湊函式得到的位址分別為： ，當雜湊表長度為 10 時，採用鏈位址法解決衝突的雜湊表如下圖所示。
大家發現萌點所在了嗎？orz~~只是小小總結一下，還有很多不足，多多包涵
————anonymous.pjq
知識點小結
華為 1.c與c 哪個效能比較好？從語言特性角度上來看，c 是c的超集。在 c c的這部分語言特性中有很多會降低執行效率。乙個例子是dynamic cast，執行乙個dynamic cast要消耗100 300個cpu cycles，因為機器要跳到一段特別的snippet 一小段程式 去檢查type...
知識點小結
一 mysql計算日期 timestampdiff day,t3.payment due date,now 二 字段轉換 case when t1.status in d01 a01 a00 then 三 mybatis在插入資料時，返回id usegeneratedkeys true keypro...
unity知識點小結
1 通過gameobject.find 玩家物體 getcomponent 獲取玩家的player指令碼 2 quaternion.identity就是指quaternion 0,0,0,0 就是每旋轉前的初始角度,是乙個確切的值,而transform.rotation是指本物體的角度,值是不確定的...