hashCode竟然不是根據對象內存地址生成的?還對內存泄漏與偏向鎖有影響?

起因

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

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

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

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

隨着討論的進行,問題慢慢集中在內存溢出和內存泄漏的問題上

內存溢出 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 xorshift[1]

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

可以看到在 JDK1.8 中生成 hashCode 的方式是 5, 也就是走程序的 else 路徑,即使用 Xorshift,並不是之前認為的對象內存地址「1」,以為老版本是採用對象內存地址的方式,所以繼續查看其他版本

從圖中可以看出,JDK1.6[2]JDK1.7[3] 版本生成 hashCode 的方式「1」隨機數的形式,和我們原本認為的並不一樣,別的版本沒有繼續查詢,至於「流傳下來」說是對象內存地址生成的 hashCode 我也木有再深入研究,有了解的同學還請留言賜教

那麼問題來了:

假設用的 JDK1.6或 JDK1.7,它們生成 hashCode 的方式是隨機生成的,那一個對象多次調用hashCode是會有不同的hashCode 呢?(排除服務重啟的情況)

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

它們存在哪了?

hash 值是存在對象頭中的,我們還知道對象頭中還可能存儲線程ID,所以他們在某些情形中還會存在衝突

對象頭中 hashCode 和 偏向鎖的衝突

jvm 啟動時,可以使用 -XX:+UseBiasedLocking=true 開啟偏向鎖,(關於偏向鎖,輕量級鎖,重量級鎖大家查閱 synchronized 相關文檔就可以),這裡引 OpenJDK Wiki[4] 裏面的圖片加以文字說明整個衝突過程

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

總結

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

當然想要更好的理解內存泄漏,當然是要更好的理解 GC 機制,而想要更好的理解 GC,當然是更好的理解 JVM,咱們後續慢慢分析吧

靈魂追問

  1. 為了清除 ThreadLocal 線程變量值,不用 ThreadLocal.remove() 方法,而是用 ThreadLocal.set(null) 會達到同樣的效果嗎?
  2. 你曾經遇到哪些不易察覺的內存泄漏問題呢?

參考

個人博客://dayarch.top
加我微信好友, 進群娛樂學習交流,備註「進群」

歡迎持續關注公眾號:「日拱一兵」

  • 前沿 Java 技術乾貨分享
  • 高效工具匯總 | 回復「工具」
  • 面試問題分析與解答
  • 技術資料領取 | 回復「資料」

以讀偵探小說思維輕鬆趣味學習 Java 技術棧相關知識,本着將複雜問題簡單化,抽象問題具體化和圖形化原則逐步分解技術問題,技術持續更新,請持續關注……



  1. //wiki.openjdk.java.net/display/HotSpot/Synchronization ↩︎

  2. //hg.openjdk.java.net/jdk6/jdk6/hotspot/file/5cec449cc409/src/share/vm/runtime/globals.hpp#l1128 ↩︎

  3. //hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/5b9a416a5632/src/share/vm/runtime/globals.hpp#l1100 ↩︎

  4. //en.wikipedia.org/wiki/Xorshift ↩︎

  5. //srvaroa.github.io/jvm/java/openjdk/biased-locking/2017/01/30/hashCode.html ↩︎