Effective Java学习笔记--2017年5月

Effective Java整理笔记

 

时间：2017/4/28~2017/5/6

文档结构：Effective Java目录结构（没有第一章引言部分）

所有的源代码Github储存仓库:

https://github.com/Wsky51/EffectiveJava

本文档URL图和思维导图开源链接：

https://www.processon.com/view/link/590f2488e4b0230b25bcc588

https://www.processon.com/view/link/590ed5e7e4b014dc3acaaa64

 

第1章 创建和销毁对象

第1条 考虑用静态工厂方法替代构造器

一是有名称，可以通过名称来选择到底用哪个构造器。

二是不必在每次调用他们的时候创建一个新的对象。

三是他们可以返回类型的任何子类型的对象。

四是在创建参数化类型实例的时候，它们使代码变得更加简洁

比如Map> m=new HashMap>随着类型参数越来越长，说明也就越繁琐。静态工厂：

 public static HashMap newInstance(){

return new HashMap

}

Map> m=HashMap.newInstance();

 

缺点：一是类如果不含有公有的或者受保护的构造器，就不能被子类化。

二是它们与其他的静态方法实际上没有任何区别

第2条 遇到多个构造器参数时要考虑用构建器

由于静态工厂和构造器有个共同的局限性：他们都不能很好地扩展到大量的可选参数。比如有多个参数以上的构造器、一些人一向习惯使用重叠构造器。

package com.wuyi.demo;

/**
 * Created by LENOVO on 2017/4/28.
 */
public class NutritionFacts {
    private final int servingSize;
    private final int servings;
    private final int calories;
    private final int fat;
    private final int sodium;
    private final int carbohydrate;
    public static class Builder{
        private final int servingSize;
        private final int servings;

        private int calories;
        private int fat;
        private int carbohydrate;
        private int sodium;

        public Builder(intservingSize,int servings){
            this.servingSize=servingSize;
            this.servings=servings;
        }
        public Builder calories(intval){
            this.calories=val;return this;
        }
        public Builder fat(intval){
            this.fat=val;return this;
        }
        public Builder carbohydrate(intval){
            this.carbohydrate=val;return this;
        }
        public Builder sodium(intval){
            this.sodium=val;return this;
        }
        public NutritionFacts build(){
            return new NutritionFacts(this);
        }
    }
    private NutritionFacts(Builder b){
        servingSize=b.servingSize;
        servings=b.servings;
        calories=b.calories;
        fat=b.fat;
        sodium=b.sodium;
        carbohydrate=b.carbohydrate;
    }
//    public NutritionFacts(int servingSize,int servings){
//        this(servingSize,servings,0);
//    }
//    public NutritionFacts(int servingSize,int servings,int calories){
//        this(servingSize,servings,calories,0);
//    }
//    public NutritionFacts(int servingSize,int servings,int calories,int fat){
//        this(servingSize,servings,calories,fat,0);
//    }
//    public NutritionFacts(int servingSize,int servings,int calories,int fat,int sodium){
//        this(servingSize,servings,calories,fat,sodium,0);
//    }
//    public NutritionFacts(int servingSize,int servings,
//                          int calories,int fat,int sodium,int carbohydrate){
//        this.servingSize=servingSize;
//        this.servings=servings;
//        this.calories=calories;
//        this.fat=fat;
//        this.sodium=sodium;
//        this.carbohydrate=carbohydrate;
//    }
    public static voidmain(String[] args) {
        NutritionFacts build = new Builder(230, 8).calories(100).sodium(35).carbohydrate(27).build();
        System.out.println(build);
    }
}

比如，注释的代码部分，对于这种重叠构造器，一句话，重叠构造器可行，但是当有许多参数的时候，客户端代码会很难编写，并且仍然难以阅读，要是两个参数不小心写反了，不容易发现。所以，不推荐这种方式。

第二种方式是JavaBean方式，用Setter和Getter方法来获取设置参数。这种模式弥补了重叠构造器的不足。说的直白点就是创建实例很容易，代码易读。但JavaBean自身严重的缺点是在构造过程中JavaBean可能处于不一致的状态。试图使用处于不一致状态的对象会导致失败。JavaBean模式阻止了把类做成了不可变的可能，这就需要人付出额外的努力确保它的线程安全。当对象构造完成，并不允许解冻使用，通过手工冻结对象，可以弥补这些不足，但这种方式十分笨拙，在实践中很少使用。

最后第三种方法，也就上上面代码中没有注销的部分，既能保证像重叠构造器模式那样的安全性，也能保证像JavaBeans模式（JavaBean模式由于多个set方法造成了其线程数据不安全，故不是一种好的方案。个人理解）那么好的可读性。

Java传统的抽象工厂实现是Class对象，用newInstance方法充当build方法的一部分。newInstance方法总是企图调用类的无参构造器，这个构造器甚至是根本不存在的。

Builder模式的不足是为了创建对象，必须先创建它的构建器。虽然创建构建器的开销在实践中可能不明显，但是在某些十分注重性能的情况下，可能就成问题了。Builder模式还比重叠构造器模式更加冗长。

