对象值到底指什么?(x.equals(y) == true)应该并不代表对象值相同
class  A
{
A(){}
public boolean equals(A a)
{
return true;
}
}
public class EqualsTest
{
public static void main(String argv[])
{
A a1 = new A();
A a2 = new A();
System.out.println(a1.equals(a2));
System.out.println(a1.hashCode());
System.out.println(a2.hashCode());
}
}

解决方案 »

  1.   

    对的,相等性比较和hashCode的计算依据可以由类的编写者确定
      

  2.   

    这句话是对的。
    这里的对象值相同就是指x.equals(y) == true但是这句话反过来说就不对了
    两个对象有相同hash code,但却可有不同的值x.equals(y)==false是不对的
      

  3.   

    楼主如果想深刻理解hash code的话
    建议去看一看数据结构方面的书
      

  4.   

    这句话是对的。
    这里的对象值相同就是指x.equals(y) == true但是这句话反过来说就不对了
    两个对象有相同hash code,但却可有不同的值x.equals(y)==false是不对的
     ypdarling(冲动是魔鬼!) 
    的回答真是一塌糊涂
      

  5.   

    你的这个问题应该是没有一定的答案,就你上边写的类A来说,由于没有覆盖hashCode()方法,所以用的还是基leiObject的hashCode()方法,由于a1,a2地址不一样,所以即使他们内容一样,
    hashCode也不一样。如果你覆盖了,就看你怎么实现了,所以不定答案。
      

  6.   

    to treeroot(旗鲁特):
    请问哪里糊涂了?
      

  7.   

    to treeroot(旗鲁特):
    请问哪里糊涂了?
    -------------
    hashcode跟数据结构有什么关系?
      

  8.   

    两个没有必然联系的事情就好像
    今天下雨(equals)

    我没洗衣服一样(hashCode)虽根据常识(推荐的做法)
    今天下雨,就最好不要洗衣服(equals -> hashCode == hashCode),但是这个不是强制的,
    虽说下雨了就一定没洗衣服阿
      

  9.   

    两个对象值相同(x.equals(y) == true),但却可有不同的hash code 。这是对的!!!
    hash code 相同,两个对象也可以不同!!强强强强强强啊!!!!!!!!
      

  10.   

    to ypdarling(冲动是魔鬼!) 但是这句话反过来说就不对了
    两个对象有相同hash code,但却可有不同的值x.equals(y)==false是不对的为什么不可以?
    事实上是非常可以
      

  11.   

    虽根据常识(推荐的做法)
    今天下雨,就最好不要洗衣服(equals -> hashCode == hashCode)!
    不是根据常识,可以这么说吧:equals()是为hashCode不同而设定的!!!
      

  12.   

    equals()是为hashCode不同而设定的!!!又是谬论!
    只有使用哈希表是才使用hashCode,equals在任何地方都会用到.
    如果你需要使用equals方法或者任何容器,就不要忽略它的存在.
    只有你需要使用哈希表时你才需要关注hashCode,而且一般要足够离散!
      

  13.   

    打错了!!!应该是equals()是为hashCode相同而设定的!!!equals()离不开hashCode,除非你做没意义的事!!对吧 treeroot(旗鲁特),帅哥?喜喜!!!
      

  14.   

    两个对象有相同hash code,但却可有不同的值x.equals(y)==false
    这句话是对的。我刚才本来是想说:
    “两个对象值不同(x.equals(y) == false)时,hash code一定要不同”这句话是不对的。
    谁知道刚才一粗心大意没仔细想给打错了,是我不好,sorry。
      

  15.   

    两个对象值不同(x.equals(y) == false)时,hash code一定要不同!!!这句话是对的啊,呵呵!经典这句话!!!
      

  16.   

    to  I_Believe_(才哥):
    equals()是为hashCode相同而设定的!!!这句话也可以算是正确。
    我认为hashCode离不开equals()
    因为当对象的hashCode相同时,哈希表是靠equals()来区分对象的。
      

  17.   

    to  I_Believe_(才哥):
    两个对象值不同(x.equals(y) == false)时,hash code一定要不同!!!这句话是对的啊,呵呵!经典这句话!!!
    我上面明明写了这句话是不对的了,你是什么意思啊?
    不是就有面试题这么问的吗?
      

  18.   

    两个对象值不同(x.equals(y) == false)时,hash code一定要相同!!晕,今天老出错下了!拜!! ypdarling(冲动是魔鬼!) 是对的!!!
      

  19.   

    believefym(暮色,miss,迷失,miss) 
    hashcode跟数据结构有什么关系?不过有一点我还是要坚持,我认为hashcode跟数据结构有很大关系。
    去书店随便拿一本数据结构的书,然后翻到查找那一章,你就知道有没有关系了。
    请高手来评评哩。
      

  20.   

    to  I_Believe_(才哥):
    两个对象值不同(x.equals(y) == false)时,hash code可以相同可以不同。
    有一定就是错了,不是吗?
      

  21.   

    to  I_Believe_(才哥) :
    你要是有什么问题你就说
    要是我错了,我虚心接受,
    你别总是把话说得不明不白。
    我都不知道你说的是陈述句 还是感叹句,都不知道该怎么理解了。
    你别走啊!
      

  22.   

    TO I_Believe_(才哥) 
    打错了!!!应该是equals()是为hashCode相同而设定的!!!equals()离不开hashCode,除非你做没意义的事!!我越来越晕了,equals怎么会是为hashCode而设的,就算没有hashCode,还有equals.
    equals又怎么会离不开hashCode呢? 
    TO  ypdarling(冲动是魔鬼!) ( 
    因为当对象的hashCode相同时,哈希表是靠equals()来区分对象的。这句话不准确,哈希表永远是更具equals来区分对象的,但是它有一个基本的规则:如果hashCode不同,就认为他们一定不equals!
      

  23.   

    首先,从语法角度,也就是从强制性的角度来说,hashCode和equals是两个独立的,互不隶属,互不依赖的方法,equals成立与hashCode相等这两个命题之间,谁也不是谁的充分条件或者必要条件。但是,从为了让我们的程序正常运行的角度,我们应当向Effective Java中所言重载equals的时候,一定要(正确)重载hashCode使得equals成立的时候,hashCode相等,也就是a.equals(b)->a.hashCode() == b.hashCode(),或者说此时,equals是hashCode相等的充分条件,hashCode相等是equals的必要条件(从数学课上我们知道它的逆否命题:hashCode不相等也不会equals),但是它的逆命题,hashCode相等一定equals以及否命题不equals时hashCode不等都不成立。所以,如果面试的时候,最好把hashCode与equals之间没有强制关系,以及根据(没有语法约束力的)规范的角度,应当做到...这两层意思都说出来:P
      

  24.   

    TO  ypdarling(冲动是魔鬼!) :打错字了!你说得是对的!!
    TO treeroot(旗鲁特):你要注意我的语气,我坚持那种说法
      

  25.   

    TO: shine333(enihs) , hashCode和equals是两个独立的,互不隶属,互不依赖的方法!!不大同意,hashCode依赖于equals!!!
      

  26.   

    hashCode与equals之间就是有强制关系
      

  27.   

    请注意这句话前面的条件:>首先,从语法角度,也就是从强制性的角度来说,hashCode和equals是两个独立的,互不隶属,互不依赖的方法,equals成立与hashCode相等这两个命题之间,谁也不是谁的充分条件或者必要条件。如果你还坚持hashCode在语法角度依赖于equals,那直到你能从强制性的Java语法的角度,解释出下面的这个例子中hashCode怎么依赖equals之前,我想我实在没什么可说的class A {
      public int hashCode() {
        return (int) System.currentTimeMillis();
      }
      public boolean equals(Object obj) {
        return true;
      }
    }
      

  28.   

    TO treeroot(旗鲁特):hashCode与equals之间既然有强制关系,我就可以说两者分不开!!为何不对捏??
      

  29.   

    我已经说过,如果不用哈希表,hashCode就是多余的,多余的东西如何会有强制关系?
      

  30.   

    TO treeroot(旗鲁特):
     TO  ypdarling(冲动是魔鬼!) ( 
     因为当对象的hashCode相同时,哈希表是靠equals()来区分对象的。 这句话不准确,哈希表永远是更具equals来区分对象的,但是它有一个基本的规则:如果hashCode 不同,就认为他们一定不equals!我明白你的意思,你也应该明白我的意思,可能是我刚才用词不太严谨,把区分改成查找就应该没问题了。
      

  31.   

    TO: shine333(enihs) ,从语法角度,或许你可以说他们没有强制性吧!但使用容器时,你还可以说之间他们没有强制性吗?我说“应该是equals()是为hashCode相同而设定的”,就一点不对吗?
      

  32.   

    不好意思刚才掉线了!!发完这贴真下了,有事!!
    TO: shine333(enihs) ,从语法角度你可能是指HASHCODE()与TOSTRING()这样才算有强制关系的吧!!但是equals()与hashCode在使用某些容器时确实有有强制性!说他们分不开不过分,容器很多地方用得到!
    TO treeroot(旗鲁特):你钻牛角尖了
      

  33.   

    但使用容器时,仍然是没有强制性,因为容器都是接口,实现方式千差万别,连java.util.Map的class javadoc的最后都说More generally, implementations of the various Collections Framework interfaces are free to take advantage of the specified behavior of underlying Object methods wherever the implementor deems it appropriate. 也就是说,即使容器,实现的时候,也可以根本不用hashCode或者equals,甚至可能直接用==当然,这个情况很少会发生。所以,我也不再谈强制性的问题。关于“equals()是为hashCode相同而设定的”,此乃大谬也。我也不说两者之间互不隶属(不光语法强制无关,而且是在逻辑上,规范上)宇宙之中,各种事物何其之多,各种情况不可计数,岂是一个小小的32bit int可以区分?!难道因为hashCode碰巧相同,equals也要为了hashCode相同而忍气吞声?
      

  34.   

    又来了一个toString(),这方面不想回答。估计您从来没有自己override过。话又说回来,equals true/false,而hashCode理论上需要32-bit内平均分布,请问怎么依赖一个只有两种可能的事物,得出一个有2^32种可能的事物
      

  35.   

    treeroot(旗鲁特) ( ) 
    equals()是为hashCode不同而设定的!!!又是谬论!
    只有使用哈希表是才使用hashCode,equals在任何地方都会用到.
    如果你需要使用equals方法或者任何容器,就不要忽略它的存在.
    只有你需要使用哈希表时你才需要关注hashCode,而且一般要足够离散!
    ---------------正解.好多时候我们实现equals的时候都可以不用管hashCode.
      

  36.   

    完全同意treeroot(旗鲁特) ( ) 的观点.请看Sun JDK 文档是怎么说的吧.
    The general contract of hashCode is: 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. 
    实际上,如果我们的对象并不会放到HashMap中去的话,根本就不需要实现hashCode.是不是这么理解呢?
      

  37.   

    基本上是这样,不过更准确的说法,并不一定是HashMap/table,而是那些根据上面这个规范,进行hash操作的地方
      

  38.   

    事实上就是哈希表,如果它使用了hashCode其实他就是哈希表的实现jdk中包括 HashMap,LinkedHashMap,IdentityHashMap,Hashtable楼上还能列举其他情况?
      

  39.   

    当然HashSet本质上是HashMap
    LinkedHashSet本质上是LinkedHashMap
      

  40.   

    我说的是“不是HashMap/Hashtable”,我没有讲数据结构中的哈希表而且为什么一定要从JDK里面找?org.apache.commons.collection就不错:P
      

  41.   

    org.apache.commons.collection里边应该也有类似hashmap的东东吧,也是只有在用到这些东西时才需要实现hashCode()么?没用过,请指教.
      

  42.   

    总结一下,equals()是对象相等性比较,hashCode()是计算对象的散列值,当然他们的语句是对象的属性。对于equals,一般我们认为两个对象同类型并且所有属性相等的时候才是相等的,在类中必须改写equals,因为Object类中的equals只是判断两个引用变量是否引用同一对象,如果不是引用同一对象,即使两个对象的内容完全相同,也会返回false。当然,在类中改写这个equals时,你也可以只对部分属性进行比较,只要这些属性相同就认为对象是相等的。对于hashCode,只要是用在和哈希运算有关的地方,前面很多兄弟都提到了,和equals一样,在你的类中也应该改写。当然如果两个对象是完全相同的,那么他们的hashCode当然也是一样的,但是象前面所述,规则可以由你自己来定义,因此两者之间并没有什么必然的联系。当然,大多数情况下我们还是根据所有的属性来计算hashCode和进行相等性比较。
      

  43.   

    对不起,输入错误。总结一下,equals()是对象相等性比较,hashCode()是计算对象的散列值,当然他们的依据是对象的属性。
      

  44.   

    如果两个对象是equal的话,则hashCode必须相同。
    而不相等的两个对象的hashCode不并不相同,但是如果不相同可以提高hash table的效率。---《Effective Java》 P36
      

  45.   

    API的规范中有这样一句:
    Note that it is generally necessary to override the hashCode method whenever this method is overridden,so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes. public boolean equals(Object obj)Indicates whether some other object is "equal to" this one. 
    The equals method implements an equivalence relation on non-null object references: It is reflexive: for any non-null reference value x, x.equals(x) should return true. 
    It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true. 
    It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true. 
    It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified. 
    For any non-null reference value x, x.equals(null) should return false. 
    The equals method for class Object implements the most discriminating possible equivalence relation on objects; that is, for any non-null reference values x and y, this method returns true if and only if x and y refer to the same object (x == y has the value true). Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes. 
    Parameters:
    obj - the reference object with which to compare. 
    Returns:
    true if this object is the same as the obj argument; false otherwise.