一個HashCode問題的追問，差點讓我陷入無底洞

一個HashCode問題的追問，差點讓我陷入無底洞
內存溢出 VS 內存泄漏這兩個詞在中文解釋上有些類似，至少給個人第一感受，他們的差異是這樣的(有人和我同樣嗎?)
做者：an日拱一兵 來源：日拱一兵|2020-08-04 08:44
收藏
分享

你有一個思想，我有一個思想，咱們交換後，一我的就有兩個思想
If you can NOT explain it simply, you do NOT understand it well enough
現陸續將Demo代碼和技術文章整理在一塊兒 Github實踐精選 ，方便你們閱讀查看，本文一樣收錄在此，以爲不錯，還請Star
原由
原由是羣裏的一位童鞋忽然問了這麼問題：
若是重寫 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
   因此也能夠反過來推理，若是發生上述問題，有可能程序的某些地方發生了內存泄漏那常見的哪些情形可能會引發內存泄漏呢?又有哪些解決辦法呢?
   會引發內存泄漏的常見情形與相應解決辦法
   靜態成員變量的亂用
   直接來看一個例子

5. @Slf4j
6. public class StaticTest {
7. public static List<Double> list = new ArrayList<>();
9. public void populateList() {
10. for (int i = 0; i < 10000000; i++) {
11. list.add(Math.random());
12. }
13. }
15. public static void main(String[] args) {
16. new StaticTest().populateList();
17. }
18. }

    populateList() 是一個 public 方法，可能被各類調用，致使 list 無限增大
    解決辦法
    解決辦法很簡單，針對這種情形(也就是一般所說的長週期對象引用短週期對象)，就是將 list 放到方法內部，方法棧幀執行完自動就會被回收了

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

    有童鞋可能有疑問：
    看 Spring 源碼時有好可能是 static 修飾的成員變量，難道它們也會致使內存泄漏?
    不是的，若是你仔細看邏輯，它們都是是在容器初始化的過程當中一次性加載的，因此不會像 populateList 隨着調用次數的增長，無限撐大 List
    未關閉的流
    在學習流的時候老師就在耳邊反覆說：
    必定要關閉流... 閉流... 流... 㐬... 兒...
    由於每當咱們創建一個新的鏈接或打開一個流時(好比數據庫鏈接、輸入流和會話對象)，JVM都會爲這些資源分配內存，若是不關閉，這就是佔用空間"有用"的對象, GC 就不會回收他們，當請求很大，來個請求就新建一個流，最終都還沒關閉，結果可想而知
    解決辦法
    流的解決辦法很簡單，其實主要遵循相應範式就能夠避免此類問題

25. 經過 try/catch/finally範式在 finally 關掉流
26. 若是你用的 Java 7+ 的版本，也能夠用 try-with-resources, 這樣代碼在編譯後會自動幫你關閉流
27. 也可使用 Lombok 的 @Cleanup 註解, 就像下面這樣

28. @Cleanup InputStream jobJarInputStream = new URL(jobJarUrl).openStream();
29. @Cleanup OutputStream jobJarOutputStream = new FileOutputStream(jobJarFile);
30. IOUtils.copy(jobJarInputStream, jobJarOutputStream);

    不正確的 equals 和 hashCode 實現
    又回到了這兩個函數上，有很大一部分程序員不會主動重寫 equals 和 hashCode，尤爲是用 Lombok @Data 註解(該註解默認會幫助重寫這兩個函數)後，更會忽視這兩個方法實現，一不當心的使就可能引發內存泄漏
    來看個很是簡單的例子：

31. public class MemLeakTest {
33. public static void main(String[] args) throws InterruptedException {
34. Map<Person, String> map = new HashMap<>();
35. Person p1 = new Person("zhangsan", 1);
36. Person p2 = new Person("zhangsan", 1);
37. Person p3 = new Person("zhangsan", 1);
39. map.put(p1, "zhangsan");
40. map.put(p2, "zhangsan");
41. map.put(p3, "zhangsan");
43. System.out.println(map.entrySet().size()); // 運行結果：3
44. }
45. }
47. @Getter
48. @Setter
49. class Person {
50. private String name;
51. private Integer id;
53. public Person(String name, Integer id){
54. this.name = name;
55. this.id = id;
56. }
57. }

    Person 類沒有重寫 hashCode 方法，那 Map 的 put 方法就會調用 Object 默認的 hashCode 方法

