build

chapter_hashing/hash_collision.md

@@ -6,7 +6,7 @@ comments: true
 
 上节提到，**通常情况下哈希函数的输入空间远大于输出空间**，因此理论上哈希冲突是不可避免的。比如，输入空间为全体整数，输出空间为数组容量大小，则必然有多个整数映射至同一数组索引。
 
-哈希冲突会导致查询结果错误，严重影响哈希表的可用性。为解决该问题，我们可以每当遇到哈希冲突时就进行哈希表扩容，直至冲突消失为止。此方法简单粗暴且有效，但效率太低，因为哈希表扩容需要进行大量的数据搬运与哈希值计算。为了提升效率，我们可以采用以下思路。
+哈希冲突会导致查询结果错误，严重影响哈希表的可用性。为解决该问题，我们可以每当遇到哈希冲突时就进行哈希表扩容，直至冲突消失为止。此方法简单粗暴且有效，但效率太低，因为哈希表扩容需要进行大量的数据搬运与哈希值计算。为了提升效率，我们可以采用以下策略。
 
 1. 改良哈希表数据结构，**使得哈希表可以在存在哈希冲突时正常工作**。
 2. 仅在必要时，即当哈希冲突比较严重时，才执行扩容操作。
@@ -168,6 +168,16 @@ comments: true
         HashMapChaining() : size(0), capacity(4), loadThres(2.0 / 3), extendRatio(2) {
             buckets.resize(capacity);
         }
+        
+        /* 析构方法 */
+        ~HashMapChaining() {
+            for (auto &bucket : buckets) {
+                for (Pair *pair : bucket) {
+                    // 释放内存
+                    delete pair;
+                }
+            }
+        }
 
         /* 哈希函数 */
         int hashFunc(int key) {
@@ -1148,9 +1158,7 @@ comments: true
     }
     ```
 
-!!! tip
-
-    当链表很长时，查询效率 $O(n)$ 很差，**此时可以将链表转换为“AVL 树”或“红黑树”**，从而将查询操作的时间复杂度优化至 $O(\log n)$ 。
+值得注意的是，当链表很长时，查询效率 $O(n)$ 很差。**此时可以将链表转换为“AVL 树”或“红黑树”**，从而将查询操作的时间复杂度优化至 $O(\log n)$ 。
 
 ## 6.2.2   开放寻址