hashCode竟然不是根據物件記憶體地址生成的？還對記憶體洩漏與偏向鎖有影響？

日拱一兵發表於2020-08-05
物件記憶體

日拱一兵 ｜ 原創

起因

起因是群裡的一位童鞋突然問了這麼問題：

如果重寫 equals 不重寫 hashcode 會有什麼影響？

這個問題從上午10:45 開始陸續討論，到下午15:39 接近尾聲 （忽略這形同虛設的馬賽克）

這是一個好問題，更是一個高頻基礎面試題，我還曾經專門寫過一篇文章 Java equals 和 hashCode 的這幾個問題可以說明白嗎, 主要說明了以下內容

<img src="https://rgyb.sunluomeng.top/20200728204424.png" style="zoom:50%;" />

隨著討論的進行，問題慢慢集中在記憶體溢位和記憶體洩漏的問題上

記憶體溢位 VS 記憶體洩漏

這兩個詞在中文解釋上有些相似，至少給我的第一感覺，他們的差別是這樣的（有人和我一樣嗎？）

記憶體溢位：Out of Memory (OOM) ，這個大家都很熟悉了，理解起來也很簡單，就是記憶體不夠用了（啤酒【物件】太多，杯子【記憶體】裝不下了）

那啥是記憶體洩漏呢？

記憶體洩漏：Memory Leak

特意查了一下 Leak 的字典含義，解釋1的直白翻譯是【通常是由於錯誤或失誤，從一個開口 進入或逃脫】

所以程式中的記憶體洩漏我的理解更多是：由於程式的編寫錯誤暴漏出一些 開口，導致一些物件進入這寫開口，最終導致相關問題，進一步說白了，程式有漏洞，不當的呼叫就會出問題

所以接下來我們主要來看看 Java 記憶體洩漏，以及問題的起因 hashCode 和記憶體洩漏到底有哪些關係

記憶體洩漏

我們也是一個有身份證的人，不能總講大白話，相對官方的記憶體洩漏解釋是這樣滴：

記憶體洩漏說明的是這樣一種情況：堆中存在一些不再使用的物件，但垃圾收集器無法將它們從記憶體中刪除（垃圾收集器定期刪除未引用的物件，但從不收集仍在引用的物件），因此對它們進行了不必要的維護

這句話略顯抽象，一張圖你就能明白

如果有用的、但垃圾收集器又不能刪除的物件增多，就像下圖這樣，那麼就會逐漸導致記憶體溢位(OOM)了

所以也可以總結為，OOM 的原因之一可能是記憶體洩漏導致的

記憶體洩漏會帶來哪些問題

記憶體洩漏，會導致真正可用記憶體變少，在沒達到 OOM 的這個過程中，就會出現奇奇怪怪的問題

  1. 當應用程式長時間連續執行時，效能會嚴重下降，畢竟可用記憶體變小
  2. 自發的和奇怪的應用程式崩潰
  3. 應用程式偶爾會耗盡連線物件（這個經常聽說吧）
  4. 最終的結果是 OOM

所以也可以反過來推理，如果發生上述問題，有可能程式的某些地方發生了記憶體洩漏

那常見的哪些情形可能會引起記憶體洩漏呢？又有哪些解決辦法呢？

會引起記憶體洩漏的常見情形與相應解決辦法

靜態成員變數的亂用

直接來看一個例子

@Slf4j
public class StaticTest {
    public static List<Double> list = new ArrayList<>();

    public void populateList() {
        for (int i = 0; i < 10000000; i++) {
            list.add(Math.random());
        }
    }

    public static void main(String[] args) {
        new StaticTest().populateList();
    }
}

populateList() 是一個 public 方法，可能被各種呼叫，導致 list 無限增大

解決辦法

解決辦法很簡單，針對這種情形（也就是通常所說的長週期物件引用短週期物件），就是將 list 放到方法內部，方法棧幀執行完自動就會被回收了

public void populateList() {
   List<Double> list = new ArrayList<>();
   for (int i = 0; i < 10000000; i++) {
      list.add(Math.random());
   }
}

有童鞋可能有疑問：

看 Spring 原始碼時有好多是 static 修飾的成員變數，難道它們也會導致記憶體洩漏？

不是的，如果你仔細看邏輯，它們都是是在容器初始化的過程中一次性載入的，所以不會像 populateList 隨著呼叫次數的增加，無限撐大 List

未關閉的流

在學習流的時候老師就在耳邊反覆說：

一定要關閉流... 閉流... 流... 㐬... 兒...

因為每當我們建立一個新的連線或開啟一個流時（比如資料庫連線、輸入流和會話物件），JVM都會為這些資源分配記憶體，如果不關閉，這就是佔用空間"有用"的物件, GC 就不會回收他們，當請求很大，來個請求就新建一個流，最終都還沒關閉，結果可想而知

解決辦法