（个人理解总结）总之，重叠构造器是由于它的可读性参数赋值易出错的问题而不建议采用，JavaBeans模式是由于线程安全问题而不采用，通常最好的做法就是一开始就是用Builder构建器。因为它综合了可读性，线程安全的优点。

第3条 用私有构造器或枚举类型强化Singleton属性

为在Java1.5版本之前，实现Singleton有两种方法。这两种方法都要把构造器保持为私有的，并导出为公有的静态成员，以便允许客户端能够访问该类唯一的实例。例如下面代码中注释掉的部分。

public class Elvis {
//    public static final Elvis INSTANCE=new Elvis();
//    private Elvis(){}
    private static finalElvis INSTACE=newElvis();
    private Elvis(){
        System.out.println("实例化了");
    }
    public static Elvis getInstace(){
        return INSTACE;
    }
}

一旦Elvis类被实例化，只会存在一个Elvis实例，不多也不少。客户端的任何行为都不会改变这一点。但是，通过反射机制享有特权的客户端可以借助AccessibleObject.setAccessible方法，通过反射机制调用私有构造器。如果需要抵御这种攻击，可以修改构造器，让它被要求创建第二个实例的时候抛出异常。

Singleton的第二种方法就是上面代码没注释的部分。为了让Singleton变成可序列化的，仅仅实现Serializable接口还不够。为了维护并保存Singleton，必须声明所有实例域都是瞬时的(transient)的，并提供一个readResolve方法。

另外，从JAVA1.5开始实现Singleton还有第三种方法。借助于enum枚举类型public enum Elvis{

INSTANCE;

public void leaveTheBuilding(){...}

}

它无偿提供了序列化机制，绝对防止多次实例化，即使是在面对复杂的序列化或者反射攻击的时候。这种单元素的枚举类型是实现Singleton的最佳方法。

第4条 通过私有构造器强化不可实例化的能力

企图通过将类做成抽象来强制该类不可被实例化，这是行不通的。该类可以被子类化，并且该子类也可以被实例化。由于只有当类不包含显示的构造器时u，编译器才会生成缺省的构造器，因此我们只要让这个类包含私有构造器，它就不能被实例化了。比如说下面的：

public class UtilityClass {
    private UtilityClass(){
        throw new AssertionError();
    }
}

由于显示的构造器是私有的，所以不可以在该类的外部访问它。

简单来说，用private关键字来让类不能实例化。

第5条 避免创建不必要的对象

一般来说，最好能重用对象而不是在每次需要的时候就创建一个相同功能的新对象。重用方式既快速又流行。如果对象是不可变的，它就始终可以被重用。

对于同时提供了静态工厂方法和构造器的不可变类，通常可以使用静态工厂方法而不是构造器，以避免创建不必要的对象。

除了重用那些不可变的对象之外，也可以重用那些已知不会被修改的可变对象。

主要做的就是将经常要用到的那一部分对象或者是值放到static。这样就可以保证当类实例的时候，无论多少次，static修饰的只实例化一次，可以避免重复创建不必要的对象，造成资源的浪费。（个人理解）

另外自动装箱

package com.wuyi.effectiveJava;

/**
 * Created by LENOVO on 2017/4/28.
 */
public class AutoBoxing {
    public static void main(String[] args) {
        Long sum=0L;
        for(longi=0;iMAX_VALUE;i++){
            sum+=i;
        }
        System.out.println(sum);
    }
}

程序答案正确，但是就是因为Long sum=0L,得出结果比实际要慢很多。只是因为打错了一个字符。字符变量被声明成Long而不是long，意味着程序要构造大约2的31次方的Long实例。将sum的声明改为long，程序运行时间极大缩短。

结论就是：要优先使用基本类型而不是装箱基本类型（否则每次都会构造一个实例对象，这对于程序来说时间开销成本很大，所以要避免，个人理解），要当心无意识的装箱。

但是不要错误地认为内容暗示着“创建对象的代价很昂贵，要尽量避免创建对象”，相反，由于小对象的构造器只做很少量的显式工作，所以小对象的创建和回收是非常廉价的，特别是在现代的JVM实现上更是如此。通过创建附加的对象，提升程序的清晰性、简洁性和功能性，这通常是一件好事。

反之，通过维护自己的对象池来避免创建对象并不是一件好做法，除非池中的对象时非常重量级的。真正正确使用对象池的典型对象示例就是数据库连接池。建立数据库连接池的代价特别昂贵，因此重用对象就非常有意义了。但，一般而言，维护自己的对象池一般会把代码弄得很乱，同时增加内存占用，并且还会损害性能。现代的JVM实现具有高度优化的垃圾回收器，其性能就很容易超过轻量级对象池的性能。

第6条 消除过期的对象引用

JVM可以帮我们自动地收集垃圾，并不是意味着我们不再考虑内存管理的事了。如packagecom.wuyi.effectiveJava;

import java.util.Arrays;
import java.util.EmptyStackException;

/**
 * Created by LENOVO on 2017/4/28.
 */
