第一條：考慮用靜態工廠方法替代構造器

靜態工廠方法的優點：

1.具有名字，有可閱讀性。

2.不必在每次呼叫他們的時候都建立一個新物件。
應用：①單例物件 ②列舉
3.可以返回返回值型別的任何子型別的物件。
應用：
①EnumSet的靜態工廠方法根據元素的個數選擇返回RegalarEnumSet還是JumboEnumSet，從而隱藏了底層的確切返回值。
②服務提供者介面(通過JDBC的Driver、DriverManager和Connection來理解)。
4.在建立引數化型別例項的時候，使得程式碼變得更加簡潔。 靜態工廠方法的缺點： 1.含有該方法的類如果沒有公有或者受保護的構造器就不能被繼承。

public class Father {
    private Father(){
 
    }
}
//報錯
class Son extends Father{
 public static void main(String[] args) {
  Son s = new Son();
 }
}

2.和其他靜態方法實際沒有任何區別，不會被API文件明確標識出來，但遵守標準的命名習慣可以彌補這一劣勢。

第二條：遇到多個構造器引數時要考慮用構建器

1.重疊構造器模式
重疊構造器模式可行，但是當有許多引數的時候，客戶端程式碼會很難編寫，並且閱讀起來比較困難。

2.JavaBeans模式
呼叫一個無參構造器來建立物件，然後呼叫setter方法來設定每個必要的引數。
優點：彌補了重疊構造器模式的不足，易建立，易閱讀。
缺點：在構造過程中JavaBean可能處於不一致的狀態。並且該模式阻止了把類做成不可變類的可能，這要付出額外的代價來確保它的執行緒安全。

3.Builder模式
優點：既能保證重疊構造器模式那樣的安全性（個人理解為可構建不可變類，即執行緒安全）又能保證像JavaBeans的可讀性。
大致過程：
不直接生成想要的物件，而是讓客戶端利用所有必要的引數呼叫構造器，得到一個builder物件，然後客戶端通過builder物件呼叫類似setter的方法來設定可選引數，最後，利用builder物件呼叫build方法來生成不可變的物件。
關於內部類的部落格：http://www.cnblogs.com/dolphin0520/p/3811445.html，這個博主寫的非常好，基礎篇看完後更為深刻地理解了內部類。
關於builder設計模式的部落格: http://www.importnew.com/6605.html

第三條：用私有構造器或列舉型別強化Singleton屬性

1.通過final的公有靜態成員來允許客戶端訪問類的唯一例項
缺點：有可能借助AccessibleObject.setAccessible方法通過反射機制呼叫私有構造器。
改進：可以通過修改構造器，讓它在被要求建立第二個例項的時候丟擲異常。

2.通過靜態工廠方法
缺點：同點1
優點：①提供靈活性，不改變API的前提下，可以取消單例的想法
            ②與泛型有關

3.編寫一個包含單個元素的列舉型別
優點：無償地提供了序列化機制，防止多次例項化。實現Singleton的最佳方法

第四條：通過私有構造器強化不可例項化的能力

當你編寫工具類utility class(把具體功能組織起來，只包含靜態方法和靜態域的類，如java.lang.Math,java.util.Collections,java.lang.Arrays)時，不希望它被例項化。但在缺少顯式構造器的情況下，編譯器會自動提供一個公有的、無參的構造器。所以應該把構造器私有化。並且可以選擇在構造器方法內部throw new AssertionError()，可以避免不小心在類的內部呼叫構造器。

第五條：避免建立不必要的物件

1.一般來說，最好能夠重用物件而不是每次都建立一個功能相同的物件。
String s = "stringette"應代替String s = new String("stringgette")

2.對於同時提供了靜態工廠方法和構造器的不可變類，應優先使用靜態工廠方法，避免建立不必要的物件。

3.對於一個給定的Map物件，多次呼叫keySet都返回同一個Set例項。

4.要優先使用基本型別而不是裝箱基本型別，要當心無意識的自動裝箱。

5.不要片面的認為“建立物件的代價非常昂貴，我們應該儘可能的避免建立物件”。相反地，有的小物件的構造器只做很少量的顯式工作。所以，小物件的建立和回收是非常廉價的。

6.可以維護自己的常量池來避免建立物件，如資料庫連線池。但也有缺點：程式碼複雜，增加記憶體佔用，損害效能。

7.請分清楚什麼時候該重用物件，什麼時候該建立物件。

第六條：消除過期的物件引用

public class Stack{
	private Object[] elements = new Object(10);
	private int size = 0;

	public void push(Obejct e){
		ensureCapacity();
		elements[size++];
	}

	public Object pop(){
		if(size == 0)
			throw new EmptyStackException();
		return elements[--size];
	}

	//判斷是否需要擴容
	private void ensureCapacity(){
		if(elements.length == size)
			elements = Arrays.copyOf(elements,2 * size + 1);
	}
}

上述程式碼簡單的修改了書本程式碼方便自己理解，因為這個棧類是通過一個變數size來維護容器裡面元素的個數，當彈出棧頂元素時，並沒有真正的刪除陣列對元素的引用，只是size--，實際上元素還是被物件引用著，該元素不會被當作垃圾回收。要解決這個問題只需要將elements[size] = null即可。
但這並不是常見的，清空物件引用應該是一種例外，而不是一種規範行為，多數時候最好定義一個變數在最緊湊的作用域範圍。

何時該清空引用？如上述例子，Stack類自己管理記憶體的情況就應該手工清空引用。

第七條：避免使用終結方法

1.終結方法通常是不可預測的，也是很危險的，一般情況下是不必要的。

2.不應該依賴終結方法來更新重要的持久狀態。

3.使用終結方法有非常嚴重的效能損失。

4.應該提供一個顯式的終止方法(如InputStream的close方法)來替代終結方法。

優點：
①終結方法可以充當“安全網”。避免編寫類時，忘記呼叫顯式的構造方法而導致資源沒有釋放。
②回收“本地對等體”

注意點：
對於一個帶有終結方法的非final公共類，應該考慮使用一個私有例項變數儲存一個匿名內部類例項，該匿名內部類例項重寫終結方法，並在裡面終結外部類。

public class Foo{
	
	private final Object finalizerGuardian = new Object(){
		@Override
		protected void finalize() throws Throwable{
			//終結外部類的操作
		}
	}
}