hashCode()返回该对象的哈希码值，该值通常是一个由该对象的内部地址转换而来的整数，它的实现主要是为了提高哈希表的性能。在每个重写了equals方法的类中，你必须也要重写hashCode方法。如果不这样做的话，就会违反Object.hashCode的通用约定，从而导致该类无法与所有基于散列值(hash)的集合类结合在一起正常运作。

下面是hashCode约定的内容，来自java.lang.Object的规范：

l在一个Java应用程序执行期间，如果一个对象的equals方法做比较所用到的信息没有被修改的话，那么，对该对象调用hashCode方法多次，它必须始终如一地返回同一个整数。在同一个应用程序的多次执行过程中，这个整数可以不同。

l如果两个对象根据equals(Object)方法是相等的，那么对这两个对象中的每一个对象调用hashCode方法都必须生成相同的整数结果。

l如果两个对象根据equals(Object)方法是不相等的，那么调用这两个对象中任一个对象的hashCode方法，不要求必须产生不同的整数结果。然而，程序员应该意识到这样的事实，对于不相等的对象产生截然不同的整数结果，有可能提高散列表的性能。

下面我们仍然用上一篇文章“(override)重写equals()方法”中所用的例子，来详细解释上面约定的内容：

public class ColorPoint{

    private Point point;

    private Color color;

    public ColorPoint(int x, int y, Color color){

        point = new Point(x, y);

        this.color = color;

    }

    //返回一个与该有色点在同一位置上的普通Point对象

    public Point asPoint(){

        return point;

    }

    public boolean equals(Object o){

        if(o == this)

            return true;

        if(!(o instanceof ColorPoint))

            return false;

        ColorPoint cp = (ColorPoint)o;

        return cp.point.equals(point)&&

cp.color.equals(color);

        }

}

假设你试图将这个类与HashMap一起使用：

public class Test{

　　public static void main(String[] args){

　　　　Map m = new HashMap();

　　　　m.put(new ColorPoint(1,2,Color.RED),”red”);

　　　　System.out.println(m.get(

　　　　　　new ColorPoint(1,2,Color.RED)));

　　}

}

这时候，你可能会期望程序返回并输出”red”，但是实际的运行结果是：null。为什么呢？因为这里涉及到两个ColorPoint实例：第一个被用于插入到HashMap中，第二个实例与第一个相等，被用于(试图)检索。由于ColorPoint类没有重写hashCode方法，从而导致两个相等的实例具有不相等的散列码，违反了hashCode的约定。因此，要想解决这个问题,只需为ColorPoint类提供一个适当的hashCode方法既可。

如何编写一个适当的hashCode方法呢？下面是我从《Effective Java》一书中摘抄而来的“诀窍”：

1.    把某个非零常数值，比如说17，保存在一个int类型的变量result中。

2.    对于对象中每个关键域f(指equals方法中考虑的每个域)，完成以下步骤：

A.    为该域计算int类型的散列码c:

a.    如果该域是boolean类型，则计算(f ? 0 : 1)。

b.    如果该域是byte、char、short或int类型，则计算(int)f。

c.    如果该域是long类型，则计算(int)(f ^ (f >>> 32))。

d.    如果该域是float类型，则计算Float.floatToIntBits(f)。

e.    如果该域是double类型，则计算Double.doubleToLongBits(f)得到一个long类型的值，然后按照步骤2.A.c ，对该long型值计算散列值。

f.    如果该域是一个对象引用，并且该类的equals方法通过递归调用equals的方式来比较这个域，则同样对该域递归调用hashCode。

g.    如果该域是一个数组，则把每一个元素当做一个单独的域来处理。也就是说，递归地应用上述规则，对每个重要的元素计算散列值。

B.    按照下面的公式，把步骤A中计算得到的散列码c组合到result中:

result = 37*result + c;

3.    返回result。

4.    写完了hashCode方法之后，问自己“是否相等的实例具有相等的散列码”。如果不是的话，请找出原因，并修正错误。