public class Stack {
    private Object[] elements;
    private int size=0;
    private static final int DEFAULT_INITIAL_CAPACITY=16;
    public Stack(){
        elements=newObject[DEFAULT_INITIAL_CAPACITY];
    }
    public void push(Object e){

    }
    public Object pop(){
        if(size==0){
            throw new EmptyStackException();
        }
        return elements[--size];
    }
    private void ensureCapacity(){
        if(elements.length==size){
            elements=Arrays.copyOf(elements,2*size+1);
        }
    }
}

这段程序没有明显的错误，无论如何测试都可以通过测试，但是这个程序隐藏着一个问题。这段程序有一个内存泄露，随着垃圾回收器活动的增加，或者由于内存占用的不断增加，程序性能的降低会逐渐表现出来。甚至失败，但是失败的情形相对比较少见。

那是哪里发生了内存的泄露呢？比如说栈先增长push进去各种元素，然后再收缩pop()，那么那些从栈中弹出的对象不会被收回，即使使用栈的程序不再引用这些对象，他们也不会收回，比如push(1),push(2),push(3),pop(),pop()，按理来说栈中现在只有1那一个元素，但是2,3这些对象并不会被JVM回收（个人理解），栈内部维护这些对象的过期引用。所谓过期引用是指永远也不会再被解除的引用。在上面的代码中，凡是在elements数组的活动部分之外的任何引用都是过期的，会对性能造成潜在的重大影响。活动部分是指elements中的下标小于size的那些元素。

问题的修复很简单：一旦对象引用已经过期，只需要清空这些引用就可以了。

也就是将对象赋值为null

Pop（）方法修改如下

public Object pop(){
    if(size==0){
        throw new EmptyStackException();
    }
    elements[size]=null;
    return elements[--size];
}

加一行清空代码即可。

还要注意的是，“对于每一个对象引用，一旦程序不再用到它，就把它清空。”其实这样做既没必要，也不是我们所期望的，因为这样做会把代码弄得很乱，清空对象引用应该是一种例外，而不是一种规范行为。消除过期引用的最好方法就是让包含该引用代码的变量结束其生命周期。一般而言，只要类是自己管理内存，我们就应该警惕内存泄露问题，手工清理一些过期引用。

第7条 避免使用终结方法

终结方法通常不可预测。使用终结方法会导致行为不稳定、降低性能，以及可移植性等问题。根据经验，应该避免使用终结方法。在Java中，一般用try-finally块来完成回收各类资源。

显示的终止方法，在每个实例不再有用的时候调用这个方法。显示的终止方法典型的例子是InputStream、OutputStream上面的close方法，显式的终止方法通常与try-catch结构结合。

终结方法有两种合法用途。第一种用途是当所有者忘记调用前面段落中建议的显示终止方法时，终结方法可以充当“安全网”。虽然并不能保证终结方法会被及时的调用。第二种合理用途与对象的本地对等体有关。本地对等体是一个本地对象。总之，除非是作为安全网，或者是为了终止非关键的本地资源，否则不要使用终结方法。

第2章 对于所有对象都通用的方法

第8条 覆盖equals时请遵守通用约定

equals()方法实现了等价关系，自反性，对称性，传递性，一致性。按照字面意思，即是数学中简单理论。

自反性：对于任何非null的对象而言。必须有x.equals(x)为true

对称性：对于任何非null的引用值，x.equals(y)值为true时，y.equals（x）也必须返回为true，比如一个CaseInsensitiveString

package com.wuyi.effectiveJava;

import java.util.ArrayList;
import java.util.List;

/**
 * Created by LENOVO on 2017/4/29.
 */
public class CaseInsensitiveString {
    private final Strings;
    public CaseInsensitiveString(String s){
        if(s==null){
            throw new NullPointerException();
        }
        this.s=s;
    }

    @Override
    public booleanequals(Object obj) {
        if(obj instanceofCaseInsensitiveString){
            return s.equalsIgnoreCase(((CaseInsensitiveString) obj).s);
        }
        if(obj instanceofString){
            return s.equalsIgnoreCase((String) obj);
        }
        return false;
    }

    public static void main(String[] args) {
        CaseInsensitiveString cis=new CaseInsensitiveString("Polish");
        String s="polish";
        List list=newArrayList ();
        list.add(cis);
        System.out.println(list.contains(s));//返回false
        List slist=new ArrayList ();
        slist.add(s);
        System.out.println(slist.contains(cis));//返回true

    }
}

问题在于，虽然CaseInsensitiveString类中的equals方法知道普通的字符串对象，但String类中的equals方法并不知道不区分大小写的字符串。因此.s.equals（cis）返回false，显然违反了对称性。一旦违反了equals规定，但其他对象面对我们的对象时，我们完全不知道这些对象的行为会怎么样。为了解决这个问题。只需把企图与string互操作的这段代码从equals去掉就可以了。

@Override
public boolean equals(Object obj) {
    return (obj instanceof CaseInsensitiveString)&&((((CaseInsensitiveString) obj).s.equalsIgnoreCase(s)));
}

个人总结：equals方法不要出现与当前类型不一致的情况的判断，否则另外的那个类的equals方法不会通过判断，造成违反对称性的情况。

传递性，1=2,2=3，那么一定有1=3。

