软件构造学习笔记：Java对象的等价性的特殊情况

简述

Java中用于测试对象的等价性有三个操作符：== ， != 和 Equals()对于基本类型即int，boolean， byte 等等来说，==和 != 比较的是 基本类型的内容，这和c、c++是一样的；

对于其他类型来说， == 和 != 比较的是对象的引用，显然是不等的，如果要比较对象之间的内容，对象所属的类型必须实现Equals()方法（大多数Java类库中都实现了Equals方法），如果没有实现Equals方法，会自动调用object中的Equals方法，而该方法是用来比较“地址”的，因此结果会是false。

两个有趣的问题

第一个有趣的问题

但是后来发现两个奇怪的问题，第一个问题，如下这段代码，输出的却是true。

原来Integer i = 11这种赋值方式会调用Integer的ValueOf()将其缓存(如果不在-128 ~ 127之间则不会缓存)为基本类型（jvm会为Integer预先分配一部分内存，在以后有请求Integer对象时，若值位于-128~127时，系统都会让它指向这个预分配好的Integer对象）

Integer与int比较相等时，会将Integer转换为进行转换为int再比较，所以最终比较的是内容。

第二个有趣的问题

第二个问题则更加有趣：

众所周知，Stringbuilder是String类型的mutable替代，为什么本应满足观察等价性的比较却返回了false呢？原来Stringbuilder没有重写Objects.equals()，所以调用 equals 仅仅是判断两个对象的引用是否相同（mutable 类型的行为等价性），因此不等价。

还有一件有趣的事

很多同学（我自己）习惯性的用观察等价性替换“相等”的概念，这就容易导致一个误区——不喜欢重写Hashcode方法
事实上这样是不正确滴，原因诸多，说一个最简单的：
在java底层的集合框架中（如HashMap，HashSet等），为了提高查询的效率，在确定某个对象的存储位置时，往往需要通过调用对象的hashCode方法来实现。如果被查询的对象不过是基本数据类型的包装类那么自然万事大吉，Hashcode都是被重写过的。不过，一旦我们试图查询一些自己定义的类型就容易不妙：
以下Sudent类只重写了，Object的equals方法，没有重写hashCode方法

测试一下：

测试结果：

按照我们的常规理解，只要两个学生对象的id和name是一样的，我们就可以认为这两个学生对象指的是同一个人，因此重写了equals方法，让Student对象只要name和id相同就返回true，而且并没有重写hashCode方法

在测试中，新建了两个Student对象，并且让他们的id和name完全一样，在调用equals方法时，返回为true，说明这两个对象时相等的。但是由于没有重写hashCode方法，所以这两个对象调用的hashCode还是Object类那里的hashCode方法，并且他们的值并不相等

在这种情形下，就容易导致我们将两个相同的学生放进同一Hashset，调用size（）方法却返回2的诡异bug

务必小心！