因为会经常覆写equals方法，其目的是根据业务规则判断两个对象是否相等。
建议45：覆写equals方法时，不要识别不出自己
public boolean equals(Object obj){
if(obj instanceof Person){
Person p = (Person)obj;
return name.equalsIgnoreCase(p.getName().trim());
}
}
如果name本身含有空格，那样会导致不相等了。 违背了自反省
建议46：equals应该考虑null情况
对称性问题
上述name容易为null输入。
建议47：传递性
不要用instanceof来进行判断
要用getClass()进行判断，否则容易让子类绕过。
public boolean equals(Object obj){
if(obj !=null && obj.getClass() == this.getClass() ){
Person p = (Person)obj;
if( p.getName() == null || name = null ){
return false;
}
return name.equalsIgnoreCase(p.getName() );
}
}
建议48：覆写equals方法必须覆写hashCode方法
为什么呢？
Map的底层机制
以数组的形式保存Map条目。其中的关键是下标的处理机制：
依据传入元素的hashCode方法的返回值决定其数组的下标。如果该数组上已经有了Map条目，且与传入的键值相等的话则不处理，若不相等则覆盖；如果数组位置上没有条目，则插入。并加入到Map条目的链表中。同理检查键是否存在也是根据哈戏码确定位置，然后遍查找键值的。
HashCodeBuilder
建议49：推荐覆写toString方法
apache commons工具包中的ToStringBuilder类。