public class ThreePoint{
    private final Point point;
    private final int z;
    public ThreePoint(intx,int y,intz){
        point=newPoint(x,y);
        this.z=z;
    }
    public Point asPoint(){
        return point;
    }

    @Override
    public booleanequals(Object obj) {
        if(!(obj instanceof ThreePoint)){
            return false;
        }
        ThreePoint threePoint = (ThreePoint) obj;

        return threePoint.point.equals(point)&&threePoint.z==z;
    }
}

根据16条的建议，复合优先于继承。这样做的目的保证不同的类之间的equals方法返回的是false。

个人总结：只要是在equals方法里面严格控制类的类型判断和逻辑语句的equals判断，便不会出现违反传递性原则的情况

一致性，如果两个对象相等，那么它们就必须始终保持相等，除非它们中有一个对象被修改了。当在写一个类的时候，应该仔细考虑它是否应该是不可变的。如果认为它应该是这样不可变的，就必须保证equals方法满足这样的限制条件：相等的对象永远相等，不相等的对象永远不相等。无论类是否是可变的，都不要使equals方法依赖于不可靠资源。如果违反，那想要满足这样的一致性的要求就十分困难。

非空性：比较对象不允许为空。且在书写equals代码的时候应该进行类型检查，不是同一个类型的直接返回false

总结，书写高质量的equals方法的要则如下：

1.使用==操作操作符检查“参数是否为这个对象的引用”。如果是，则返回true。这只不过是一种性能优化，如果比较操作会很昂贵的话，就值得这样做。

2.使用instanceof操作符检查“参数是否为正确类型”。若果不是，则返回false。一般来说正确的类型就是写equals方法的那个类。有些情况是指该类所实现的某个接口。如果类实现的接口改进了equals规定，允许在实现了该接口的类之间的比较，那么就使用接口。集合接口都具有这样的特性

3.把参数转化成正确的类型。因为之前进行过instanceof判断，所以确保会成功。

4.对于该类中每一个关键域，检查参数中的域是否与该域对象中对应的域相匹配。另外，在这之前一定要确保是可访问的。注意一点的是，对于基本类型用==号就可以了（除了float和double，他们应该用Float.compare和Double.compare（a1,a2）方法，相等返回0，大于返回1，小于返回-1）.对于对象引用域，调用equals方法。对于数组用Arrays.equals方法。域的比较顺序可能会影响到equals方法的性能。为了获得最佳的性能，应该最先比较最有可能不一致的域，或者是开销最低的域。

 

范式是什么？？

5.当编写完equals方法的时候，应该问自己是否满足对称性传递性一致性。如果否定就必须要更改equals方法代码。最后编写equals方法总要覆盖hashcode()方法，不要试着让equals方法过于智能。不要将equals声明中的Object对象替换为其他的类型。

    public boolean equals(Object obj) {
        if(this==obj){
            return true;
        }

        if(!(obj instanceof ThreePoint)){
            return false;
        }
        ThreePoint threePoint = (ThreePoint) obj;

        return threePoint.point.equals(point)&&threePoint.z==z;
    }

    public static void main(String[] args) {
        ThreePoint p1=null;
        ThreePoint p2=new ThreePoint(1,2,3);
//        System.out.println(p1.equals(p2));//抛出NullPointerException异常
        System.out.println(p2.equals(p1));//返回false
    }

第9条 覆盖equals时总要覆盖hashCode

一个很常见的错误根源在于没有覆盖hashCode方法。在每个覆盖了equals方法的类中，也必须覆盖了hashCode方法。如果不这样，就会违反Object.hashCode规定。从而导致该类无法结合所有基于散列的集合一起运作。

·在应用程序执行的过程中，只要对象的equals方法的比较操作所用到的信息没有被更改，那么对于这同一个对象调用多次，hashCode方法必须始终如一地返回同一个整数。

·如果两个对象根据equals(Object)方法比较的是相等的，那么调用这两个对象中任意一个对象的hashCode方法都必须产生同样的整数结果。如果不同，那么调用hashCode方法有可能在逻辑上也是相等的，但是我们应该尽量让他们产生截然不同的hashCode以提高hashTable的性能。

所以没有覆盖hashCode违反了Object规范。

一个好的散列函数通常倾向于“为不相等的对象产生不相等的散列码”。理想情况下，散列函数应该把集合中不相等的实例均匀地分布到所有可能的散列值上。但要想完全达到这种理想的情形是非常困难的。但相对接近这种理想情况并不困难。以下原则步骤：

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

2.对于对象中每个关键域f（指equals方法中涉及的每个域），完成下面步骤。

a.为该域计算int类型的散列码c：

1.如果是boolean类型，true设值为1false设置0

2.如果是byte，char，short，计算（int）f

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

4.如果是float，计算Float.floatToIntBits(f)

5.如果是double类型，则计算Double.doubleToLongBits(f)然后按照第三条计算。

6.如果是一个对象引用，则调用hashCode方法。

7.如果是个数组，则把每一个元素当做单独的域处理。如果数组每一个元素都很重要，则利用Arrays.hashCode()方法。

b.按照公式，把步骤2.a计算得到的散列码c合并到result中：