现在，我们把这种方法用到ColorPoint类中。它有两个关键域，都是对象引用类型。根据上面的步骤，很直接地会得到下面的散列函数：

public int hashCode(){

　　int result = 17;

　　result = 37*result + point.hashCode();

　　result = 37*result + color.hashCode();

　　return result;

}

接下来还要为Point类重写hashCode方法，它有两个关键域，都是int类型，添加如下代码：

public int hashCode(){

　　int result = 17;

result = 37*result + x;

result = 37*result + y;

return result;

}

最后，我们再次运行上面的Test类，看看实际的运行结果是否和我们期望的一样。亲爱的朋友们，你们的运行结果怎样？请用留言的方式来告诉我。

我们知道每一个java类都继承自Object类，equals()是Object类中提供的方法之一。那么，让我们先来看看Object#equals()在Java中的原代码：

publicboolean equals(Object obj) {

   return (this == obj);

}

可以看出，只有当一个实例等于它本身的时候，equals()才会返回true值。通俗地说，此时比较的是两个引用是否指向内存中的同一个对象，也可以称做是否实例相等。而我们在使用equals()来比较两个指向值对象的引用的时候，往往希望知道它们逻辑上是否相等，而不是它们是否指向同一个对象。在这样的情况下，如果超类也没有重写equals()以实现期望的行为，这时我们就需要重写equals方法。而且这样做也使得这个类的实例可以被用做映射表(map)的键，或者集合(set)的元素，并使映射表或者集合表现出预期的行为。

怎样重写equals()方法？

重写equals()方法看起来非常简单，但是有许多改写的方式会导致错误，并且后果非常严重。要想正确改写equals()方法，你必须要遵守它的通用约定。下面是约定的内容，来自java.lang.Object的规范：

equals方法实现了等价关系(equivalence relation):

1. 自反性：对于任意的引用值x，x.equals(x)一定为true。

2. 对称性：对于任意的引用值x 和 y，当x.equals(y)返回true时，y.equals(x)也一定返回true。

3. 传递性：对于任意的引用值x、y和ｚ，如果x.equals(y)返回true，并且y.equals(z)也返回true，那么x.equals(z)也一定返回true。

4. 一致性：对于任意的引用值x 和 y，如果用于equals比较的对象信息没有被修改的话，那么，多次调用x.equals(y)要么一致地返回true，要么一致地返回false。

5. 非空性：对于任意的非空引用值x，x.equals(null)一定返回false。

接下来我们通过实例来理解上面的约定。我们首先以一个简单的非可变的二维点类作为开始：

public class Point{

    private final int x;

    private final int y;

    public Point(int x, int y){

        this.x = x;

        this.y = y;

    }

    public boolean equals(Object o){

        if(!(o instanceof Point))

            return false;

        Point p = (Point)o;

        return p.x == x && p.y == y;

    }

    ………

}

假设你想要扩展这个类，为一个点增加颜色信息：

public class ColorPoint extends Point{

    private Color color;

    public ColorPoint(int x, int y, Color color){

        super(x, y);

        this.color = color;

    }

    //override equasl()

    public boolean equals(Object o){

        if(!(o instanceof ColorPoint))

            return false;

        ColorPoint cp = (ColorPoint)o;

        return super.equals(o) && cp.color==color;

    }

    ………

}

我们重写了equals方法，只有当实参是另一个有色点，并且具有同样的位置和颜色的时候，它才返回true。可这个方法的问题在于，你在比较一个普通点和一个有色点，以及反过来的情形的时候，可能会得到不同的结果：

public static void main(String[] args){

    Point p = new Point(1, 2);

    ColorPoint cp=new ColorPoint(1,2, Color.RED);

    System.out.println(p.equals(cp));

    System.out.println(cp.eqauls(p));

}

运行结果：

true   

false

这样的结果显然违反了对称性，你可以做这样的尝试来修正这个问题：让ColorPoint.equals在进行“混合比较”的时候忽略颜色信息：

