object的hash code

sun的jvm默认的hash code返回的是对象的内部地址构造的int。
那么就有了2个问题。
1 会不会重复。
2 同一个对象的hash code在gc移动了该对象之后会不会改变。

当然会重复了。无限的对象，有限的地址空间，hash是可以重复的。

同一个对象的hash code即使gc移动了该对象也不会改变。
jvm内部在object上加了标识位(2bits加上按需分配的存储hashcode的32bits)，用来决定是用对象的地址还是存储的值，如果对象被gc移动过，如果以前该对象的hash code被调用过的话，会对标识位置位，并存储以前的hashcode供以后使用。按需存储可以减少内存损耗。

评论

10 楼 mercyblitz 2011-01-04  

zhang_xzhi_xjtu 写道

mercyblitz 写道

1.hashcode的重复，不是因为地址空间，而是数据类型的长度限制。hashcode的原生Object算法不一定是对象地址哦！JVM实现不同！

2.为什么必要这么做啊，你的理论依据是？

1 你说的是对的。不过我的地址空间的本意就是数据类型限制，（太隐晦了，汗），int的类型决定了只有2的32次幂个hashcode。jvm实现不同，的确是这样，我讨论的是sun的jvm。
2 必须这么做，你想想hash的本意就会明白的。如果同一对象2次hash的值不一样，java世界就乱套了。

你误会我的意思啦，我的意思是说，他没有必要做偏移～

如果hashCode只是内部（逻辑）偏移地址的话，GC移动的物理地址就行了啊！

9 楼 whaosoft 2011-01-04  

zhang_xzhi_xjtu 写道

mercyblitz 写道

1.hashcode的重复，不是因为地址空间，而是数据类型的长度限制。hashcode的原生Object算法不一定是对象地址哦！JVM实现不同！

2.为什么必要这么做啊，你的理论依据是？

1 你说的是对的。不过我的地址空间的本意就是数据类型限制，（太隐晦了，汗），int的类型决定了只有2的32次幂个hashcode。jvm实现不同，的确是这样，我讨论的是sun的jvm。
2 必须这么做，你想想hash的本意就会明白的。如果同一对象2次hash的值不一样，java世界就乱套了。

如果同一对象2次hash的值不一样，java世界就乱套了
感觉这个靠谱 不可能java把自己弄的很繁琐很变态吧

8 楼 RednaxelaFX 2011-01-03  

首先Object的identity hash code跟地址没有必然的联系。规范里从来没说要有。

其次，在实际实现中也是有多种策略的。直接跟JVM相关的讨论可以参考Xiao-Feng Li以前发的一篇文章，相当不错：Object hashcode implementation（请自备梯子）

再次，如果想了解HotSpot VM所采用的具体策略，请参考这个源文件：synchronizer.cpp
留意其中的get_next_hash()，自身就是混合了多种策略的，目的就是让hash更加的分散。

7 楼 freish 2011-01-03  

从hashCode方法的javadoc描述可以看出一些端倪：



hashCode 的常规协定是：

在 Java 应用程序执行期间，在同一对象上多次调用 hashCode 方法时，必须一致地返回相同的整数，前提是对象上 equals 比较中所用的信息没有被修改。从某一应用程序的一次执行到同一应用程序的另一次执行，该整数无需保持一致。
如果根据 equals(Object) 方法，两个对象是相等的，那么在两个对象中的每个对象上调用 hashCode 方法都必须生成相同的整数结果。
以下情况不 是必需的：如果根据 equals(java.lang.Object) 方法，两个对象不相等，那么在两个对象中的任一对象上调用 hashCode 方法必定会生成不同的整数结果。但是，程序员应该知道，为不相等的对象生成不同整数结果可以提高哈希表的性能。
实际上，由 Object 类定义的 hashCode 方法确实会针对不同的对象返回不同的整数。（这一般是通过将该对象的内部地址转换成一个整数来实现的，但是 JavaTM 编程语言不需要这种实现技巧。）


只要jvm表现出来如同上面描述的那样就ok，至于怎么实现jvm，实在是仁者见仁智者见智的事情了

6 楼 zhang_xzhi_xjtu 2011-01-03  

mercyblitz 写道

1.hashcode的重复，不是因为地址空间，而是数据类型的长度限制。hashcode的原生Object算法不一定是对象地址哦！JVM实现不同！

2.为什么必要这么做啊，你的理论依据是？

1 你说的是对的。不过我的地址空间的本意就是数据类型限制，（太隐晦了，汗），int的类型决定了只有2的32次幂个hashcode。jvm实现不同，的确是这样，我讨论的是sun的jvm。
2 必须这么做，你想想hash的本意就会明白的。如果同一对象2次hash的值不一样，java世界就乱套了。

5 楼 mercyblitz 2011-01-03  

1.hashcode的重复，不是因为地址空间，而是数据类型的长度限制。hashcode的原生Object算法不一定是对象地址哦！JVM实现不同！

2.为什么必要这么做啊，你的理论依据是？

4 楼 zhang_xzhi_xjtu 2011-01-03  

yangyi 写道

zhang_xzhi_xjtu 写道

yangyi 写道

这个标志的长度是多少？既然java cache了hashcode，为什么不cache所有的呢，以至于effective java让我们在应用里cache自定义hashcode

标识是2位。存储32位。
cache所有的太占空间，所以是按需cache。

这个应该是lazy cache，用链表实现，所以空间应该不是问题。effective java2 p34页用的也是一个lazy的cache，为了保证堆上的一致，还用了volatile。
这个设计我觉得真的是值得商榷，本身就是给集合类用的一个工具方法，为什么不像comparator那样完全交给用户来处理呢？还有那个序列化的接口，给对象加入readobject writeobject，标记版本这种高耦合的都想得出来。
不知道算不算jdk早期版本遗留的败笔。

程序员当然希望有选择的自由，但是都是有代价的。
我记着把hashmap的load暴露给程序员后，很多程序员传入的参数都是不合理的。
至于hashcode的用法，当然可以覆盖hashcode了，这个问题不大。原生的hashcode只是提供一个默认实现。
系列化我也觉得不好，但是这个问题本身比较复杂，也没有想到什么好的办法。

3 楼 yangyi 2011-01-03  

zhang_xzhi_xjtu 写道

yangyi 写道

这个标志的长度是多少？既然java cache了hashcode，为什么不cache所有的呢，以至于effective java让我们在应用里cache自定义hashcode

标识是2位。存储32位。
cache所有的太占空间，所以是按需cache。

这个应该是lazy cache，用链表实现，所以空间应该不是问题。effective java2 p34页用的也是一个lazy的cache，为了保证堆上的一致，还用了volatile。
这个设计我觉得真的是值得商榷，本身就是给集合类用的一个工具方法，为什么不像comparator那样完全交给用户来处理呢？还有那个序列化的接口，给对象加入readobject writeobject，标记版本这种高耦合的都想得出来。
不知道算不算jdk早期版本遗留的败笔。

2 楼 zhang_xzhi_xjtu 2011-01-03  

yangyi 写道

这个标志的长度是多少？既然java cache了hashcode，为什么不cache所有的呢，以至于effective java让我们在应用里cache自定义hashcode

标识是2位。存储32位。
cache所有的太占空间，所以是按需cache。

1 楼 yangyi 2011-01-03  

这个标志的长度是多少？既然java cache了hashcode，为什么不cache所有的呢，以至于effective java让我们在应用里cache自定义hashcode