result=31*result+c;(之所以选择31，是因为他是一个奇素数。如果是偶数，并且乘法溢出的话，信息就会丢失，因为与2乘等于移位运算。使用素数的好处并不很明显，但是习惯上都使用素数计算散列结果。31有个很好的特性，即用移位和减法来代替乘法，可以得到更高的性能：31*i==(i<<5)-i)

3.返回result

4.写完测试。

如下面的代码，equals方法是按照第8条书写得：

package com.wuyi.effectiveJava;

/**
 * Created by LENOVO on 2017/4/29.
 */
public class PhoneNumber {
    private final short areaCode;
    private final short prefix;
    private final short lineNumber;

    public PhoneNumber(intareaCode,int prefix,intlineNumber){
        this.areaCode= (short) areaCode;
        this.prefix= (short) prefix;
        this.lineNumber= (short) lineNumber;
    }

    @Override
    public booleanequals(Object obj) {
        if(obj==this){
            return true;
        }
        if(!(obj instanceof PhoneNumber)){
            return false;
        }
        PhoneNumber p = (PhoneNumber) obj;
        return p.areaCode==areaCode&&p.prefix==prefix&&p.lineNumber==lineNumber;
    }

    @Override
    public inthashCode() {
        int result=17;
        result=31*result+areaCode;
        result=31*result+prefix;
        result=31*result+lineNumber;
        return result;
    }
}

如果一个类是不可变的，并且计算散列码的开销也比较大，就应该考虑把散列码缓存在对象内部，而不是每次请求的时候都重新计算散列码。

不要试图从一散列码计算中排除一个对象的关键部分阿里提高性能。

第10条 始终要覆盖toString

如打印上一个PhoneNumber的实例的时候，输出的是com.wuyi.effective Java.PhoneNumber@9b448依次是类的名称，@号和无符号的十六进制表示法。查看源码：returngetClass().getName() + "@"+ Integer.toHex String(hashCode());建议所有的子类都覆盖这个方法。它可以使类使用起

来更加舒适

第11条 谨慎地克隆clone

Cloneable接口的目的是作为对象的一个mixin接口，表明一个对象允许这样的克隆。但它并没有达到这个目的。其主要缺陷在于它缺少一个clone方法，Object的clone方法是受保护的。如果实现Cloneable接口是要对某个类起到作用，类和他的超类都必须遵循一个相当复杂，不可实施的，并且基本上没有文档说明的协议。由此得到一种语言之外的机制：无需调用构造器就可以创建对象。

拷贝对象往往会导致创建它的类的一个新实例，但它同时也会要求拷贝内部的数据结构。这个过程中没有调用构造器。但是，不调用构造器的规定太强硬了。行为良好的clone方法可以调用构造器来创建对象，构造之后再复制内部数据。如果这个类是final的，clone甚至可能会返回一个由构造器创建的对象。以下的部分代码

public class PhoneNumberimplements Cloneable

@Override
protected Object clone()throws CloneNotSupportedException {
    return super.clone();
}

 

public static void main(String[] args)throws CloneNotSupportedException {
    PhoneNumber p=new PhoneNumber(123,355,321);
    PhoneNumber clone = (PhoneNumber)p.clone();
    System.out.println(p.getClass()==clone.getClass());//true
    System.out.println(clone.prefix);//355
}

如果希望在一个类中实现Cloneable，并且它的超类都提供行为良好的clone方法。我们从clone()中得到的对象可能会接近于最终要返回的对象，也可能相差甚远，这要取决于这个类的本质。从每个超类的角度来看，这个对象将是原始对象功能完整的克隆。在这个类中声明的域将等同于被克隆对象中相应的域。另外，1.5版本引入了协变返回类型作为泛型，就是说覆盖@Override方法的返回类型可以是被覆盖方法的返回类型的子类。如下

@Override
protected PhoneNumber clone()throws CloneNotSupportedException {
    return (PhoneNumber)super.clone();
}

这体现了一点：永远不要让客户去做任何类库能够替客户完成的事情。

如果对象中包含域引用了可变的对象就像之前的Stack这个类。由于private Object[] elements是可变的，使用上述这种简单的clone实现可能会导致灾难性的后果。实际上clone方法就是另外一个构造器，必须确保它不会伤害到原始对象，并确保正确地创建被克隆对象中的约束条件。所以为了使Stack类中的clone方法正常工作，它必须要拷贝栈的内部信息。最容易的做法就是在elements数组中递归地调用clone，就像这样：

@Override
protected Stack clone()throws CloneNotSupportedException {
    Stack result = (Stack) super.clone();
    result.elements=elements.clone();
    return result;
}

推论：clone是潜复制，不存在对象引用（个人理解，可能有偏差错误）

所以如果一个对象是final的时候，就不能复制了

简而言之，所有实现Cloneable接口的类都应该用一个公有的方法覆盖clone。此公有方法首先调用super.clone，然后修正任何需要修正的域。一般情况下，这意味着要拷贝任何包含内部“深层结构”的可变对象，并用指向新对象的引用代替原来指向这些对象的引用。