流的解決辦法很簡單，其實主要遵循相應正規化就可以避免此類問題

  1. 通過 try/catch/finally正規化在 finally 關掉流
  2. 如果你用的 Java 7+ 的版本，也可以用 try-with-resources, 這樣程式碼在編譯後會自動幫你關閉流
  3. 也可以使用 Lombok 的 @Cleanup 註解, 就像下面這樣
@Cleanup InputStream jobJarInputStream = new URL(jobJarUrl).openStream();
@Cleanup OutputStream jobJarOutputStream = new FileOutputStream(jobJarFile);
IOUtils.copy(jobJarInputStream, jobJarOutputStream);

不正確的 equals 和 hashCode 實現

又回到了這兩個函式上，有很大一部分程式設計師不會主動重寫 equals 和 hashCode，尤其是用 Lombok @Data 註解（該註解預設會幫助重寫這兩個函式）後，更會忽視這兩個方法實現，一不小心的使就可能引起記憶體洩漏

來看個非常簡單的例子：

public class MemLeakTest {

   public static void main(String[] args) throws InterruptedException {
      Map<Person, String> map = new HashMap<>();
      Person p1 = new Person("zhangsan", 1);
      Person p2 = new Person("zhangsan", 1);
      Person p3 = new Person("zhangsan", 1);

      map.put(p1, "zhangsan");
      map.put(p2, "zhangsan");
      map.put(p3, "zhangsan");

      System.out.println(map.entrySet().size()); // 執行結果：3
   }
}  

@Getter
@Setter
class Person {
    private String name;
    private Integer id;

    public Person(String name, Integer id){
        this.name = name;
        this.id = id;
    }
}

Person 類沒有重寫 hashCode 方法，那 Map 的 put 方法就會呼叫 Object 預設的 hashCode 方法

public V put(K key, V value) {
    return putVal(hash(key), key, value, false, true);
}

