我只讨论观念。
※ 引述《Killercat (杀人猫™)》之铭言：
: ※ 引述《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/
这是对的，有手动去调整或看过eclipse.ini就可以知道。
: 也就是说，你一个object的物件在内存里面的位置根本是会跑来跑去的
: 他的hash会因此变来变去吗？不会。
这个部分问题会变成你觉得物件的hashCode会永远不变吗？
我的主张是会变的。
: 那你觉得hashCode跟内存有没有关系呢?
: 目前来讲“应该”是没有，不然按这种搬法，要是有第二个object出现在heap同位置
: 那不就死翘翘了?
问题变成当第二个object出现的时候，第一个object的位置在那里呢？
如果位置相同