public boolean equals(Object o){

    if(!(o instanceof Point))

        return false;

    //如果o是一个普通点，就忽略颜色信息

    if(!(o instanceof ColorPoint))

        return o.equals(this);

    //如果o是一个有色点，就做完整的比较

    ColorPoint cp = (ColorPoint)o;

    return super.equals(o) && cp.color==color;

}

这种方法的结果会怎样呢？让我们先来测试一下：

public static void main(String[] args){

    ColorPoint p1=new ColorPoint(1,2, Color.RED);

    Point p2 = new Point(1, 2);

    ColorPoint p3=new ColorPoint(1,2, Color.BLUE);

    System.out.println(p1.equals(p2));

    System.out.println(p2.equals(p1));

    System.out.println(p2.equals(p3));

    System.out.println(p1.eqauls(p3));

}

运行结果：

true

true

true

false

这种方法确实提供了对称性，但是却牺牲了传递性(按照约定，p1.equals(p2)和p2.eqauals(p3)都返回true，p1.equals(p3)也应返回true)。要怎么解决呢？事实上，这是面向对象语言中关于等价关系的一个基本问题。要想在扩展一个可实例化的类的同时，既要增加新的特征，同时还要保留equals约定，没有一个简单的办法可以做到这一点。新的解决办法就是不再让ColorPoint扩展Point，而是在ColorPoint中加入一个私有的Point域，以及一个公有的视图(view)方法：

public class ColorPoint{

    private Point point;

    private Color color;

    public ColorPoint(int x, int y, Color color){

        point = new Point(x, y);

        this.color = color;

    }

    //返回一个与该有色点在同一位置上的普通Point对象

    public Point asPoint(){

        return point;

    }

    public boolean equals(Object o){

        if(o == this)

            return true;

        if(!(o instanceof ColorPoint))

            return false;

        ColorPoint cp = (ColorPoint)o;

        return cp.point.equals(point)&&

cp.color.equals(color);

        }

}

还有另外一个解决的办法就是把Point设计成一个抽象的类(abstract class)，这样你就可以在该抽象类的子类中增加新的特征，而不会违反equals约定。因为抽象类无法创建类的实例，那么前面所述的种种问题都不会发生。

重写equals方法的诀窍：

1. 使用==操作符检查“实参是否为指向对象的一个引用”。

2. 使用instanceof操作符检查“实参是否为正确的类型”。

3. 把实参转换到正确的类型。

4. 对于该类中每一个“关键”域，检查实参中的域与当前对象中对应的域值是否匹配。对于既不是float也不是double类型的基本类型的域，可以使用==操作符进行比较；对于对象引用类型的域，可以递归地调用所引用的对象的equals方法；对于float类型的域，先使用Float.floatToIntBits转换成int类型的值，然后使用==操作符比较int类型的值；对于double类型的域，先使用Double.doubleToLongBits转换成long类型的值，然后使用==操作符比较long类型的值。 

5. 当你编写完成了equals方法之后，应该问自己三个问题：它是否是对称的、传递的、一致的？(其他两个特性通常会自行满足)如果答案是否定的，那么请找到这些特性未能满足的原因，再修改equals方法的代码。

　　abstract和interface在Java语言中都是用来进行抽象类定义的，那么什么是抽象类，使用抽象类能为我们带来什么好处呢？

　　在面向对象的概念中，我们知道所有的对象都是通过类来描绘的，但是反过来却不是这样并不是所有的类都是用来描绘对象的，如果一个类中没有包含足够的信息来描绘一个具体的对象，这样的类就是抽象类。抽象类往往用来表征我们在对问题领域进行分析、设计中得出的抽象概念，是对一系列看上去不同，但是本质上相同的具体概念的抽象。比如：如果我们进行一个图形编辑软件的开发，就会发现问题领域存在着圆、三角形这样一些具体概念，它们是不同的，但是它们又都属于形状这样一个概念，形状这个概念在问题领域是不存在的，它就是一个抽象概念。正是因为抽象的概念在问题领域没有对应的具体概念，所以用以表征抽象概念的抽象类是不能够实例化的。 

