※ 引述《noapaov (單身漢)》之銘言：
: 最近看了一下書籍, 不太清楚理解是否有錯, 想請教一下各位
: Object 類別所提供的 hashCode() method, 主要是返回物件的記憶體位置
: 經過運算後的整數, 所以與記憶體有密切關係
: 所以每個物件的HashCode()理論上應該都不一樣, 但是有些子類別繼承後會
: 進行equals和HashCode的覆寫,例如String、Array等, 所以就有可能造成 :
: 如果兩個物件使用equals(Object) 測試結果為不相等,
: 則這兩個物件呼叫 hashCode 時，可以獲得不同的整數結果("可以相同，也可以不同")
: 所以總結是如果繼承Object類的子類別, 沒有對equals hashCode進行改寫,
: 那麼這些物件產生的HashCode應該都不一樣, 但如果重寫就有可能造成HashCode相等, 但不一定是參考相同的記憶體位置情況
: 不知道原理是否是這樣
回文一下好了，我簡單說一下
1. hashCode()不見得跟記憶體位置有關，有興趣翻一下OpenJDK的String.hashCode()
他的實作方式保證你看了會笑出來
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/
classes/java/lang/String.java
縮 : http://tinyurl.com/mqguft4
2. 追下去原始碼的話你會發現 Object的hashCode是native
但是你只要對現代Java的GC有一點認識的話，就知道GC是會搬動記憶體的
從Java6引入Hotspot GC以降，整個heap被分為young/old/permgen
http://www.cubrid.org/blog/dev-platform/understanding-java-garbage-collection/
也就是說，你一個object的物件在記憶體裡面的位置根本是會跑來跑去的
他的hash會因此變來變去嗎？不會。那你覺得hashCode跟記憶體有沒有關係呢?
目前來講「應該」是沒有，不然按這種搬法，要是有第二個object出現在heap同位置
那不就死翹翹了?
我提供一下OpenJDK hashCode()的native C code給你參考一下
不同JVM有不同實作，不過我想再有implement Hotspot的JVM下
我想應該僅僅只是一個序列號而已
http://tinyurl.com/mhhrehs (他實作請搜尋get_next_hash，可以對照.h去對簽名)
在OpenJDK的VM實作，我們可以清楚地看到他其實只是一個遞增序列
ok...這看不懂沒關係
總之，雖然我沒有Oracle JVM的原始碼，但是我想....那本書應該是錯的
這東西跟記憶體位置毫無關係
其實有興趣可以去翻一下