## 起因 起因是群裡的一位童鞋突然問了這麼問題： > 如果重寫 equals 不重寫 hashcode 會有什麼影響？ 這個問題從上午10:45 開始陸續討論，到下午15:39 接近尾聲 （忽略這形同虛設的馬賽克）  這是一個好問題，更是一個高頻基礎面試題，我還曾經專門寫過一篇文章 [Java equals 和 hashCode 的這幾個問題可以說明白嗎](https://dayarch.top/p/java-equals-hashcode.html), 主要說明了以下內容 隨著討論的進行，問題慢慢集中在記憶體溢位和記憶體洩漏的問題上 ## 記憶體溢位 VS 記憶體洩漏 這兩個詞在中文解釋上有些相似，至少給我的第一感覺，他們的差別是這樣的（有人和我一樣嗎？）  記憶體溢位：Out of Memory (OOM) ，這個大家都很熟悉了，理解起來也很簡單，就是記憶體不夠用了（啤酒【物件】太多，杯子【記憶體】裝不下了） > 那啥是記憶體洩漏呢？ 記憶體洩漏：**Memory Leak** 特意查了一下 Leak 的字典含義，解釋1的直白翻譯是【通常是由於`錯誤`或`失誤`，從一個`開口` `進入`或逃脫】  所以程式中的記憶體洩漏我的理解更多是：由於程式的編寫錯誤暴漏出一些 **開口**，導致一些物件**進入**這寫開口，最終**導致相關問題**，進一步說白了，程式有漏洞，不當的呼叫就會出問題 所以接下來我們主要來看看 Java 記憶體洩漏，以及問題的起因 hashCode 和記憶體洩漏到底有哪些關係 ## 記憶體洩漏 咱也是一個有身份證的人，不能總講大白話，相對官方的記憶體洩漏解釋是這樣滴： > 記憶體洩漏說明的是這樣一種情況：堆中存在一些不再使用的物件，但垃圾收集器無法將它們從記憶體中刪除（垃圾收集器定期刪除未引用的物件，但從不收集仍在引用的物件），因此對它們進行了不必要的維護 這句話略顯抽象，一張圖你就能明白  如果有用的、但垃圾收集器又不能刪除的物件增多，就像下圖這樣，那麼就會逐漸導致記憶體溢位(OOM)了  所以也可以總結為，OOM 的原因之一可能是記憶體洩漏導致的 ### 記憶體洩漏會帶來哪些問題 記憶體洩漏，會導致真正可用記憶體變少，在沒達到 OOM 的這個過程中，就會出現奇奇怪怪的問題 1. 當應用程式長時間連續執行時，效能會嚴重下降，畢竟可用記憶體變小 3. 自發的和奇怪的應用程式崩潰 4. 應用程式偶爾會耗盡連線物件（這個經常聽說吧） 4. 最終的結果是 OOM **所以也可以反過來推理，如果發生上述問題，有可能程式的某些地方發生了記憶體洩漏** > 那常見的哪些情形可能會引起記憶體洩漏呢？又有哪些解決辦法呢？ ## 會引起記憶體洩漏的常見情形與相應解決辦法 ### 靜態成員變數的亂用 直接來看一個例子 ```java @Slf4j public class StaticTest { public sta