58. public V put(K key, V value) {
59. return putVal(hash(key), key, value, false, true);
60. }
62. static final int hash(Object key) {
63. int h;
64. return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
65. }

    p1, p2, p3 在【業務】屬性上是徹底相同的三個對象，因爲「對象地址」的不一樣致使生成的 hashCode 不同，最終都被放到 Map 中，這就會致使業務重複對象佔用空間，因此這也是內存泄漏的一種
    解決辦法
    解決辦法很簡單，在 Person 上加一個 Lombok 的 @Data 註解自動幫你重寫 hashCode 方法，或手動在 IDE 中 generate，再次運行，結果就爲 1了，符合業務需求
    那重寫了 hashCode 確實能夠避免重複對象的加入，那這就完事大吉了嗎, 再來看個例子

66. public static void main(String[] args) throws InterruptedException {
67. // 注意: HashSet 的底層也是 Map 結構
68. Set<Person> set = new HashSet<Person>();
70. Person p1 = new Person("zhangsan", 1);
71. Person p2 = new Person("lisi", 2);
72. Person p3 = new Person("wanger", 3);
74. set.add(p1);
75. set.add(p2);
76. set.add(p3);
78. System.out.println(set.size()); // 運行結果：3
79. p3.setName("wangermao");
80. set.remove(p3);
81. System.out.println(set.size()); // 運行結果：3
82. set.add(p3);
83. System.out.println(set.size()); // 運行結果：4
84. }

    從運行結果中來看，很顯然 set.remove(p3) 沒有刪除成功，由於p3.setName("wangermao") 後，從新計算 p3 的 hashCode 會發生變化，因此 remove 的時候會找不到相應的 Node，這就又給了增長相同對象的「機會」，致使業務中無用的對象被引用着，因此能夠說這也是內存泄漏的一種。運行結果來看：
    ![](https://s4.51cto.com/images/blog/202008/04/64bf8fd585b7d1daec77201a5443c118.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)
    因此諸如此類操做，最好是先 remove，而後更改屬性，最後再從新 add 進去看到這，你應該發現了，要解決 hashCode 相關的問題，你要充分了解集合的特性，更要留意類是否重寫了該方法以及它們的實現方式，避免出現內存泄漏狀況
    ThreadLocal
    羣消息中的最後，小姐姐 留下【ThreadLocal】幾個字，深藏功與名的離開了，一看就是高手
    ThreadLocal 是面試多線程的高頻考點，它的好處是能夠快速方便的作到線程隔離，但你們也都知道他是一把雙刃劍，由於使用很差就有可能致使內存泄漏了
    實際工做中咱們都是使用線程池來管理線程 「具體請參考 我會手動建立線程，爲何要使用線程池」，這種方式可讓線程獲得反覆利用(故意不讓 GC 回收)，
    如今，若是任何類建立了一個ThreadLocal變量，但沒有顯式地刪除它，那麼即便在web應用程序中止以後，該對象的副本仍將保留在工做線程中，從而阻止了該對象被垃圾收集，因此亂用也會致使內存泄漏
    解決辦法
    解決辦法依舊很簡單，依舊是遵循標準

85. 調用 ThreadLocal 的 remove() 方法，移除當前線程變量值
86. 也能夠將它看做一種 resource，使用 try/finally 範式，萬一在運行過程當中出現異常，還能夠在 finally 中 remove 掉

87. try {
88. threadLocal.set(System.nanoTime());
89. // business code
90. }
91. finally {
92. threadLocal.remove();
93. }

    我以爲小姐姐必定是高手
    總的來講，引發內存泄漏的緣由很是多，好比還有引用外部類的內部類等問題，這裏再也不展開說明，只是說明了幾種很是常見的可能引起內存泄漏問題的幾種場景
    內存泄漏問題不易察覺，因此有時須要藉助工具來幫忙
    JVisualVM
    JVisualvm 【可視化JVM】，可分析JDK1.6及其以上版本的JVM運行時的JVM參數、系統參數、堆棧、CPU使用等信息。可分析本地應用及遠程應用，在JDK1.6以上版本中自帶，工具的使用暫不展開說明， 想快速使用此工具，只須要在 IDE 中安裝個 VisualVM Launcher 插件
    ![](https://s4.51cto.com/images/blog/202008/04/30a8a7261a792ea8bca79d414edf3cba.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)
    而後在進行基本的配置
    ![](https://s4.51cto.com/images/blog/202008/04/08db45b3b4e2a4630044c08017ed5ebf.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)
    而後在IDE的右上角或當前類鼠標右鍵就能夠點擊運行查看了
    ![](https://s4.51cto.com/images/blog/202008/04/6a3d106bc303207027a47fd847b4c190.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)
    運行起 VisualVM 就是這樣子了
    ![](https://s4.51cto.com/images/blog/202008/04/96a81429250c09ad0fa69e3c912de064.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)
    不要走，還沒結束，在總結這篇文章的時候，我還發現了「新大陸」
    HashCode 真是根據對象內存地址生成的?
    腦海中的印象不知道爲什麼，很根深蒂固的接受了Object hashCode 是根據對象內存地址生成的，此次恰好想探求一下 hashCode 的本質，還着實打破了個人固有印象 (以 JDK1.8 爲例)
    OpenJDK 定義 hashCode 的方法在下面兩個文件中
    •   src/share/vm/prims/jvm.h
    •   src/share/vm/prims/jvm.cpp
    逐步看下去，最終會來到 get_next_hash 這個方法中，方便你們查看我先把方法截圖至此：
    ![](https://s4.51cto.com/images/blog/202008/04/2f485ddc1425cb56b1992e58dac83bd0.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)
    總的來講有 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 xor-shift[1]
    那在 JDK1.8 種用的哪種呢?
    ![](https://rgyb.sunluomeng.top/Screen Shot 2020-08-01 at 1.35.29 PM.png)
    能夠看到在 JDK1.8 中生成 hashCode 的方式是 5， 也就是走程序的 else 路徑，即便用 Xorshift，並非以前認爲的對象內存地址「1」，覺得老版本是採用對象內存地址的方式，因此繼續查看其餘版本
    ![](https://s4.51cto.com/images/blog/202008/04/c39f3a5e0b02131601acad36c2222c49.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)
    從圖中能夠看出，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] 裏面的圖片加以文字說明整個衝突過程
    ![](https://s4.51cto.com/images/blog/202008/04/50ff8d9b46d8f7b08d87faeb41ed12ed.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)
    因此，調用 Object 的 hashCode() 方法或者 System.identityHashCode() 方法會讓對象不能使用偏向鎖。到這裏你也就應該知道了，若是你還想使用偏向鎖，那最好重寫 hashCode() 方法，避免使偏向鎖失效
    總結
    爲了解決羣的這個問題，發現新大陸的同時也差點讓我掉入【追問無底洞】，不過經過本文你應該瞭解內存溢出和內存泄漏的差異，以及他們的解決方案，另外 hashCode[5] 生成方式還着實讓人有些驚訝，若是你知道「hashCode的生成是根據對象內存地址生成的來源，還請留言賜教」。除此以外，小小的 hashCode 還有可能讓偏向鎖失效，全部的這些細節問題都有多是致使程序崩潰的坑，因此勿以「惡」小而爲之，毋以「善」小而不爲，良好的編程習慣能避免不少問題
    固然想要更好的理解內存泄漏，固然是要更好的理解 GC 機制，而想要更好的理解 GC，固然是更好的理解 JVM，我們後續慢慢分析吧
    靈魂追問
    爲了清除 ThreadLocal 線程變量值，不用 ThreadLocal.remove() 方法，而是用 ThreadLocal.set(null) 會達到一樣的效果嗎?
    你曾經遇到哪些不易察覺的內存泄漏問題呢?
    參考
    [1]xor-shift算法: https://en.wikipedia.org/wiki/Xorshift
    [2]JDK1.6代碼: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/5cec449cc409/src/share/vm/runtime/globals.hpp#l1128
    [3]JDK1.7代碼: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/5b9a416a5632/src/share/vm/runtime/globals.hpp#l1100
    [4]OpenJDK Wiki: https://wiki.openjdk.java.net/display/HotSpot/Synchronization
    [5]默認hashCode生成方式: https://srvaroa.github.io/jvm/java/openjdk/biased-locking/2017/01/30/hashCode.html
    本文轉載自微信公衆號「 日拱一兵」，能夠經過如下二維碼關注。轉載本文請聯繫 日拱一兵公衆號。
    ![](https://s4.51cto.com/images/blog/202008/04/947cb00cc60253709a64cffffcb86723.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

94. Java中hashCode和equals方法的正確使用
95. 關於equals和hashCode，看這一篇真的夠了！【責任編輯：武曉燕 TEL：（010）68476606】