effective-java-3rd学习笔记3

第八条: 避免使用 Finalizer(finally) 和 Cleaner（try-with-resources)机制

1. Java 9 开始，Finalizer 机制已被弃用，但仍被 Java 类库所使用。 Java 9 中 Cleaner 机制代替了 Finalizer 机制。Cleaner 机制不如 Finalizer 机制那样危险，但仍然是不可预测，运行缓慢并且通常是不必要的。
2. Finalizer 和 Cleaner 机制的一个缺点是不能保证他们能够及时执行。在一个对象变得无法访问时，到Finalizer 和 Cleaner 机制开始运行时，这期间的时间是任意长的。 这意味着你永远不应该 Finalizer 和 Cleaner 机制做任何时间敏感（time-critical）的事情。
3. 不要相信 System.gc 和 System.runFinalization 方法。 他们可能会增加 Finalizer 和 Cleaner 机制被执行的几率，但不能保证一定会执行。 曾经声称做出这种保证的两个方法System.runFinalizersOnExit 和它的孪生兄弟 Runtime.runFinalizersOnExit ，包含致命的缺陷，并已被弃用了。
4. Finalizer 机制的另一个问题是在执行 Finalizer 机制过程中，未捕获的异常会被忽略，并且该对象的 Finalizer 机制也会终止 。未捕获的异常会使其他对象陷入一种损坏的状态（corrupt state）。如果另一个线程试图使用这样一个损坏的对象，可能会导致任意不确定的行为。通常情况下，未捕获的异常将终止线程并打印堆栈跟踪（
   stacktrace），但如果发生在 Finalizer 机制中，则不会发出警告。Cleaner 机制没有这个问题，因为使用 Cleaner 机制的类库可以控制其线程。
5. 使用Cleaner时Finalizer的效率的差不多50倍。
6. finalizer 机制有一个严重的安全问题：如果一个异常是从构造方法或它的序列化中抛出的—— readObject 和 readResolve 方法 恶意子类的 finalizer 机制可以运行在本应该的部分构造对象上。finalizer 机制可以在静态字属性记录对对象的引用，防止其被垃圾收集。

解决方案

类实现 AutoCloseable接口，并用try-with-resources确保终止。
实例代码如下：

import java.lang.ref.Cleaner;

// An autocloseable class using a cleaner as a safety net (Page 32)
public class Room implements AutoCloseable {
    private static final Cleaner cleaner = Cleaner.create();

    // Resource that requires cleaning. Must not refer to Room!
    private static class State implements Runnable {
        int numJunkPiles; // Number of junk piles in this room

        State(int numJunkPiles) {
            this.numJunkPiles = numJunkPiles;
        }

        // Invoked by close method or cleaner
        @Override public void run() {
            System.out.println("Cleaning room");
            System.out.println(Thread.currentThread().getName());
            numJunkPiles = 0;
        }
    }

    // The state of this room, shared with our cleanable
    private final State state;

    // Our cleanable. Cleans the room when it’s eligible for gc
    private final Cleaner.Cleanable cleanable;

    public Room(int numJunkPiles) {
        state = new State(numJunkPiles);
        cleanable = cleaner.register(this, state);
    }

    @Override public void close() {
        cleanable.clean();
    }
}

调试代码如下：

// Well-behaved client of resource with cleaner safety-net (Page 33)
public class Adult {
    public static void main(String[] args) {
        try (Room myRoom = new Room(7)) {
            System.out.println("Goodbye");
            System.out.println(Thread.currentThread().getName());
        }
    }
}

运行结果如下：

Goodbye
main
Cleaning room
main

---

第九条： 使用 try-with-resources 语句替代 try-finally 语句

1. 精简，不易出错，可读性好。
2. try-with-resources不会覆盖异常。例如在读取文件时，readLine方法发生异常，调用 close 方法可能会异常。try-finally第二个异常会覆盖第一个异常。try-with-resources 如果调用 readLine 和（不可见） close 方法都抛出异常，则后一个异常将被抑制，而不是前者。

总结

结论很明确：在处理必须关闭的资源时，使用 try-with-resources 语句替代 try-finally 语句。 生成的代码更简洁，更清晰，并且生成的异常更有用。 try-with-resources 语句在编写必须关闭资源的代码时会更容易，也不会出错，而使用 try-finally 语句实际上是不可能的。

第十条：重写 equals 方法时遵守通用约定

1. 什么时候需要重写 equals 方法呢？
   如果一个类包含一个逻辑相等的概念，此概念有别于对象标识，而且父类还没有重写过 equals 方法。
2. 当你重写 equals 方法时，必须遵守它的通用约定。

• 自反性： 对于任何非空引用 x， x.equals(x) 必须返回 true。
• 对称性： 对于任何非空引用 x 和 y，如果且仅当 y.equals(x) 返回 true 时 x.equals(y) 必须返回 true。
• 传递性： 对于任何非空引用 x、y、z，如果 x.equals(y) 返回 true， y.equals(z) 返回 true，则
  x.equals(z) 必须返回 true。
• 一致性： 对于任何非空引用 x 和 y，如果在 equals 比较中使用的信息没有修改，则 x.equals(y) 的多次调用
  必须始终返回 true 或始终返回 false。
• 对于任何非空引用 x， x.equals(null) 必须返回 false。
  违反以上约定，会导致程序各种错误。

---

第十一点：重写 equals 方法时同时也要重写 hashcode 方法

1. 在每个类中，在重写 equals 方法的时侯，一定要重写 hashcode 方法。 如果不这样做，你的类违反了 hashCode的通用约定，这会阻止它在 HashMap 和 HashSet 这样的集合中正常工作。根据 Object 规范，以下时具体约定。
2. 当无法重写 hashCode 时，所违反第二个关键条款是：相等的对象必须具有相等的哈希码。
3. 重写hashcode方法

• 如果这个属性是基本类型的，使用 Type.hashCode(f) 方法计算，其中 Type 类是对应属性 f 基本类型的包装类。
• 如果该属性是一个对象引用，并且该类的 equals 方法通过递归调用 equals 来比较该属性，并递归地调用hashCode 方法。 如果需要更复杂的比较，则计算此字段的“范式（“canonical representation）”，并在范式上调用 hashCode。 如果该字段的值为空，则使用 0（也可以使用其他常数，但通常来使用 0 表示）。
• 如果属性 f 是一个数组，使用Arrays.hashCode方法。
• 如果真的需要哈希函数而不太可能产生碰撞，请参阅 Guava
  框架的的 com.google.common.hash.Hashing [Guava] 方法。
• Objects 类有一个静态方法，它接受任意数量的对象并为它们返回一个哈希码。

---

第十二条：始终重写 toString 方法

1. 利于日志打印，日志排查错误。

---

第十三条：谨慎地重写 clone 方法

1. 浅克隆，谨慎使用
2. 深克隆

3. 实现Cloneable 接口

   
   
   image.png

---

第十三条：考虑实现 Comparable 接口

通过实现 Comparable 接口，可以让你的类与所有依赖此接口的通用算法和集合实现进行互操作。强烈 建议满足一下特性。

• 自反性
• 对称性
• 传递性

总而言之，无论何时实现具有合理排序的值类，你都应该让该类实现 Comparable 接口，以便在基于比较的集合中轻松对其实例进行排序，搜索和使用。 比较 compareTo 方法的实现中的字段值时，请避免使用「<」和「>」运算符。 相反，使用包装类中的静态 compare 方法或 Comparator 接口中的构建方法。