※ 引述《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的原始码，但是我想....那本书应该是错的
这东西跟内存位置毫无关系
其实有兴趣可以去翻一下