　　在面向对象领域，抽象类主要用来进行类型隐藏。我们可以构造出一个固定的一组行为的抽象描述，但是这组行为却能够有任意个可能的具体实现方式。这个抽象描述就是抽象类，而这一组任意个可能的具体实现则表现为所有可能的派生类。模块可以操作一个抽象体。由于模块依赖于一个固定的抽象体，因此它可以是不允许修改的；同时，通过从这个抽象体派生，也可扩展此模块的行为功能。熟悉OCP的读者一定知道，为了能够实现面向对象设计一个最核心的原则OCP(Open-Closed Principle)，抽象类是其中的关键所在。

从语法定义层面看abstract class和interface 

　　在语法层面，Java语言对于abstract class和interface给出了不同的定义方式，下面以定义一个名为Demo的抽象类为例来说明这种不同。

使用abstract class的方式定义Demo抽象类的方式如下：
abstract class Demo ｛ 
　　abstract void method1(); 
　　abstract void method2(); 
　　…
｝

使用interface的方式定义Demo抽象类的方式如下：
interface Demo { 
　　void method1(); 
　　void method2(); 
　　…
} 

　　在abstract class方式中，Demo可以有自己的数据成员，也可以有非abstarct的成员方法，而在interface方式的实现中，Demo只能够有静态的不能被修改的数据成员(也就是必须是static final的,不过在interface中一般不定义数据成员),所有的成员方法都是abstract的。从某种意义上说，interface是一种特殊形式的abstract class。 

　　从编程的角度来看，abstract class和interface都可以用来实现"design by contract"的思想。但是在具体的使用上面还是有一些区别的。 

　　首先，abstract class在Java语言中表示的是一种继承关系，一个类只能使用一次继承关系。但是，一个类却可以实现多个interface。也许这是Java语言的设计者在考虑Java对于多重继承的支持方面的一种折中考虑吧。 

　　其次，在abstract class的定义中，我们可以赋予方法的默认行为。但是在interface的定义中，方法却不能拥有默认行为，为了绕过这个限制，必须使用委托，但是这会增加一些复杂性，有时会造成很大的麻烦。 

　　在抽象类中不能定义默认行为还存在另一个比较严重的问题，那就是可能会造成维护上的麻烦。因为如果后来想修改类的界面（一般通过abstract class或者interface来表示）以适应新的情况（比如，添加新的方法或者给已用的方法中添加新的参数）时，就会非常的麻烦，可能要花费很多的时间（对于派生类很多的情况，尤为如此）。但是如果界面是通过abstract class来实现的，那么可能就只需要修改定义在abstract class中的默认行为就可以了。 

　　同样，如果不能在抽象类中定义默认行为，就会导致同样的方法实现出现在该抽象类的每一个派生类中，违反了"one rule，one place"原则，造成代码重复，同样不利于以后的维护。因此，在abstract class和interface间进行选择时要非常的小心。

从设计理念层面看abstract class和interface 

　　上面主要从语法定义和编程的角度论述了abstract class和interface的区别，这些层面的区别是比较低层次的、非本质的。本小节将从另一个层面：abstract class和interface所反映出的设计理念，来分析一下二者的区别。作者认为，从这个层面进行分析才能理解二者概念的本质所在。 

　　前面已经提到过，abstarct class在Java语言中体现了一种继承关系，要想使得继承关系合理，父类和派生类之间必须存在"is a"关系，即父类和派生类在概念本质上应该是相同的。对于interface来说则不然，并不要求interface的实现者和interface定义在概念本质上是一致的，仅仅是实现了interface定义的契约而已。

　　abstract class和interface是Java语言中的两种定义抽象类的方式，它们之间有很大的相似性。但是对于它们的选择却又往往反映出对于问题领域中的概念本质的理解、对于设计意图的反映是否正确、合理，因为它们表现了概念间的不同的关系（虽然都能够实现需求的功能）。这其实也是语言的一种的惯用法，希望读者朋友能够细细体会。