第八条: 避免使用 Finalizer(finally) 和 Cleaner（try-with-resources)机制
- Java 9 开始，Finalizer 机制已被弃用，但仍被 Java 类库所使用。 Java 9 中 Cleaner 机制代替了 Finalizer 机制。Cleaner 机制不如 Finalizer 机制那样危险，但仍然是不可预测，运行缓慢并且通常是不必要的。
- Finalizer 和 Cleaner 机制的一个缺点是不能保证他们能够及时执行。在一个对象变得无法访问时，到Finalizer 和 Cleaner 机制开始运行时，这期间的时间是任意长的。 这意味着你永远不应该 Finalizer 和 Cleaner 机制做任何时间敏感（time-critical）的事情。
- 不要相信 System.gc 和 System.runFinalization 方法。 他们可能会增加 Finalizer 和 Cleaner 机制被执行的几率，但不能保证一定会执行。 曾经声称做出这种保证的两个方法System.runFinalizersOnExit 和它的孪生兄弟 Runtime.runFinalizersOnExit ，包含致命的缺陷，并已被弃用了。
- Finalizer 机制的另一个问题是在执行 Finalizer 机制过程中，未捕获的异常会被忽略，并且该对象的 Finalizer 机制也会终止 。未捕获的异常会使其他对象陷入一种损坏的状态（corrupt state）。如果另一个线程试图使用这样一个损坏的对象，可能会导致任意不确定的行为。通常情况下，未捕获的异常将终止线程并打印堆栈跟踪（
stacktrace），但如果发生在 Finalizer 机制中，则不会发出警告。Cleaner 机制没有这个问题，因为使用 Cleaner 机制的类库可以控制其线程。 - 使用Cleaner时Finalizer的效率的差不多50倍。
- 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 语句
- 精简，不易出错，可读性好。
- try-with-resources不会覆盖异常。例如在读取文件时，readLine方法发生异常，调用 close 方法可能会异常。try-finally第二个异常会覆盖第一个异常。try-with-resources 如果调用 readLine 和（不可见） close 方法都抛出异常，则后一个异常将被抑制，而不是前者。
总结
结论很明确：在处理必须关闭的资源时，使用 try-with-resources 语句替代 try-finally 语句。 生成的代码更简洁，更清晰，并且生成的异常更有用。 try-with-resources 语句在编写必须关闭资源的代码时会更容易，也不会出错，而使用 try-finally 语句实际上是不可能的。
第十条：重写 equals 方法时遵守通用约定
- 什么时候需要重写 equals 方法呢？
如果一个类包含一个逻辑相等的概念，此概念有别于对象标识，而且父类还没有重写过 equals 方法。 - 当你重写 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 方法
- 在每个类中，在重写 equals 方法的时侯，一定要重写 hashcode 方法。 如果不这样做，你的类违反了 hashCode的通用约定，这会阻止它在 HashMap 和 HashSet 这样的集合中正常工作。根据 Object 规范，以下时具体约定。
- 当无法重写 hashCode 时，所违反第二个关键条款是：相等的对象必须具有相等的哈希码。
- 重写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 方法
- 利于日志打印，日志排查错误。
第十三条：谨慎地重写 clone 方法
- 浅克隆，谨慎使用
- 深克隆
-
实现Cloneable 接口
image.png
第十三条：考虑实现 Comparable 接口
通过实现 Comparable 接口，可以让你的类与所有依赖此接口的通用算法和集合实现进行互操作。强烈 建议满足一下特性。
- 自反性
- 对称性
- 传递性
总而言之，无论何时实现具有合理排序的值类，你都应该让该类实现 Comparable 接口，以便在基于比较的集合中轻松对其实例进行排序，搜索和使用。 比较 compareTo 方法的实现中的字段值时，请避免使用「<」和「>」运算符。 相反，使用包装类中的静态 compare 方法或 Comparator 接口中的构建方法。