另外一个实现对象拷贝的好办法就是提供一个拷贝构造器或拷贝工厂。拷贝构造器只是一个构造器，它唯一的参数类型是包含该构造器的类。如：public Yun(Yum yum);拷贝工厂是类似于拷贝构造器的静态工厂：public static Yum newInstance（Yum yum）;Cloneable具有上述那么多问题，所以可以肯定地说，其他的接口都不应该扩展这个接口，为了继承而设计的类也不应该实现这个接口。有些专家级别的程序员干脆从来不去覆盖clone方法，也不调用它，除非拷贝数组。

第12条 考虑实现Comparable接口

重写其中的int compareTo(T  t)方法。CompareTo方法的通用约定与equals方法相似。将这个对象与指定对象比较，当该对象小于、等于、或大于指定对象的时候，分别返回一个负整数，0或者正整数。如果由于指定对象的类型而无法与该对象比较，则抛出ClassCastException异常。同样由compareTo方法施加的同等性测试，也一定遵循相同于equals约定所施加的限制条件：自反性，对称性，传递性。

另外，注意一点，书上第55页中，谈到BigDecimal类，它的compareTo方法和equals方法不一致。如果我们创建了HashSet，并添加new BigDecimal(“1.0”)和new BigDecimal(“1.00”)那么最终会有两个实例，因为BigDecimal类的compareTo方法和equals不一致。然而，如果使用TreeSet而不是HashSet执行同样的过程，集合中将只保存一个元素，因为这两个BigDecimal实例在通过compareTo方法进行比较的时候是相等的。

还要注意一点：@Override
public int compareTo(PhoneNumber o) {
    if(areaCode>o.areaCode){
        return 1;
    }
    if(areaCodeareaCode){
        return -1;
    }
    return 0;
}

这个方法可行，但是还可以改进。因为compareTo并没有指定返回值的大小，而是指定了返回值的符号。可以利用这一点来简化代码，或许能提高速度。

@Override
public int compareTo(PhoneNumber o) {
    int res=areaCode-o.areaCode;
    if(res!=0){
        return res;
    }
    return 0;
    
}

这项技巧在这里可以工作的很好，但是用起来要非常小心。除非确信相关的域不会为负值，或者更一般的情况：最大和最小的可能域值差小于或等于INTEGER.MAX_VALUE（2^31-1）,否则就不要用这种方法。这不是一个纯粹的理论问题：它已经在实际的系统中导致了失败。这些失败可能非常难以调试，因为这样的compareTo方法对于大多数的输入值都能正常工作。

第3章 类和接口

第13条 使类和成员的可访问性最小化

区分设计良好的模块与设计不好的模块，最重要的因素在于，这个模块对于外部的其他模块而言，是否隐藏其内部数据和其他实现细节。设计良好的模块会隐藏所有的实现细节，把它的API与它的实现清晰地隔离开来。然后，模块之间只通过他们的API通信，一个模块不需要知道其他模块的内部工作情况。这个概念被称为信息隐藏或封装，是软件设计的基本原则

如果一个包级私有的顶层类只是在某一个类的内部被用到，就应该考虑使它成为唯一使用它的那个类的私有嵌套类。这样可以将它的可访问性范围从包中的所有类缩小到了使用它的那个类。但是降低不必要公有类的可访问性，比降低包级私有的顶层类的更重要的多。

实例域（什么是实例域？？？）绝对不能是公有的。同样的建议也适用于静态域，只有一种例外情况。类具有公有的静态final数组域，或者返回这种域的访问方法，这几乎总是错误的。如果类具有这样的域或者访问方法，客户端将能够修改数组中的内容。这是安全漏洞的一个常见根源。

总而言之，应该尽可能地降低可访问性。除了公有静态final域的特殊情形之外，公有类都不应该包含公有域。并且要确保公有静态final域所引用的对象都是不可变的。

第14条 在公有类中使用访问方法而非公有域

类的数据域永。远不要被暴露。应该提供封装功能。

Class Point{

public double x;//数据域被暴露

public double y;//同上，用getter和setter方法

}

比如Javabean这种方法。如果类是包级私有的，或者是私有的嵌套类，直接暴露它的数据域并没有本质的错误----假设这些数据域确实描述了该类所提供的抽象。这种方法比访问方法的做法更不会产生视觉混乱。让公有类直接暴露域虽然从来都不是种好方法，但是如果域是不可变的，这种做法的危害就比较小一些。

总之，公有类永远都不应该暴露可变的域。虽然还是会有问题，但是让公有类暴露不可变的域其危害比较小。但有时候会需要用包级私有的或者私有的嵌套类来暴露域，无论这个类是可变还是不可变的。

第15条 使可变性最小化

不可变类只是其实例不能被修改的类。每个实例中包含的所有信息都必须在创建该实例的时候就提供，并且在对象的整个生命周期内固定不变。存在不可变的类有许多理由：不可变的类比可变类更加易于设计、实现和使用。他们不容易出错，且更加安全。让类成为不可变，要遵守下面5条原则：

1.不要提供任何会修改对象状态的方法。

2.保证类不会被扩展，一般做法是加final

3.使所有的域都是final的

4.使所有的域都变成私有的

