https://github.com/clxering/Effective-Java-3rd-edition-Chinese-English-bilingual/blob/dev/

准则一 考虑以静态工厂方法代替构造函数

优点

• 静态工厂方法与构造函数相比的第一个优点，静态工厂方法有确切名称。
  知名见意，静态方法我们可以通过命名这个方法，知道这个方法返回什么对象。但是构造函数往往是通过参数来控制对象，需要我们对提供的构造函数有定的了解。
• 静态工厂方法与构造函数相比的第二个优点，静态工厂方法不需要在每次调用时创建新对象。
  静态方法是共享的，不需要创建对象就能调用。
• 静态工厂方法与构造函数相比的第三个优点，可以通过静态工厂方法获取返回类型的任何子类的对象。
• 静态工厂的第四个优点是，返回对象的类可以随调用的不同而变化，作为输入参数的函数。
• 静态工厂的第五个优点是，当编写包含方法的类时，返回对象的类不需要存在。

缺点

• 仅提供静态工厂方法的主要局限是，没有公共或受保护构造函数的类不能被子类化。
• 静态工厂方法的第二个缺点是程序员很难找到它们。

最佳实践

Boolean的valueOf

public static Boolean valueOf(boolean b) {
      return (b ? TRUE : FALSE);
  }

顺便提一嘴,布尔类型的变量是两个不可变的，实际上改变一个布尔类型值就是改变了引用：

Boolean sington = Boolean.valueOf(true);
sington = false;

通过字节码就看的比较清楚，sington = false;还是调用valueOf 这个静态方法

集合中的

public static <T> List<T> unmodifiableList(List<? extends T> list)
public static <T> Set<T> unmodifiableSet(Set<? extends T> s)
public static <K,V> Map<K,V> unmodifiableMap(Map<? extends K, ? extends V> m)

准则二 当构造函数有多个参数时，考虑改用构建器

优点

可伸缩构造函数模式可以工作，但是当有很多参数时，编写客户端代码是很困难的，而且读起来更困难。那么使用构造者模式可以在最后build的时候进行检验，也不需要写一堆Get，Set。但是通常来说构造对象发逻辑比较复杂时候也经常实用构造者模式。

缺点

为了创建一个对象，你必须首先创建它的构建器。虽然在实际应用中创建这个构建器的成本可能并不显著，但在以性能为关键的场景下，这可能会是一个问题。而且，建造者模式比可伸缩构造函数模式更冗长，因此只有在有足够多的参数时才值得使用，比如有 4 个或更多参数时，才应该使用它。

最佳实践

com.google.common.collect.ImmutableMap#Builder<K, V>

static final ImmutableMap<String, Integer> WORD_TO_INT = new ImmutableMap.Builder<String, Integer>()          .put("one", 1)          
.put("two", 2)          
.put("three", 3)          
.build();

准则三 使用私有构造函数或枚举类型实施单例属性

最佳实践

例如Java中的Runtime,可以看到构造函数是私有的，提供了一个静态方法返回单例的Runtime 对象。

public class Runtime {
    private static Runtime currentRuntime = new Runtime();

    /**
     * Returns the runtime object associated with the current Java application.
     * Most of the methods of class <code>Runtime</code> are instance
     * methods and must be invoked with respect to the current runtime object.
     *
     * @return  the <code>Runtime</code> object associated with the current
     *          Java application.
     */
    public static Runtime getRuntime() {
        return currentRuntime;
    }
    /** Don't let anyone else instantiate this class */
    private Runtime() {}
 }

准则四 用私有构造函数实施不可实例化

这个准则主要是由于，有的时候我们这类的作用仅仅是将一些通用的方法聚集在一起，比如我们这个方法是工具类。我们对这个类进行实例化是毫无意义的。

方式一

class NonInstantiionClass {
    // 构造函数私有化
    private NonInstantiionClass() {
    }
}

方式二

class NonInstantiionClass {
   public NonInstantiionClass() {
       throw new UnsupportedOperationException("不支持实例化");
   }
}

最佳实践

在Java总Arrays是一个工具类，里面大多数方法都是静态的，可以看到它的构造函数就被私有化了。

准则五 依赖注入优于硬连接资源

这个准则是什么意思呢？
首先来看一个反例，也是书上的例子：

public class SpellChecker {
    private static final Lexicon dictionary = ...;
    private SpellChecker() {} // Noninstantiable
    public static boolean isValid(String word) { ... }
    public static List<String> suggestions(String typo) { ... }
}

比如说这个类，我们要检查单词拼写的正确性，我们需要一个参考标准，而这个标准就是Lexicon这个字典，这样写代码好像貌似完全可行。但是有个缺陷，那如果我们需要引入新的字典怎么办，或者这个字典并不是非常的全面我们需要替换字典怎么办呢？

