重写了hashCode()方法,还用重写equals()吗?
那equals()不就是比较两个对象的hashCode()吗?

解决方案 »

  1.   

    equals方法最好要跟hashcode逻辑一致,即equals比较的是对象的hashcode
      

  2.   

    不是这样的,如果该对象没有重写object的equals方法,equals比较的是对象的hashcode。
      

  3.   

    equals并不是自动比较的hashcode值,
    在都不重写的时候
    equals比较的是对象的内存地址
    hashcode打印的也是对象的内存地址
    所有看起来equals比较靠的是hashcode
    其实可以不一样
      

  4.   

    1、不重写equals方法,两个对象互相equals比较的是对象的地址;
    2、集合里面元素,重写equals()的时候要重写hashcode(),如hashset、treeset、hashmap等;
      

  5.   

    楼上纯属菜鸟,乱扯先搞明白什么是地址好吗?害人家可不好。。
    下面这个这个比较严谨:
    如果该对象没有重写object的equals方法,equals比较的是对象的hashcode。
     
     
      

  6.   


    /**
     *一般equals的效率能更高一些,比如
     *hashcode就是简单的理解就是计算对象的权值(就是一种特殊值,只有内容相等的才会一样)
     *而就是是在必须进行hashcode的时候才会去调用hashcode
     *
     */
    //比如这是一个hashcode算法,计算比较复杂吧
    hashcode(){ return  ((n*(n-1)+ n - (n - 1)  ) + (n - 2) ..... - 1)}equals (Object obj){
              //判断引用是否相等,如果等就直接返回,不用计算hashcode的值
              if( this == obj)
              {
                    return true;
              }
              else{
                   if(obj instanceof this.getClass().getName())
                   {
                          //这里才真正计算hashcode ,所以效率比较高
                          if(this.hashcode() == obj.hashcode())
                          {
                                return ture;
                          }
                          else
                          {
                                return false;
                          }
                   }
                   else
                   {
                          return false;
                   }            
              }
    }
    个人看法,仅供参考
      

  7.   

    概念设计上是要求同时提供两个,JDK API 是这么说的,hashCode 主要用来支持像 HashMap 这样的工具类,JDK 提供一个参考模型,JCF (集合类都需要用到它)我们按它的来就行了。不是外国人常说,不要重复发明轮子吗。虽然我们也可以提供我们自己的支持 hash 的方法,但没有必要。你不同时提供 hashcode 和 equals 也没关系,但是设计上可能会将问题搞得复杂化。在做大型软件时,几乎每个细节都必须坚持同一个标准才能降低复杂性,否则你根本估计不到将来的 bug 从什么地方会冒出来。人家 JDK 这样说有他们深刻的体会,写出 JVM /JDK 的人都是写过 20 多年代码的人和他们带领的徒弟。
      

  8.   

    我觉得equals和hashCode之间没有什么关系。你可以随便实现,比如可以让equals永远返回true,但是老是去抠的话就没有什么意义了,和人们平时的理解不一致。所以一般重写equals方法的时候要重写hashCode方法,为的是遵循一种约定(contract):两个在equals的意义下相等(equal)的对象应该有相等的hash codes(但并没有说hash codes相等就一定equals)。这些约定都是一些实践的需要,java语言规范并没有要求equals和hashCode两个方法一定要有什么关系或满足什么条件。
      

  9.   

    比较两个对象的时候,会先比较 hashcode,如果不相等,再调用 equals()。 只要 Hashcode和 equals()有一个认为相等,就认为两个对象相等。当然,这里不是指直接用 hashcode==hashcode,或者 直接调用 equals的地方,而是指系统内的一些实现,例如 HashMap中对key的比较。所以,假设你需要用一个对象做key,默认的hashcode是不同的,你可以覆盖hashcode()这个方法,也可以覆盖 equals方法。 如果你覆盖了 hashcode方法,让他们相等,那么equals方法不会被调用;通常的做法是不覆盖hashcode方法,而是覆盖 equals方法。 这么做还有一个原因,hashcode通常只在生成对象时被调用一次。所以,如果这个对象不是一个不可修改对象,那么使用hashcode可能导致错误。
    例如,使用 class { String a; int b} 的实例作为Key,K={a="hi", b=2}的对象的hashcode假设是 1000,然后用它做key, hashmap.put( K, "something");后,把改对象的成员 a 改为 其他值,例如 K.a="hello", 然后再用它做key,调用 hashmap.get(K), 你就会发现,即使是实际内容已经变了,但是还是返回“somnthing”。
      

  10.   

    http://blog.csdn.net/michaellufhl/archive/2010/08/23/5833188.aspx
      

  11.   

    hashCode相等,equals不一定相等;
    equals相等,hashCode一定相等。
      

  12.   

    不重写hashCode的时候,返回的通常是对象的内存地址,JDK文档原文是"typically implemented by converting the internal address of the object into an integer"。另外,文档说,重写equals,就必须重写hashCode,因为hashCode规定,如果a.equals(b)==true,则必有a.hashCode()==b.hashCode()。原文是
    " so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes." 不重写equals的时候,比较的是引用(Reference),也就是内存地址,见JDK的源码:
        public boolean equals(Object obj) {
    return (this == obj);
        }
    这个实现是符合上面的规定的。如果重写了equals,就有可能打破了上面的规定。这是因为,你自己定义的equals有可能让地址不同(也就是hashCode不同)的两个对象相等。所以要将hashCode一并重写。注意,这个关系是单向的,java并不要求hashCode相同的对象一定要相互equal。
      

  13.   

    什么是集合?collection吗?
      

  14.   

    容器,collection是接口,为了判断往容器里面添加的元素是否重复,就是根据hashcode()和equals()来决定的
      

  15.   

    equals比较的不是对象的内容吗?好像“==”比较的才是内存地址吧