RegretLi的博客

try-with-resources 优先于 try-finally 根据传统，try-finally 块是确保关闭资源的一个有效方法，但是当多个资源时，就可能造成代码的混乱。而且某个 finally 块中也可能抛出异常，就会使得之前抛出的异常信息被覆盖。 public static void copy(String src, String dst) throws IOException { InputStream in = new FileInputStream(src); try {

避免使用终结方法和清除方法 使用终结方法的缺点 首先应该清楚的是，终结方法（finalize()）不等同于 C++ 中等析构方法。 这类方法不能保证其会被及时执行，甚至不能保证会被执行，因此，不应该依赖终结方法或者清除方法来更新重要的持久状态。 终结方法内部如果产生了未被捕获的异常，则终结方法也会异常终止，而且，不会打印异常警告。 使用终结方法会产生非常严重的性能损失。主要是因为终结方法阻止了有效的垃圾回收。 终结方法也存在安全问题。可以通过反序列化的对象抛出异常，使得恶意子类的终结方法中构造了一部分的对象

消除过期的对象引用 在手工管理内存的语言中（如“C++”），当对象使用之后，需要手动释放其所占有的内存，例如 C++ 中的析构函数。但 Java 具有垃圾回收器，降低了内存管理的难度，但仍会出现内存泄漏的风险。如： public class Stack { private Object[] elements; private int size = 0; private static final int DEFAULT_INITIAL_CAPACITY = 16; publi

避免创建不必要的对象 如果对象是不可变的，那么它就始终可以被重用。 反面例子 String s = new String("bikini"); 该语句每次被执行时，都会创建一个新的 String 实例，但是这些创建对象的动作是不必要的。传递给 String 构造器的参数本身就是一个 String 实例，功能方面等同于构造器创建的所有对象。应该改进为 String s = "bikini"; 对于同时提供了静态工厂方法和构造器的不可变类，通常优先使用静态工厂方法而不是构造器方法，以避免创建不必要的对象。

优先考虑依赖注入来引入资源 有许多类会依赖一个或多个底层的资源。即这个类可能会依赖其他的类的实例。 最好的采取做法是，当创建一个新的实例时，就将该实例所依赖的资源传入到构造器中。这就是依赖注入的一种形式。 public class SpellChecker { private final Lexicon dictionary; public SpellChecker(Lexicon dictionary) { this.dictionary = Objects.re

使用私有构造器或者枚举类型强化 Singleton 属性 Singleton 单例，表示仅仅被实例化一次的类。 将构造器私有化是实现 Singleton 的常见方法 如 public class Elvis { public static final Elvis INSTANCE = new Elvis(); private Elvis () {} public void leaveTheBuilding() { } } 此时，静态 final

遇到多个构造器参数时，要考虑使用构建器

静态工厂方法的优劣