public class SpellChecker {
    /**
     * 注入字典的抽象 通过注入的方式是不是灵活性更强了呢?
     * 如果我们要替换字典只需通过set注入改变引用即可
     */
    private Dictionary dictionary;
    public SpellChecker() {}
    public static boolean isValid(String word) {
        return Boolean.FALSE;
    }
    public static List<String> suggestions(String typo) {
        return Collections.emptyList();
    }
    public void setDictionary(Dictionary dictionary) {
        this.dictionary = dictionary;
    }
}

我个人的理解就是这样，这也是为什么Java编程中有个准则叫依赖倒置原则，我们常用的Spring IOC容器也是这个思想。

准则六 避免创建不必要的对象

下面这两个语句到底有什么区别？

String s = new String("bikini"); 
String s = "bikini";

通过对比字节码我们可以看到第二条语句没有new 而是直接使用了LDC（Push item from run-time constant pool），根据JVM规范是把这个对方放到常量池中了，所以说第一条语句其实创建了多余的对象。其实这里也是经常说的字符串常量池，在直接使用双引号申明字符串的时候会放到字符串常量池中。
书中还有一个例子，关于原生类型和包装类型，看到这个例子之前我经常用包装类型，以后得改变这个习惯：

private static long sum1() {
     Long sum = 0L;
     for (long i = 0; i <= Integer.MAX_VALUE; i++)
         sum += i;
     return sum;
 }
 private static long sum2() {
     long sum = 0L;
     for (long i = 0; i <= Integer.MAX_VALUE; i++)
         sum += i;
     return sum;
 }

 public static void main(String[] args) {
     System.out.println("===========================");
     long cur = System.currentTimeMillis();
     sum1();
     System.out.println("sum1 cost time : " + (System.currentTimeMillis() - cur));
     System.out.println("-----------------------------");
     cur = System.currentTimeMillis();
     sum2();
     System.out.println("sum2 cost time : " + (System.currentTimeMillis() - cur));
 }

差距既然如此之大，原因就在于使用包装类创建了很多不必要的对象。

另外书中给我们举了这个例子：

static boolean isRomanNumeral(String s) {
    return s.matches("^(?=.)M*(C[MD]|D?C{0,3})" + "(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");
}

这个例子有什么问题，问题就在于每一次调用都会去实例化"^(?=.)M*(C[MD]|D?C{0,3})" + “(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$” 这个正则的Pattern对象，但是这个Pattern其实完全可以复用。如果说我们这个函数调用的比较频繁，就会创建大量的对象，可能会增加monitor GC的频率，影响性能。怎么优化呢?

// 这样子是不是就是复用了这个对象呢? 这里还有一个思考,就是这种写法其实是饿汉式的写法,一上来就创建,我们是不是可以考虑延迟初始化呢?这个就需要结合具体的场景了
private final static Pattern MATCH_PATTERN = Pattern.compile("^(?=.)M*(C[MD]|D?C{0,3})\" + \"(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");

最佳实践

这个准则的最佳实践其实就是我们常用的数据库连接池、线程池，用设计模式的角度来看待的话就是享元模式。这个准则更适合应用在我们使用的对象可以复用并且创建它的成本是比较大的，如果成本可以忽略不计也没有必要。

准则七 排除过时的对象引用避免内存泄漏

常见的场景

• 一个类管理它自己的内存时，程序员应该警惕内存泄漏。当释放一个元素时，该元素中包含的任何对象引用都应该被置为 null。

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

// Can you spot the "memory leak"?
public class Stack {
    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;

    public Stack() {
        elements = new Object[DEFAULT_INITIAL_CAPACITY];
    }

    public void push(Object e) {
        ensureCapacity();
        elements[size++] = e;
    }
    // 这里就存在内存泄漏，因为这个数据是这个类进行管理的,我们并没有释放对象(只是改变了数组的大小),它依然被数组引用
    public Object pop() {
        if (size == 0)
            throw new EmptyStackException();
        return elements[--size];
    }

    /**
     * Ensure space for at least one more element, roughly
     * doubling the capacity each time the array needs to grow.
     */
    private void ensureCapacity() {
        if (elements.length == size)
            elements = Arrays.copyOf(elements, 2 * size + 1);
    }
}

• 缓存，要有淘汰策略，或者设置软引用，或者后台线程定期清理。
• 内存泄漏的第三个常见来源是侦听器和其他回调。 如果你实现了一个 API，其中客户端注册回调，但不显式取消它们，除非你采取一些行动，否则它们将累积。确保回调被及时地垃圾收集的一种方法是仅存储对它们的弱引用，例如，将它们作为键存储在 WeakHashMap 中。

准则八 避免使用终结器和清除器

准则九 使用 try-with-resources 优于 try-finally