豆瓣评分9.8的图书《Effective Java》,是当今世界顶尖高手Josh Bloch的著作,在我之前的文章里我也提到过,编程就像练武,既需要外在的武功招式(编程语言、工具、中间件等等),也需要修炼心法(设计模式、源码等等) 学霸、学神OR开挂
我个人在Java领域也已经学习了近5年,在修炼“内功”的方面也通过各种途径接触到了一些编程规约,例如阿里巴巴的泰山版规约,在此基础下读这本书的时候仍是让我受到了很大的冲激,学习到了很多约定背后的细节问题,还有一些让我欣赏此书的点是,书中对于编程规约的解释让我感到十分受用,并愿意将他们应用在我的工作中,也提醒了我要把阅读JDK源码的任务提上日程。
最后想分享一下我个人目前的看法,内功修炼不像学习一个新的工具那么简单,其主旨在于踏实,深入探索底层原理的过程很缓慢并且是艰辛的,但一旦开悟,修为一定会突破瓶颈,达到更高的境界,这远远不是我通过一两篇博客就能学到的东西。
接下来就针对此书列举一下我的收获与思考。
不过还是要吐槽一下的是翻译版属实让人一言难尽,有些地方会有误导的效果,你比如java语言里extends是继承的关键字,书本中全部翻译成了扩展就完全不是原来的意思了。所以建议有问题的地方对照英文原版进行语义上的理解。
没有时间读原作的同学可以参考我这篇文章。
10 覆盖equals时要遵守通用约定
覆盖equals方法要注意的点特别多,并且很容易出错,下面四种情况最好不覆盖equals:
- 类的每个实例本质上都是唯一的 例如:Thread这种代表活动实体而不是值的类
- 类没有必要提供“逻辑相等”的测试功能 例如:正则表达式类Pattern就没有必要设计检查两个Pattern实例是否代表同一个正则表达式,因为没意义
- 父类已经覆盖了equals,如果功能合适的话,子类能不覆盖就不要覆盖 例如:List从AbstractList继承equals
- 类是private或default的 这样以来可以确定它的equals方法不会被调用
需要覆盖equals方法的情况:
- 类有自己的“逻辑相等”的概念,比如假设两个Student类如果name相同则认为是同一个实例的话,就需要覆盖equals方法
枚举类型也不需要覆盖equals方法,因为每个值至多只有一个对象。
接下来的讨论将重点围绕在等价关系的5个属性上: 1. 自反性:若x != null,则x.equals(x)=true
2. 对称性:若x != null,y != null,当y.equals(x)=true时,x.equals(y)=true 编写自定义类和Java标准类库中比较相等逻辑时,可能会无意间违反这一条规则
public final class CaseInsensitiveString {
private final String s;
public CaseInsensitiveString(String s){
this.s = s;
}
@Override
public boolean equals(Object o) {
if (o instanceof CaseInsensitiveString)
return s.equalsIgnoreCase(((CaseInsensitiveString) o).s);
if (o instanceof String)
return s.equalsIgnoreCase((String) o);
return false;
}
}
上面代码实现了一个不区分大小写的字符串,接下来使用下面两个对象进行比较
CaseInsensitiveString cis = new CaseInsensitiveString("Polish");
String s = "polish";
cis.equals(s)返回true,但s.equals(cis)返回false,原因在于String中的equals方法并不知道我们定义的类CaseInsensitiveString,所以违背了对称性。
为了解决这个问题,可以将和String互操作的代码删掉:
@Override
public boolean equals(Object o) {
return o instanceof CaseInsensitiveString && (((CaseInsensitiveString) o).s.equalsIgnoreCase(s));
}
3. 传递性:若x != null,y != null,z != null,当x.equals(y)=true,y.equals(z)=true时,x.equals(z)=true 当子类在父类的基础上添加属性时会无意中出现这个问题:
public class Point {
private final int x;
private final int y;
public Point(int x, int y){
this.x = x;
this.y = y;
}
@Override
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 final Color color;
public ColorPoint(int x, int y, Color color){
super(x, y);
this.color = color;
}
@Override
public boolean equals(Object o) {
if (!(o instanceof Point))
return false;
if (!(o instanceof ColorPoint))
return o.equals(this);
return super.equals(o) && ((ColorPoint) o).color == color;
}
}
上面的代码子类为父类扩展了一个颜色属性,子类的equals方法保证了对称性,但却牺牲了传递性:
ColorPoint p1 = new ColorPoint(1, 2, Color.RED);
Point p2 = new Point(1, 2);
ColorPoint p1 = new ColorPoint(1, 2, Color.BLUE);
上面的三个实例中,p1.equals(p2)和p2.equals(p3)都是true,但p1.equals(p3)返回的却是false。这里就引出了面向对象语言中关于等价关系的一个基本问题:无法在继承可实例化类的同时,即增加新的类属性,同时又保留equals约定。好在是有一个其他的方案,即遵循复合优先于继承的原则:
public class ColorPoint {
private final Point point;
private final Color color;
public ColorPoint(int x, int y, Color color){
point = new Point(x, y);
this.color = color;
}
public Point asPoint(){
return point;
}
@Override
public boolean equals(Object o) {
if (!(o instanceof ColorPoint))
return false;
ColorPoint cp = (ColorPoint) o;
return cp.point.equals(point) && cp.color.equals(color);
}
}
此时ColorPoint就不继承Point了,而是在类的定义里添加一个Point属性,并提供getter方法
此时由于没有了继承关系,所以
Point instanceof ColorPoint
和ColorPoint instanceof Point
结果都是false,所以在前面对称性和传递性的例子里都返回false,相应的也满足了这两条性质Java标准类库里甚至也有违反对称性的例子,
java.sql.Timstamp
对java.util.Date
扩展了一个属性,所以也违反了对称性,<font color="#ff3333">Timstamp和Date混用时会出现错误</font>,当然这一点也被作者狠狠吐槽,我们不要模仿 ~~
- 如果类是abstract的,我们可以在其子类李加新属性且不违反equals约定 只要不能创建超类的实例,前面的问题就没有。
4. 一致性:若x != null,y != null,只要对象没有被修改,多次执行x.equals(y)都是相同的结果 equals方法禁止依赖于不可靠的资源,否则就会违反一致性。
例如:java.net.URL的equals方法依赖于对URL中主机IP地址的比较。将一个主机名转变成IP地址可能会有不同的结果,这也是一个大错误不值得提倡!
5. 非空性:若x != null,x.equals(null)=false 为了避免抛出空指针异常,通常会有这样的写法:
@Override
public boolean equals(Object o) {
if (o == null)
return false;
......
}
但实际上更好地写法是:
@Override
public boolean equals(Object o) {
if (!(o instanceof Type))
return false;
Type t = (Type) o;
......
}
这样既可以类型检查,也可以保证传入null时返回false
综上所述,实现一个高质量的equals分以下四步即可:
- 用==检查入参是否是本对象的引用
- 用instanceof检查参数类型
- 将参数转换成正确的类型
- 对于类中的每个属性,检查入参的每个属性和自身是否匹配
- 不比较不属于对象逻辑状态的属性,比如保证同步的Lock(这种情况比较少)
有些对象的引用属性中包含null可能是合法的,为了避免出现空指针,建议使用
Objects.equals(Object, Object)
来检查是否相同
一个标准的equals示例:
public class PhoneNumber {
private final int areaCode, prefix, lineNum;
public PhoneNumber(int areaCode, int prefix, int lineNum){
this.areaCode = areaCode;
this.prefix = prefix;
this.lineNum = lineNum;
}
@Override
public boolean equals(Object o) {
if (o == this)
return true;
if (!(o instanceof PhoneNumber))
return false;
PhoneNumber pn = (PhoneNumber) o;
return pn.lineNum == lineNum && pn.prefix == prefix && pn.areaCode == areaCode;
}
}
代替手工编写和测试equals和hashCode方法的最佳途径是使用Google开源的AutoValue框架。它可以通过注解自动生成这两个方法。
注意:
- 覆盖equals时还要覆盖hashCode
- equals的逻辑不要太复杂
- equals的入参类型只能是Object
11 覆盖equals时总要覆盖hashCode
这是一个老生常谈的话题,没有覆盖hashCode违反的是相等的对象必须具有相等的hash code这一约定。
例如下面的代码:
Map<PhoneNumber, String> m = new HashMap<>();
m.put(new PhoneNumber(707, 867, 5309), "Jenny");
如果没有覆盖hashCode方法,m.get(new PhoneNumber(707, 867, 5309))会返回null,这里涉及到两个PhoneNumber对象,因为在put和get操作里都使用new关键字,因为没有覆盖hashCode方法,所以这两个实例有不同的hash code,所以返回结果是null
即使这两个实例正好被放到同一个桶中,get方法返回的也是null,因为HashMap会将每一项的hash code缓存起来,如果code不匹配则不会去检查对象的等同性
下面给出一种简单且有效的hashCode计算方法:
- 初始化int result = c,其中c是对象中第一个关键属性的散列码
- 对于剩下的每一个属性f,循环进行以下步骤: a. 为该属性计算散列码c ① 如果是基本数据类型,直接计算hashCode(f) ② 如果是引用,则针对这个属性递归调用hashCode ③ 如果是数组,对其中的元素单独求hash code b. 按照如下公式将上面算出来的c合并的result里
- 最终的result就是求出的hash code
result = 31 * result + c;
31有一个很好的特性:
31 * i == (i << 5) - i
,使用移位和减法可以代替乘法,在硬件层面上执行速度更快上面给出的hashCode实现方法可以满足日常需要,如果执意不想让散列函数有冲突,可以使用Guava的com.google.common.hash.Hashing
如果是不太注重性能的情况,可以在上面定义的PhoneNumber类里使用下面这种简单的实现方式:
@Override
public int hashCode(){
return Objects.hash(lineNum, prefix, areaCode);
}
如果计算hash code的开销较大的话,可以考虑使用缓存 + 延迟加载技术来提高性能:
private int hashCode;
@Override
public int hashCode(){
if(this.hashCode == 0){
// 计算散列码的逻辑
this.hashCode = XXX;
}
return this.hashCode;
}
最后要提醒注意一点:不要在计算hash code是尝试排除掉类的任一个属性,否则在某些场景下会以平方级的时间运行。
12 始终要覆盖toString
当对象传递给println、printf、字符串联接操作符+,assert或者被调试器打印出来时,toString方法会被自动调用。
所以提供好的toString实现可以使类用起来更舒服,也更容易调试。
例如有一个电话号码类PhoneNumber,没有覆盖和覆盖了toString方法分别会输出:
PhoneNumber@163b91
18373xxxxxx
我们肯定希望看到后面一种输出
对此,阿里巴巴开发规约里面也专门做了要求:
在实现toString时,还要决定是否要返回指定的格式,比如对于一般的类而言,使用json格式输出就很直观;但是对于一些特殊的类,比如电话号码类,它是有自己固定的格式的
@Override
public String toString(){
return String.format("%03d-%03d-%04d", areaCode, prefix, lineNum);
}
注意点:
- 无论是否指定格式,toString中返回的所有属性都应该有一个getter方法
- 如果很多子类都是同一个字符串表示法,在其抽象类里一定要写一个toString
比如大多数集合实现的toString都是继承自抽象集合类
13 谨慎地覆盖clone
这里主要讨论何时,以及如何实现一个较好的clone方法。
Java的Cloneable接口没有任何方法:如果一个类实现了Cloneable,Object的clone方法就返回该对象的拷贝,否则会抛CloneNotSupportedException异常。
这是接口一种不常用的用法,依据子类是否实现这个接口来决定返回什么。不值得提倡!
我们实现Cloneable接口的目的就是为了提供一个public的clone方法(clone方法来自于Object类, 实现了这个接口也意味着要提供一个合适的clone方法),此外,不可变的类不应该提供clone方法(鼓励尽可能复现现有实例)。
由于类里面定义的属性可能是变的或不变的,所以还要分情况讨论: 1. 如果每个属性都是基本数据类型或指向一个不可变对象的引用,这种情况不需要特殊处理。 例如之前的电话号码类PhoneNumber:
@Override
public PhoneNumber clone(){
try {
return (PhoneNumber) super.clone();
} catch (CloneNotSupportedException e){
throw new AssertionError();
}
}
2. 如果对象中的域引用了可变对象,用上面简单的clone会产生问题。 如果要对一个栈做克隆操作:
package com.wjw;
import java.util.Arrays;
import java.util.EmptyStackException;
/** * 2 * @Author: 小王同学 * 3 * @Date: 2021/11/23 20:50 * 4 */
public class Stack {
private Object[] elements;
private int size = 0;
private static final int DEFAULT_INITIAL_CAPACITY = 16;
public Stack(){
elements = new Object[DEFAULT_INITIAL_CAPACITY];
}
public void push(Object e){
ensureCapacity();
elements[size ++] = e;
}
public Object pop(){
if (size == 0)
throw new EmptyStackException();
Object result = elements[-- size];
elements[size] = null;
return result;
}
private void ensureCapacity() {
if (elements.length == size)
elements = Arrays.copyOf(elements, 2 * size + 1);
}
}
如果仅仅返回super.clone(),这样得到的新Stack实例的elements属性与原来的Stack指向的其实是同一个数组,这两个对象任意一个修改了elements都会影响另外一个。解决方案是使用深拷贝技术,递归地拷贝栈的内部信息:
@Override
public Stack clone(){
try {
Stack result = (Stack) super.clone();
result.elements = elements.clone();
return result;
} catch (CloneNotSupportedException e){
throw new AssertionError();
}
}
如果elements被final修饰,上面的代码会报错,clone方法禁止给final域赋新值。
递归调用clone了可能还不够,比如HashTable这种引用套引用再套引用的数据结构:
package com.wjw;
public class HashTable implements Cloneable{
private Entry[] buckets = new Entry[10];
private static class Entry{
final Object key;
Object value;
Entry next;
Entry(Object key, Object value, Entry next){
this.key = key;
this.value = value;
this.next = next;
}
}
}
如果向上面clone栈一样,仅仅递归地克隆buckets
@Override
public HashTable clone(){
try {
HashTable result = (HashTable) super.clone();
result.buckets = buckets.clone();
return result;
} catch (CloneNotSupportedException e){
throw new AssertionError();
}
}
这样一来,这个数组引用的链表与原始对象又是一样的了,继续出现上面的问题。 为了解决这个问题,必须单独拷贝buckets每个位置的链表:
package com.wjw;
public class HashTable implements Cloneable{
private Entry[] buckets = new Entry[10];
private static class Entry{
final Object key;
Object value;
Entry next;
Entry(Object key, Object value, Entry next){
this.key = key;
this.value = value;
this.next = next;
}
Entry deepCopy(){
return new Entry(key, value, next == null ? null : next.deepCopy());
}
}
@Override
public HashTable clone(){
try {
HashTable result = (HashTable) super.clone();
result.buckets = new Entry[buckets.length];
for (int i = 0; i < buckets.length; i++) {
if (buckets[i] != null)
result.buckets[i] = buckets[i].deepCopy();
}
return result;
} catch (CloneNotSupportedException e){
throw new AssertionError();
}
}
}
这样一来,HashTable的clone方法重新new了一个新的buckets数组,并且遍历原先的buckets,对其中的非空位置进行深度的拷贝。
需要注意的点: 1. public的clone方法应该省略throws声明 Object的clone方法声明时抛了一个异常 我们覆盖clone之后可以忽略这个声明(继承后,不能抛出比父类更多的异常)
2. 如果是线程安全的类要实现Cloneable接口,它的clone方法必须保证严格的同步。 Object的clone方法没有同步,所以必须实现synchronized clone()方法来调用super.clone()
3. 对象拷贝的更好方法是实现一个 拷贝构造器 或 拷贝工厂
public Yum(Yum yum){
this.属性 = yum.属性;
}
或
public static Yum newInstance(Yum yum){
...
}
这样做有很多优势: a. 不依赖于语言之外的对象创建机制; b. 不会与final域发生冲突; c. 不会抛不必要的异常; d. 不需要进行类型转换。
假设希望将一个HashSet对象s拷贝成TreeSet对象,clone方法无法完成,但用构造器就容易实现:
new TreeSet<>(s)
综上所述:除了数组最好用clone方法复制之外,其余的类不要实现Cloneable接口
14 考虑实现Comparable接口
这一条主要说明实现了Comparable接口后可以获得非常强大的功能。
比如下面一段代码就实现了args数组去重并打印的功能:
public class WordList {
Set<String> s = new TreeSet<>();
Collections.addAll(s, args);
System.out.println(s);
}
可以看到String类实现了Comparable接口后上面的代码量其实非常少。
如果一个类具有按照字母、数字、年代等排序的需求,就强烈建议实现这个接口
compareTo方法的约束与之前的equals方法的约束类似,这里需要借助数学里面的sgn函数:
- sgn(x.compareTo(y)) == - sgn(y.compareTo(x))
- 如果x.compareTo(y) > 0 && y.compareTo(z) > 0,则有x.compareTo(z) > 0
- 如果x.compareTo(y) == 0,则对于任意的z,sgn(x.compareTo(z)) == sgn(y.compareTo(z))
<li>最后一条是一个建议,最好满足x.compareTo(y) == 0的结果和x.equals(y)相同</li>
compareTo和equals的限制也类似,子类继承父类并扩展了新的属性时,同时保持compareTo约定,所以上面equals章节里的解决方案同时也适用于这里。
最后一条是一个强烈的建议,例如Java里面有一个BigDecimal类,它的compareTo与equals方法不一致。如果创建两个对象new BigDecimal("1.0")和new BigDecimal("1.00"),并添加到HashSet里,这个集合里面将会有两个元素,因为这两个对象通过equals方法比较结果是不同的。但将他们添加到TreeSet里,这个集合里将只包含一个元素,这又是因为这两个BigDecimal实例在通过compareTo方法进行比较时是相等的。
需要注意的是,不要在compareTo方法中使用操作符<,>
下面介绍Comparator接口配置比较器构造方法,这样做会使得构造工作变得流畅,还是以手机号码的比较为例:
private static final Comparator<PhoneNumber> COMPARATOR =
comparingInt((PhoneNumber pn) -> pn.areaCode)
.thenComparingInt(pn -> pn.prefix)
.thenComparingInt(pn -> pn.lineNum);
public int compareTo(PhoneNumber pn) {
return COMPARATOR.compare(this, pn);
}
comparingInt返回一个按areaCode对手机号进行排序的Comaprator<PhoneNumber>,如果两个手机号的areaCode相同,需要进行prefix和lineNum的比较。
如果要比较两个hashCode值的话,千万不要使用减法运算符:
static Comparator<Object> hashCodeOrder = new Comparator<Object>() {
@Override
public int compare(Object o1, Object o2) {
return o1.hashCode() - o2.hashCode();
}
};
上面的代码段很容易造成整数溢出,解决方案也很简单,就是使用现成的API:
static Comparator<Object> hashCodeOrder = new Comparator<Object>() {
@Override
public int compare(Object o1, Object o2) {
return Integer.compare(o1.hashCode(), o2.hashCode());
}
};
或
static Comparator<Object> hashCodeOrder = Comparator.comparingInt(o -> o.hashCode());