「Java 进阶之路」系列 Day20写在前面这是一个几乎每个人都踩过的坑给一个类重写了equals自信满满地觉得两个属性一样的对象现在应该被判定为相等了结果一放进HashSetcontains查一个属性完全一样的新对象返回的却是false。问题不在equals写错了而是漏了另一半——hashCode。这篇就把这两个方法为什么必须绑在一起讲清楚。一、是什么一个判断相等一个决定放哪equals定义的是逻辑相等两个对象即使不是同一个引用只要关心的属性都一样就应该被判定为相等。Object类默认的equals比较的是引用地址等价于——不重写的话两个属性完全一样的不同对象永远不相等。hashCode返回一个int本意是给基于哈希表的容器HashMap、HashSet、Hashtable用来快速定位数据该放进哪个桶bucket。Object默认的hashCode是跟对象内存地址相关的一个整数同一个对象只要没被移动多次调用返回值不变但和equals判定的逻辑相等完全没关系。二、为什么HashMap 靠这两个方法配合才能定位到对象hashCode的官方契约里有一条硬性规定两个对象用equals判定相等hashCode就必须相等反过来不要求——hashCode相同的两个对象完全可以不相等这叫哈希冲突哈希表本来就要处理这种情况。这条契约不是凭空定的而是HashMap.get(key)的查找过程决定的先算key.hashCode()用这个值定位到某个桶再在这个桶里逐个用equals比较找到真正相等的那一个key对象计算hashCode定位到某个桶桶内可能有多个entry逐个用equals比较找到匹配返回没有匹配判定不存在如果只重写了equals、没重写hashCode两个逻辑相等的对象会因为默认的hashCode基于地址不同从一开始就被分到了不同的桶——equals再准确也没用压根不会走到逐个比较这一步。这就是为什么这两个方法必须成对重写equals负责终点的精确比较hashCode负责能不能先走到这个终点。三、怎么用三个容易踩的坑classPoint{intx,y;Point(intx,inty){this.xx;this.yy;}Overridepublicbooleanequals(Objecto){if(thiso)returntrue;if(!(oinstanceofPoint))returnfalse;Pointp(Point)o;returnxp.xyp.y;}// 没有重写 hashCode}SetPointpointsnewHashSet();points.add(newPoint(1,2));System.out.println(points.contains(newPoint(1,2)));// false逻辑相等的对象却查不到正确做法是让hashCode用和equals完全一致的字段来计算OverridepublicinthashCode(){returnObjects.hash(x,y);}Objects.hash内部就是把每个字段的hashCode按31做累乘累加IDE 自动生成、Lombok 的EqualsAndHashCode走的也是同一套思路。一个更隐蔽的坑用可变字段参与hashCode计算。对象放进HashSet之后如果再去修改参与hashCode计算的字段这个对象的hashCode会变但它在哈希表里的桶位置是插入那一刻就定死的、不会跟着重新调整——于是这个对象实际上迷失了后续用contains/remove都定位不到它原来所在的桶看起来就像对象凭空消失。参与equals/hashCode计算的字段最好是不可变的或者整个对象干脆设计成不可变对象。另一个容易忽略的坑类型检查该用instanceof还是getClass()。上面Point的equals用的是instanceof如果Point被继承出一个ColorPoint多了一个颜色字段instanceof会认为父类的Point(1, 2)和子类的ColorPoint(1, 2, 红色)只要坐标一样就相等——但反过来ColorPoint的equals通常会比较颜色判定两者不相等。这样就出现了p.equals(cp)为true、cp.equals(p)为false破坏了equals契约里的对称性a.equals(b)和b.equals(a)结果必须一致。改用o.getClass() ! this.getClass()判断类型能规避这个问题要求类型完全一致父子类之间永远不相等代价是丧失了父类引用可以和子类对象比较的灵活性——这也是为什么《Effective Java》建议优先用组合代替继承来复用带equals的类从设计上绕开这个两难。四、面试追问Q1为什么重写 equals 一定要重写 hashCode因为HashMap/HashSet这类基于哈希表的容器查找时先用hashCode()定位桶再在桶内用equals()精确比较。只重写equals不重写hashCode两个equals判定相等的对象会因为默认hashCode基于地址不同而被分到不同桶导致contains/get永远找不到本该相等的元素违反了equals相等则hashCode必须相等这条硬性契约。Q2hashCode 相等的两个对象equals 一定相等吗不一定。hashCode允许出现哈希冲突equals不相等的对象完全可以有相同的hashCode反过来equals相等则hashCode必须相等这是单向约束不能反过来推。Q3用可变字段参与 hashCode 计算会有什么风险对象放入哈希表之后如果修改了参与hashCode计算的字段对象的hashCode会变但它在哈希表里的桶位置是插入时就定死的不会跟着重新调整于是这个对象实际上丢失了——后续用get/contains/remove都找不到它。所以参与计算的字段最好是不可变的。Q4Object 类默认的 equals 和 hashCode 分别是什么行为默认equals比较的是引用地址等价于默认hashCode返回一个跟对象内存地址相关的整数同一个对象多次调用结果不变但和逻辑相等没有关系。不重写的话两个属性完全一样的不同对象永远被判定为不相等。Q5用 Lombok 的EqualsAndHashCode或 IDE 自动生成时要注意什么要确认参与计算的字段集合和业务定义的相等语义一致——比如继承关系下父类字段有没有正确纳入集合类字段参与计算时要保证不可变、不会在放入哈希表之后被修改如果手动排除了部分字段要保证equals和hashCode排除的是同一批字段不能两边字段集合对不上否则照样违反契约。Q6equals 里用 instanceof 判断类型可能有什么问题如果这个类被继承子类通常会在equals里多比较自己新增的字段。这样一来父类对象和子类对象比较时父类的equals用instanceof可能判定两者相等但子类的equals会因为多出来的字段判定不相等导致a.equals(b)和b.equals(a)结果不一致破坏了equals契约里的对称性。改用getClass()做严格的类型比较能规避这个问题代价是父类和子类对象之间永远不可能相等。下一篇预告模块二到这里就收尾了Day21 开始进入模块三集合框架ArrayList和LinkedList到底该怎么选从源码层面把两者的性能差异掰开揉碎讲清楚。
「Java 进阶之路」系列 Day20写在前面这是一个几乎每个人都踩过的坑给一个类重写了equals自信满满地觉得两个属性一样的对象现在应该被判定为相等了结果一放进HashSetcontains查一个属性完全一样的新对象返回的却是false。问题不在equals写错了而是漏了另一半——hashCode。这篇就把这两个方法为什么必须绑在一起讲清楚。一、是什么一个判断相等一个决定放哪equals定义的是逻辑相等两个对象即使不是同一个引用只要关心的属性都一样就应该被判定为相等。Object类默认的equals比较的是引用地址等价于——不重写的话两个属性完全一样的不同对象永远不相等。hashCode返回一个int本意是给基于哈希表的容器HashMap、HashSet、Hashtable用来快速定位数据该放进哪个桶bucket。Object默认的hashCode是跟对象内存地址相关的一个整数同一个对象只要没被移动多次调用返回值不变但和equals判定的逻辑相等完全没关系。二、为什么HashMap 靠这两个方法配合才能定位到对象hashCode的官方契约里有一条硬性规定两个对象用equals判定相等hashCode就必须相等反过来不要求——hashCode相同的两个对象完全可以不相等这叫哈希冲突哈希表本来就要处理这种情况。这条契约不是凭空定的而是HashMap.get(key)的查找过程决定的先算key.hashCode()用这个值定位到某个桶再在这个桶里逐个用equals比较找到真正相等的那一个key对象计算hashCode定位到某个桶桶内可能有多个entry逐个用equals比较找到匹配返回没有匹配判定不存在如果只重写了equals、没重写hashCode两个逻辑相等的对象会因为默认的hashCode基于地址不同从一开始就被分到了不同的桶——equals再准确也没用压根不会走到逐个比较这一步。这就是为什么这两个方法必须成对重写equals负责终点的精确比较hashCode负责能不能先走到这个终点。三、怎么用三个容易踩的坑classPoint{intx,y;Point(intx,inty){this.xx;this.yy;}Overridepublicbooleanequals(Objecto){if(thiso)returntrue;if(!(oinstanceofPoint))returnfalse;Pointp(Point)o;returnxp.xyp.y;}// 没有重写 hashCode}SetPointpointsnewHashSet();points.add(newPoint(1,2));System.out.println(points.contains(newPoint(1,2)));// false逻辑相等的对象却查不到正确做法是让hashCode用和equals完全一致的字段来计算OverridepublicinthashCode(){returnObjects.hash(x,y);}Objects.hash内部就是把每个字段的hashCode按31做累乘累加IDE 自动生成、Lombok 的EqualsAndHashCode走的也是同一套思路。一个更隐蔽的坑用可变字段参与hashCode计算。对象放进HashSet之后如果再去修改参与hashCode计算的字段这个对象的hashCode会变但它在哈希表里的桶位置是插入那一刻就定死的、不会跟着重新调整——于是这个对象实际上迷失了后续用contains/remove都定位不到它原来所在的桶看起来就像对象凭空消失。参与equals/hashCode计算的字段最好是不可变的或者整个对象干脆设计成不可变对象。另一个容易忽略的坑类型检查该用instanceof还是getClass()。上面Point的equals用的是instanceof如果Point被继承出一个ColorPoint多了一个颜色字段instanceof会认为父类的Point(1, 2)和子类的ColorPoint(1, 2, 红色)只要坐标一样就相等——但反过来ColorPoint的equals通常会比较颜色判定两者不相等。这样就出现了p.equals(cp)为true、cp.equals(p)为false破坏了equals契约里的对称性a.equals(b)和b.equals(a)结果必须一致。改用o.getClass() ! this.getClass()判断类型能规避这个问题要求类型完全一致父子类之间永远不相等代价是丧失了父类引用可以和子类对象比较的灵活性——这也是为什么《Effective Java》建议优先用组合代替继承来复用带equals的类从设计上绕开这个两难。四、面试追问Q1为什么重写 equals 一定要重写 hashCode因为HashMap/HashSet这类基于哈希表的容器查找时先用hashCode()定位桶再在桶内用equals()精确比较。只重写equals不重写hashCode两个equals判定相等的对象会因为默认hashCode基于地址不同而被分到不同桶导致contains/get永远找不到本该相等的元素违反了equals相等则hashCode必须相等这条硬性契约。Q2hashCode 相等的两个对象equals 一定相等吗不一定。hashCode允许出现哈希冲突equals不相等的对象完全可以有相同的hashCode反过来equals相等则hashCode必须相等这是单向约束不能反过来推。Q3用可变字段参与 hashCode 计算会有什么风险对象放入哈希表之后如果修改了参与hashCode计算的字段对象的hashCode会变但它在哈希表里的桶位置是插入时就定死的不会跟着重新调整于是这个对象实际上丢失了——后续用get/contains/remove都找不到它。所以参与计算的字段最好是不可变的。Q4Object 类默认的 equals 和 hashCode 分别是什么行为默认equals比较的是引用地址等价于默认hashCode返回一个跟对象内存地址相关的整数同一个对象多次调用结果不变但和逻辑相等没有关系。不重写的话两个属性完全一样的不同对象永远被判定为不相等。Q5用 Lombok 的EqualsAndHashCode或 IDE 自动生成时要注意什么要确认参与计算的字段集合和业务定义的相等语义一致——比如继承关系下父类字段有没有正确纳入集合类字段参与计算时要保证不可变、不会在放入哈希表之后被修改如果手动排除了部分字段要保证equals和hashCode排除的是同一批字段不能两边字段集合对不上否则照样违反契约。Q6equals 里用 instanceof 判断类型可能有什么问题如果这个类被继承子类通常会在equals里多比较自己新增的字段。这样一来父类对象和子类对象比较时父类的equals用instanceof可能判定两者相等但子类的equals会因为多出来的字段判定不相等导致a.equals(b)和b.equals(a)结果不一致破坏了equals契约里的对称性。改用getClass()做严格的类型比较能规避这个问题代价是父类和子类对象之间永远不可能相等。下一篇预告模块二到这里就收尾了Day21 开始进入模块三集合框架ArrayList和LinkedList到底该怎么选从源码层面把两者的性能差异掰开揉碎讲清楚。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
