|
精华帖 (0) :: 良好帖 (2) :: 新手帖 (3) :: 隐藏帖 (9)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-02-16
最后修改：2011-02-16
不算跑题吧，楼主谈的这种情况只是我说的这种情况的一种特例，可以从我说这种情况推断出来。我只是不想让 看似有道理但是不算完美 的解释方法（我认为）摆在最后而已。
既然放进去任何对象只要hashCode改变就拿不出来（不用提equals，得出这个结论和equals一点关系都没），那么楼主的结论和你所解释的原因就都问题（如果我的解释是正确的）。 如果你觉得这个是跑题，一直认为自己解释的是正确的话，烦请指出我的错误在哪，否则我也认为就真没什么必要继续讨论了。 |
| 返回顶楼 | |
|
发表时间：2011-02-16
最后修改：2011-02-16
superobin 写道
不算跑题吧，楼主谈的这种情况只是我说的这种情况的一种特例，可以从我说这种情况推断出来。我只是不想让 看似有道理但是不算完美 的解释方法（我认为）摆在最后而已。
既然放进去任何对象只要hashCode改变就拿不出来（不用提equals，得出这个结论和equals一点关系都没），那么楼主的结论和你所解释的原因就都问题（如果我的解释是正确的）。 如果你觉得这个是跑题，一直认为自己解释的是正确的话，烦请指出我的错误在哪，否则我也认为就真没什么必要继续讨论了。
特别注意一个就是comparate接口，既然equals都判断true那么compare结果也应当为0
这些通用约定如果未注意很容易让里的程序或设计出现非预期结果的 |
| 返回顶楼 | |
|
发表时间：2011-02-16
superobin 写道 不算跑题吧，楼主谈的这种情况只是我说的这种情况的一种特例，可以从我说这种情况推断出来。我只是不想让 看似有道理但是不算完美 的解释方法（我认为）摆在最后而已。
既然放进去任何对象只要hashCode改变就拿不出来（不用提equals，得出这个结论和equals一点关系都没），那么楼主的结论和你所解释的原因就都问题（如果我的解释是正确的）。 如果你觉得这个是跑题，一直认为自己解释的是正确的话，烦请指出我的错误在哪，否则我也认为就真没什么必要继续讨论了。 首先您消消火，我回复也是看您很认真对待这个问题，如果不回复可能您还在生闷气。下面表达一下我的意见，您要是不同意也没关系，我们保留意见就好了，何必非要意见一致呢，没准某个特定场合就发生了您说的情况，那您的分析比我的有用多了。 首先逻辑上讲，如果公理都不承认的话讨论定理还有意义吗？太极生两仪，四象演八卦。道之不存，器又焉附呢？没有1+1=2这个“共识”，又怎么敢大胆的说2+1=3呢 其次，假如我们承认了公理， 引用 Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application. If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result. It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables. http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Object.html 根据公理，对于我们的场景，可以分析出两点： 1 hashcode是可以变化的，但是一定要equals所依赖的信息变化才行 2 当equals成立时，必有hashcode相等 回头说我们的场景， 当两个对象Key不相等，并且当两次put发生在同一个bucket中时，第一次table[x] = P1，第二次table[x] = P2, P2->next = P1 当P2的key发生变化，并变为和P1一致时： a)此变化满足条件1，因此可行 b)根据条件2，此时P2的新的hash值等于之前P1的hash值，同时也是P2之前的hash值 c)当根据P1或P2作为key取值时，首先hash值都相等，其次equals成立，第三首先定位到P2，所以返回P2 |
| 返回顶楼 | |
|
发表时间：2011-02-16
我觉得yangyi说的情况是存在的。我现在有个疑问，就是HashMap的hash方法计算不同的hashcode返回的hash值有可能相同吗？我想知道hash冲突发生在仅仅是不同的key对应相同的hashcode这种情况，还是不同的hashcode也会生成相同的hash值？
|
| 返回顶楼 | |
|
发表时间：2011-02-17
To：yangyi
可能之前说的有点冲，但是没有恶意，你也是个对技术问题很执著的人，我对之前的鲁莽表示歉意~ 经过你的举例我发现我之前的结论确实有问题，在极端的情况下，它确实可以取出来。后来经过实例测试也验证了这一点。并不是永远都取不出来。 另外，我认為对於各种问题，尤其是像这种有明确代码的一是一二是二的问题，应该没啥周旋的餘地，这种问题如果有分歧，两个个人肯定有一个错的，如果找不到错在哪，至少有一个人要坚持著错误的观点，这样不好，不对吗？ 今天坚持了错误的观点很长时间，经过讨论学到了很多——越是这样的讨论学到的越多，思考越深入。比如今天我就知道了hashCode和equals之间的约定，之前只有个模糊的概念现在也终於清晰了。 再另外，佔领楼主的帖子争论了这麼多，再对楼主表现一下歉意吧~呵呵 |
| 返回顶楼 | |
|
发表时间：2011-02-17
java中典型的内存泄露问题啊，修改的字段参与了对象的hashcode的计算，造成存储位置变更
|
| 返回顶楼 | |
|
发表时间：2011-02-17
superobin 写道 To：yangyi
可能之前说的有点冲，但是没有恶意，你也是个对技术问题很执著的人，我对之前的鲁莽表示歉意~ 经过你的举例我发现我之前的结论确实有问题，在极端的情况下，它确实可以取出来。后来经过实例测试也验证了这一点。并不是永远都取不出来。 另外，我认為对於各种问题，尤其是像这种有明确代码的一是一二是二的问题，应该没啥周旋的餘地，这种问题如果有分歧，两个个人肯定有一个错的，如果找不到错在哪，至少有一个人要坚持著错误的观点，这样不好，不对吗？ 今天坚持了错误的观点很长时间，经过讨论学到了很多——越是这样的讨论学到的越多，思考越深入。比如今天我就知道了hashCode和equals之间的约定，之前只有个模糊的概念现在也终於清晰了。 再另外，佔领楼主的帖子争论了这麼多，再对楼主表现一下歉意吧~呵呵 原本的目的就是让大家讨论的，技术问题方面我们对事不对人，该争论的还是得争论，这是一种学习态度。 |
| 返回顶楼 | |
|
发表时间：2011-04-14
虽然看不懂，但是强烈希望能进一步学习。留个名。。。
|
| 返回顶楼 | |