static final int hash(Object key) {
  int h;
  return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

p1, p2, p3 在【業務】屬性上是完全相同的三個物件，由於「物件地址」的不同導致生成的 hashCode 不一樣，最終都被放到 Map 中，這就會導致業務重複物件佔用空間，所以這也是記憶體洩漏的一種

解決辦法

解決辦法很簡單，在 Person 上加一個 Lombok 的 @Data 註解自動幫你重寫 hashCode 方法，或手動在 IDE 中 generate，再次執行，結果就為 1了，符合業務需求

那重寫了 hashCode 確實可以避免重複物件的加入，那這就完事大吉了嗎, 再來看個例子

public static void main(String[] args) throws InterruptedException {
  // 注意: HashSet 的底層也是 Map 結構 
  Set<Person> set = new HashSet<Person>();

   Person p1 = new Person("zhangsan", 1);
   Person p2 = new Person("lisi", 2);
   Person p3 = new Person("wanger", 3);

   set.add(p1);
   set.add(p2);
   set.add(p3);
   
   System.out.println(set.size()); // 執行結果：3
   p3.setName("wangermao");
   set.remove(p3);
   System.out.println(set.size()); // 執行結果：3
   set.add(p3);
   System.out.println(set.size()); // 執行結果：4
}

從執行結果中來看，很顯然 set.remove(p3) 沒有刪除成功，因為 p3.setName("wangermao") 後，重新計算 p3 的 hashCode 會發生變化，所以 remove 的時候會找不到相應的 Node，這就又給了增加相同物件的“機會”，導致業務中無用的物件被引用著，所以可以說這也是記憶體洩漏的一種。執行結果來看：

所以諸如此類操作，最好是先 remove，然後更改屬性，最後再重新 add 進去

看到這，你應該發現了，要解決 hashCode 相關的問題，你要充分了解集合的特性，更要留意類是否重寫了該方法以及它們的實現方式，避免出現記憶體洩漏情況

ThreadLocal

群訊息中的最後，小姐姐 留下【ThreadLocal】幾個字，深藏功與名的離開了，一看就是高手

ThreadLocal 是面試多執行緒的高頻考點，它的好處是可以快速方便的做到執行緒隔離，但大家也都知道他是一把雙刃劍，因為使用不好就有可能導致記憶體洩漏了

實際工作中我們都是使用執行緒池來管理執行緒 「具體請參考 我會手動建立執行緒，為什麼要使用執行緒池」，這種方式可以讓執行緒得到反覆利用（故意不讓 GC 回收），

現在，如果任何類建立了一個ThreadLocal變數，但沒有顯式地刪除它，那麼即使在web應用程式停止之後，該物件的副本仍將保留在工作執行緒中，從而阻止了該物件被垃圾收集，所以亂用也會導致記憶體洩漏

解決辦法

解決辦法依舊很簡單，依舊是遵循標準

  1. 呼叫 ThreadLocal 的 remove() 方法，移除當前執行緒變數值
  2. 也可以將它看作一種 resource，使用 try/finally 正規化，萬一在執行過程中出現異常，還可以在 finally 中 remove 掉
try {
    threadLocal.set(System.nanoTime());
    // business code
}
finally {
    threadLocal.remove();
}

我覺得小姐姐一定是高手

總的來說，引起記憶體洩漏的原因非常多，比如還有引用外部類的內部類等問題，這裡不再展開說明，只是說明了幾種非常常見的可能引發記憶體洩漏問題的幾種場景

記憶體洩漏問題不易察覺，所以有時需要藉助工具來幫忙

JVisualJVM

JVisualJvm 【視覺化JVM】，可分析JDK1.6及其以上版本的JVM執行時的JVM引數、系統引數、堆疊、CPU使用等資訊。可分析本地應用及遠端應用，在JDK1.6以上版本中自帶。工具的使用暫不展開說明， 想快速使用此工具，只需要在 IDE 中安裝個 VisualVM Launcher 外掛

然後在進行基本的配置

然後在IDE的右上角或當前類滑鼠右鍵就可以點選執行檢視了

執行起 VisualJVM 就是這樣子了

不要走，還沒結束，在總結這篇文章的時候，我還發現了「新大陸」

HashCode 真是根據物件記憶體地址生成的？

腦海中的印象不知道為何，很根深蒂固的接受了Object hashCode 是根據物件記憶體地址生成的，這次剛好想探求一下 hashCode 的本質，還著實打破了我的固有印象 (以 JDK1.8 為例)

OpenJDK 定義 hashCode 的方法在下面兩個檔案中

  • src/share/vm/prims/jvm.h
  • src/share/vm/prims/jvm.cpp

逐步看下去，最終會來到 get_next_hash 這個方法中，方便大家檢視我先把方法截圖至此：

總的來說有 6 種生成 hashCode 的方式：

  • 0: A randomly generated number
  • 1: A function of memory address of the object
  • 2: A hardcoded 1 (used for sensitivity testing.)
  • 3: A sequence.
  • 4: The memory address of the object, cast to int
  • 5（else）: Thread state combined with xorshift1

那在 JDK1.8 種用的哪一種呢？

可以看到在 JDK1.8 中生成 hashCode 的方式是 5， 也就是走程式的 else 路徑，即使用 Xorshift，並不是之前認為的物件記憶體地址「1」，以為老版本是採用物件記憶體地址的方式，所以繼續檢視其他版本

從圖中可以看出，JDK1.62 和 JDK1.73 版本生成 hashCode 的方式「1」隨機數的形式，和我們原本認為的並不一樣，別的版本沒有繼續查詢，至於「流傳下來」說是物件記憶體地址生成的 hashCode 我也木有再深入研究，有了解的同學還請留言賜教

那麼問題來了：

假設用的 JDK1.6或 JDK1.7，它們生成 hashCode 的方式是隨機生成的，那一個物件多次呼叫hashCode是會有不同的hashCode 呢？（排除服務重啟的情況）

顯然應該不會的，因為如果每次都變化， 儲存到集合中的物件那就很容易丟失了，那問題又來了：

它們存在哪了？

hash 值是存在物件頭中的，我們還知道物件頭中還可能儲存執行緒ID，所以他們在某些情形中還會存在衝突

物件頭中 hashCode 和 偏向鎖的衝突

jvm 啟動時，可以使用 -XX:+UseBiasedLocking=true 開啟偏向鎖，（關於偏向鎖，輕量級鎖，重量級鎖大家查閱 synchronized 相關文件就可以），這裡引 OpenJDK Wiki4 裡面的圖片加以文字說明整個衝突過程

所以，呼叫 Object 的 hashCode() 方法或者 System.identityHashCode() 方法會讓物件不能使用偏向鎖。到這裡你也就應該知道了，如果你還想使用偏向鎖，那最好重寫 hashCode() 方法，避免使偏向鎖失效

總結

為了解決群的這個問題，發現新大陸的同時也差點讓我掉入【追問無底洞】，不過通過本文你應該瞭解記憶體溢位和記憶體洩漏的差別，以及他們的解決方案，另外 hashCode5 生成方式還著實讓人有些驚訝，如果你知道「hashCode的生成是根據物件記憶體地址生成的來源，還請留言賜教」。除此之外，小小的 hashCode 還有可能讓偏向鎖失效，所有的這些細節問題都有可能是導致程式崩潰的坑，所以勿以「惡」小而為之，毋以「善」小而不為，良好的程式設計習慣能避免很多問題

當然想要更好的理解記憶體洩漏，當然是要更好的理解 GC 機制，而想要更好的理解 GC，當然是更好的理解 JVM，我們們後續慢慢分析吧

靈魂追問

  1. 為了清除 ThreadLocal 執行緒變數值，不用 ThreadLocal.remove() 方法，而是用 ThreadLocal.set(null) 會達到同樣的效果嗎？
  2. 你曾經遇到哪些不易察覺的記憶體洩漏問題呢？

參考

  1. https://wiki.openjdk.java.net... ↩
  2. http://hg.openjdk.java.net/jd... ↩
  3. http://hg.openjdk.java.net/jd... ↩
  4. https://en.wikipedia.org/wiki... ↩
  5. https://srvaroa.github.io/jvm... ↩

相關文章