5.确保对任何可变组件的互斥访问

不可变对象本质上是线程安全的，它们不要求同步。当多个线程并发访问这样的对象时，它们不会遭到破坏。这无疑是获得线程安全最容易的办法。实际上，没有任何线程会注意到其他线程对于不可变对象的影响。所以，不可变对象可以被自由的共享，不可变类应该充分利用这种优势，鼓励客户端尽可能地重用现有的实例。要做到这一点，一个很简单的方法就是对于频繁使用的值，加final。

不可变对象可以被自由地共享导致的结果是，永远也不需要进行保护性拷贝了。因为这些拷贝始终等于原始对象，所以不应该为不可变的类提供clone方法或者拷贝构造器。不可变类真正唯一的缺点是，对于每个不同的值都需要一个单独的对象。创建这种对象的代价可能很高。特别是对于大型对象的情形。

为了确保不可变性，类绝对不允许自身被子类化。除了“使类成为final”这种方法之外，还有另外一种更加灵活的办法可以做到这一点。让不可变的类变成final的另外一种方法就是，让类的所有构造器都变成私有的或者包级私有的，并添加公有的静态工厂来代替公有的构造器。如下所示：

public class Complex {
    private final double re;
    private final double im;
    private Complex(doublere,double im){
        this.re=re;
        this.im=im;
    }
    public static Complex valueOf(doublere,double im){
        return new Complex(re,in);
    }
    
}

它经常是最好的替代方法。它最灵活，因为它允许使用多个包级私有的实现类。这样静态工厂具有很多其他的优势，在第一条中已经写到过。

总之，坚决不要为每一个get方法编写一个相应的set方法。除非有很好的你有要让类成为可变的类，否则就应该是不可变的。不可变的类有许多优点，唯一的缺点是在特定的情况下存在潜在的性能问题。只有当我们确认有必要实现令人满意的性能时，才应该为不可变类提供公有的可变配套类。如果类不能被做成是不可变的，仍然应该尽可能地限制他的可变性。因此除非是有令人信服的理由要是域变成是非final的，否则要使每个域都是final的

第16条 复合优先于继承

对于同一个包的继承是非常安全的，因为是在同一个程序员的控制之下。但是对于普通的具体类进行跨越包边界的继承，则是非常危险的。

与封装不同，继承打破了封装性。举例说明：

public class InstrumentedHashSet<E>extends HashSet<E> {
    private int addCount;
    public InstrumentedHashSet(){}
    public InstrumentedHashSet(intinitCap,float loadFactor){
        super(initCap,loadFactor);
    }

    @Override
    public booleanadd(E e) {
        addCount++;
        return super.add(e);
    }

    @Override
    public booleanaddAll(CollectionextendsE> c) {
        addCount+=c.size();
        return super.addAll(c);
    }
    public int getAddCount(){
        return addCount;
    }

    public static void main(String[] args) {
        InstrumentedHashSet s=newInstrumentedHashSet ();
        s.addAll(Arrays.asList("t1","t2","t3"));
        System.out.println(s.getAddCount());//返回6
    }
}

类看起来合情合理但是不能工作。addCount应该是3，但结果是6。出错的原因就在于在HashSet的内部，addAll方法是基于它的add方法来实现的，虽然只要去掉addALL方法就可以修正这个子类。虽然得到的类可以正产工作，但是不能保证随着发行版主JDK的不同而变化，因此这样的类是很脆弱的。导致子类脆弱的一个相关的原因就是他们的超类在后续的发行版本中可以获得新的方法。

上面问题的来源都来自于覆盖动作，如果扩展一个类的时候，仅仅是增加新的方法，而不覆盖现有的方法，这也并非完全没有风险，因为如果后期JDK中对超类添加一个方法，但这个方法的名字和我们扩展类中一个方法同名问题就又出现了。

有一种方法可以避免所有问题，就是在新类中增加一个私有域，它引用现有类的一个实例。这种设计被称作复合。

只有当子类真正是超类的子类型时，才适合继承，另外当试图扩展类的时候，还会把超类的API缺陷扩展到子类当中。

第17条 要么为继承而设计，并提供文档说明，要么就禁止继承

首先，该类的文档必须精确地描述覆盖每个方法所带来的影响。换句话说，就是该类必须有文档说明它可覆盖的方法的自用性，详细说明那些方法那些构造器是可覆盖的方法，是以什么顺序调用的等等。

好的API文档应该描述一个给定的方法做了什么工作，而不是描述它是如何做到的。对于为了继承而设计的类，唯一的测试方法就是编写子类。另外，构造器决不能调用可被覆盖的方法，无论是直接调用还是间接调用。如下面这段程序：public class Super {
    public Super(){
        overrideMe();
    }
    public void overrideMe(){
        System.out.println("Super()");
    }
}

public class Sub extends Super{
    private final Date date;
    Sub(){
        date=newDate();
    }

    @Override
    public voidoverrideMe() {
        System.out.println(date);
    }

    public static void main(String[] args) {
        Sub sub=new Sub();
        sub.overrideMe();
    }
}

返回结果null

        Sun Apr 30 17:47:52 CST 2017

