Effective Java 阅读笔记

第二章 创建和销毁对象

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

静态工厂方法优势：

• 静态工厂方法有名称

静态工厂方法可以详细的指定名称，而使用构造器时如果没有文档会难以区分不同构造器之间的区别。

• 不必每次调用的时候创建一个新对象

静态工厂方法可以缓存预先构建好的实例，或者直接返回之前的实例（如果需要的话）。

• 可以返回任何类型的任何子类型对象

基于接口时，这会非常有用。既可以隐藏具体实现，又能返回需要的类型。

• 返回对象可以随着每次调用发生变化

EnumSet类没有构造方法，只有静态方法，调用返回的时候会根据不同的枚举大小返回不同的内部类，而且以后也可以很好的新增或删除内部实现，这对调用者是不需要关心的。

• 返回对象可以暂时不存在

这个在服务提供框架（Service Provider Framework）中很有用，返回对象由服务提供者提供，框架不需要考虑是什么类型。

JDK在1.6的时候也提供了ServiceLoader类，这是一个通用的服务提供处理。

静态工厂方法的缺点：

• 如果需要的类没有 public 构造器或者 protected 构造器，就不能子类话该类。
• 工厂类很难被发现

如果没有在API中明确注明，那么想实例化一个提供了工厂方法的类是比较难的。（深有同感）

静态工厂方法管用名称：

• from：类型转换方法，接受单个参数并返回对应类型。
• of：聚合方法，接受多个参数，并合并成对应类型。
• valueOf：比from和of更繁琐的替代方法。
• instance或getInstance：获取实例；
• create或newInstance：获取实例，并且保证每次都是一个新实例。
• get{Type}：获取实例，主要用于工厂类和实例类型不一样时使用，比如Files.getFileStore(path)
• new{Type}：和get{Type}类似，用于返回新实例，例如：Files.newBufferedReader(path)
• {type}：get{Type}和new{Type}的简化版，例如：Collections.list(...)

第 2 条 多个构造参数时有限考虑 Builder 建造器

工厂模式和构造器不能很好的扩展大量可选参数。

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

单例可以使用饿汉、懒汉、双重检查锁、枚举来实现。

第 4 条 私有化构造器使类不可实例化

特指不要使用抽象类来禁止实例化。

第 5 条 优先考虑依赖注入来引入资源

能 DI 尽量 DI（依赖注入：Dependency Injection）。

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

反例：String s = new String("blabla")

注意进行正则校验时，优先考虑创建公共的Pattern对象，避免使用静态方法Pattern.matches()，该静态方法每次都会创建一个Pattern，并且Pattern的创建是有一定负担的。

循环时优先使用基本类型，避免不必要的装箱。

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

给对象引用复制为 null 就可以消除引用，但是这里的消除引用并不是说局部变量用完之后赋值 null：

public void someMethod() {
    List<String> strList = new ArrayList<>();
    useStrMethod(strList);
    // 并不是指这种
    strList = null;
}

局部变量在方法结束时会自动解除引用，这里的过期引用特指缓存，否则很容易引发内存泄露。
比如在实现一个List时，内部使用数组缓存了对象，那个在调用removeLast方法时，不能仅仅把最大下标移动一下，而是要数组中引用的对象赋为null，这样删除的对象才能被GC。

第 8 条 避免使用终结方法（finalize）和清除方法（cleaner）

Object 上的 finalize 方法已经被标记为 removal，原本是被回收时会出发的方法，但是并不够保险，该方法现在已经被标记过时，不要使用。

cleaner 是 Java 9 加入的方法，加入的目的是代替finalize方法，这是一个使用例子：

Cleaner cleaner = Cleaner.create();
Cleaner.Cleanable cleanable = cleaner.register(anyObj, () -> {
    System.out.println("do clean");
});
cleanable.clean();

不同的垃圾回收算法会在不同时间进行垃圾回收，因此程序不应该依赖这种方法，并且终结方法有严重性能损失。
正常应该使用 AutoCloseable 接口，然后使用 try-with-resource 的方式进行释放。

第 9 条 try-with-resource 优先于 try-finally

当有多个 io 流是，try-finally 的关闭会非常繁琐，并且可读性不好。如果一个类需要被关闭，那么就可以实现 AutoCloseable 接口，然后使用try-with-resource。