原因就是在Super调用构造器的时候，OverrideMe方法内打印日期这个时候日期没有被初始化，所以打印为null,如果在overrideMe里面打印日期里的某一种方法，则会抛出NullPointerException异常。如果决定在一个为了继承而设计的类中实现cloneable和Serializable接口，就应该意识到，因为clone和readObject方法在行为上非常类似于构造器，应

很明显，为了继承而设计类，对这个类会有一些实质性的限制。在某些情况下，这样的决定是正确的，比如抽象类，包括接口的骨架实现。但是另外一些情况，这样的决定是明显错误的，比如不可变的类。

对于这个问题最佳的解决方法是，对于那些并非为了安全地进行子类化而设计和编写文档的类，要禁止子类化。方有两种方法可以禁止子类化，一种是把类声明为final的，另外一种就是把所有的构造器都变成私有的，或者包级私有的，并增加一些公有的静态工厂来代替构造器

第18条 接口优于抽象类

通过导出的每个重要的接口都提供一个抽象的骨架实现类，把接口和抽象类的优点结合起来。接口的作用仍是定义类型，但是骨架实现类接管了所有与接口实现相关的工作。按照惯例，骨架实现被称为AbstractInterface，比如AbstractSet

设计接口必须非常谨慎，接口一旦被公开发行，并且已被广泛实现，再想改变这个接口几乎是不可能的。我们必须在初次设计的时候就保证接口是正确的。

简而言之，接口通常是定义允许多个实现的类型的最佳途径。如果导出了一个重要的接口，就应该坚决考虑同时提供骨架实现类

第19条 接口只用于定义类型

有一种接口为常量接口，interface里面的常量都默认为static和final的，不可改变。但常量接口模式是对接口的不良使用。实现常量接口，会导致把这样的实现细节西楼到该类的导出API中去。另外，非final类实现了这个接口的话，它的所有子类的命名空间也会被接口中的常量所污染。总之，接口应该只被用来定义类型，他们不应该被用来导出常量。

第20条 类层次优于标签类

eg下面的标签类：

public class Figure {
    enum Shape{RECTANGLE,CIRCLE};
    final Shape shape;
    double length;
    double width;
    double radius;
    Figure(double radius){
        shape=Shape.CIRCLE;
        this.radius=radius;
    }
    Figure(double length,doublewidth){
        shape=Shape.RECTANGLE;
        this.length=length;
        this.width=width;
    }
    double area(){
        switch (shape){
            case CIRCLE:
                return Math.PI*(radius*radius);
            case RECTANGLE:
                return length*width;
            default:throw newAssertionError();
        }
    }

这种标签类有许多缺点，因为实例承担了属于其他风格的不相关的域，一个花，标签类过于冗长、容易出错，并且效率低下。标签类正是类层次的一种简单的仿效。

abstract class Figure{
    abstract double area();
}
class Circle extendsFigure{
    final double radius;

    Circle(double radius){this.radius=radius;}
    double area(){returnMath.PI*(radius*radius);}
}
class Rectangle extends Figure{
    final double length;
    final double width;
    Rectangle(double length,doublewidth){
        this.length=length;
        this.width=width;
    }
    @Override
    doublearea() {
        return length*width;
    }
}

类层次保证了确保对每个抽象方法都有一个实现。这样杜绝了swithch case而导致运行时失败的可能性。总之，标签类很少有适用的时候。当我们想要编写一个包含显示标签域的类时，应该考虑一下，这个标签类是否可以取消，这个类是否可以用类层次来代替。

第21条 用函数对象表示策略

Java没有提供函数指针，但是可以用对象引用，调用对象上的方法通常是执行该对象上的某项操作。例如我们进行实现comparator的compare(T a,T b )方法。

简而言之，函数指针的主要用途是实现策略模式。为了在java中实现这一模式，要声明一个接口来表示该策略，并且为每个具体策略声明一个实现了该接口的类。当一个具体的策略只被使用一次时，通常使用匿名类来声明和实例化这个具体策略类。当一个具体策略是设计用来重复使用的时候，它的类通常就要被实现为私有的静态成员类，并通过公有的静态final域导出，其类型为该策略接口。

第22条 优先考虑静态成员类

嵌套类有四种：静态成员类，非静态成员类，匿名类，和局部类。除了第一种，其他都称为内部类。静态成员类和非静态成员类之间的唯一的区别是static修饰符。尽管语法很相似，但这两种嵌套类有很大的不同。非静态成员类的每一个实例都隐含着与外围类的一个外围实例相关联，在没有外围实例的情况下，想要创建非静态成员类的实例是不可能的。

另外，匿名类出现在表达式中，必须简短否则会影响到程序的可读性。局部类也一样，如果太长，就把他做成成员类。

第4章 泛型

第23条 请不要在新代码中使用原生态类型

每个泛型都定义一个原生态类型，即不带任何实际类型参数的泛型名称(泛型的擦除机制)，例如，List相对应的原生态类类型是List。

使用泛型最主要的目的是出于安全性和表述性方面的考虑。泛型有子类化的规则，List是原生态类型;List的一个子类型，而不是参数化类型List