來源：https://blog.dogchao.cn/?p=70

《Effective JavaJava》名著，必讀。如果能嚴格遵從本文的原則，以編寫API的質量來苛求自己的代碼，會大大提升編碼素質。

以下內容只記錄了我自己整理的東西，還是建議讀原文。為了聚焦知識點，一些說明故意忽略掉了。相當于是一篇摘要。

---

1、考慮用靜態工廠方法替代構造函數

例子：

Integer.valueOf(“1”)、Boolean.valueOf(“true”)等。

優勢：

• 可讀性高（方法名）

• 性能（不一定創建對象）

• 靈活性高

下面針對三個優勢進行一些解讀。

可讀性高

new Point(x,y)和Point.at(x,y)、Point.origin()。構造函數只能看出兩個參數，不知其意，后者更易理解。

性能

在某些情況下，可以事先進行實例化一些對象，調用時直接調用即可，不需要進行改變。比如，Boolean。

public?final?class?Boolean?implements?Serializable,?Comparable<Boolean>?{//?預先設置兩個對象public?static?final?Boolean?TRUE?=?new?Boolean(true);public?static?final?Boolean?FALSE?=?new?Boolean(false);public?Boolean(boolean?var1)?{this.value?=?var1;}public?Boolean(String?var1)?{this(parseBoolean(var1));}//?工廠方法public?static?Boolean?valueOf(boolean?var0)?{return?var0?TRUE:FALSE;????//?返回預先設置的對象，而不是創建對象}//?工廠方法public?static?Boolean?valueOf(String?var0)?{return?parseBoolean(var0)?TRUE:FALSE;}//?...?other?code }

靈活性高

可根據具體情況，返回子類。相當于更強大的工廠。直接從父類獲取到子類。尤其適用于工具類（提供各種API）。例子：Collections。

public?class?Collections?{//?私有，典型工廠private?Collections()?{}public?static?final?List?EMPTY_LIST?=?new?EmptyList<>();//?工廠方法public?static?final?<T>?List<T>?emptyList()?{return?(List<T>)?EMPTY_LIST;}private?static?class?EmptyList<E>?extends?AbstractList<E>?implements?RandomAccess,?Serializable?{//?code}//?工廠方法public?static?<E>?List<E>?checkedList(List<E>?list,?Class<E>?type)?{//?根據具體情況，獲取相應子類return?(list?instanceof?RandomAccess??new?CheckedRandomAccessList<>(list,?type)?:new?CheckedList<>(list,?type));}//?子類1static?class?CheckedRandomAccessList<E>?extends?CheckedList<E>?implements?RandomAccess?{CheckedRandomAccessList(List<E>?list,?Class<E>?type)?{super(list,?type);}public?List<E>?subList(int?fromIndex,?int?toIndex)?{return?new?CheckedRandomAccessList<>(list.subList(fromIndex,?toIndex),?type);}}//?子類2static?class?CheckedList<E>?extends?CheckedCollection<E>?implements?List<E>?{//?code} }

2、多個構造函數時，考慮使用構造器

尤其在進行Android開發時，會碰到這種情況。通常是一個對象，具有多個成員變量可能需要初始化，常規方法，需要提供大量構造函數。例如：

//?非Android中的AlertDialog，便于說明問題，舉個例子 public?class?AlertDialog?{private?int?width;private?int?height;private?String?title;private?String?confirmText;private?String?denyText;private?AlertDialog(){}public?AlertDialog(int?width,?int?height){????//?空白的警告框AlertDialog(width,height,null);}//?帶標題的警告框public?AlertDialog(int?width,?int?height,?String?title){????//?帶標題的警告框AlertDialog(width,?height,?title,?"確定");}//?帶標題的警告框，有確定按鈕public?AlertDialog(int?width,?int?height,?String?title,?String?confirm){???AlertDialog(width,?height,?title,?confirm,?null);}//?帶標題的警告框，有確定按鈕，取消按鈕public?AlertDialog(int?width,?int?height,?String?title,?String?confirm,?String?denyText){//?set?every?thing.} }

有多種樣式的警告框，為了調用方便，必須提供多個構造函數。否則用戶在調用時，只能使用完整構造函數，容易犯錯且無法進行閱讀。極不靈活。如果采用另外一種方式，則可以解決，但會花費很多經歷處理并發的情況:

//?非Android中的AlertDialog，便于說明問題，舉個例子 public?class?AlertDialog?{private?int?width;private?int?height;private?String?title;private?String?confirmText;private?String?denyText;public?AlertDialog(){}//?空白的構造函數public?void?setWidth(int?width){this.width?=?width;}//?其他set方法 }

調用時，通過調用各個參數的set方法進行設置。問題來了：

并發

無法進行參數校驗。例如，只創建了對象，設置了標題，卻沒有尺寸，相當于創建了一個沒有尺寸的警告框。

在Android中，大量的控件都使用了構造器Builder。

//?非Android中的AlertDialog，便于說明問題，舉個例子 public?class?AlertDialog?{private?int?width;private?int?height;private?String?title;private?String?confirmText;private?String?denyText;//?privateprivate?AlertDialog(){}//?Builder中使用protected?AlertDialog(Builder?b){width?=?b.width;height?=?b.height;//?.....if(width==0||height==0)?throws?new?Exception("size?must?be?set");}//?構造器public?static?class?Builder?{private?int?width;private?int?height;private?String?title;private?String?confirmText;private?String?denyText;//?注意：返回的Builder。public?Builder?setTitle(String?title)?{this.title?=?title;return?this;}//?其他set...public?AlertDialog?build(){return?AlertDialog(this);}} }

于是，可以根據相應需求，進行相應設置，并在AlertDialog真正構造時，進行參數校驗。就像這樣：

new?AlertDialog.Builder().setTitle("提示").build();

上述例子，會成功拋出異常。

3、用私有化構造器或者枚舉型強化Singleton。

Singleton指最多會被實例化一次的類。通常情況下，以前的做法是沒有問題的。但是在某些高級情況，通過使用反射的相關知識訪問private的構造函數，破壞Singleton。

public?class?Elvis{//?注意，公有final對象public?static?final?Elvis?INSTANCE?=?new?Elvis();private?Elvis(){} }

另一種情況，在序列化的過程中，反序列化得到的對象已經不再是以前的對象（破壞了Singleton），這種情況下，可以通過單元素枚舉型處理。

public?enum?Elvis{INSTANCE;//?some?methods }

4、通過私有化構造器強化不可實例化的能力

有一些工具類，僅僅是提供一些能力，自己本身不具備任何屬性，所以，不適合提供構造函數。然而，缺失構造函數編譯器會自動添加上一個無參的構造器。所以，需要提供一個私有化的構造函數。為了防止在類內部誤用，再加上一個保護措施和注釋。

public?class?Util{private?Util(){//?拋出異常，防止內部誤調用throw?new?AssertionError();} }

弊端是無法對該類進行繼承（子類會調用super()）。

5、避免創建不必要的對象

• 對象的重用

• 昂貴的對象，使用對象池

• 廉價的對象，慎用對象池。現代JVM對廉價對象的創建和銷毀非常快，此時不適于使用對象池。

6、消除過期的對象引用

以下三種情況可能會造成內存泄露：

• 自己管理的內存（數組長度減小后，pop出的對象容易導致內存泄漏）

• 緩存

• 監聽和回調

自己管理的內存

對于自己管理的內存要小心，比如：

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;????//?allocate新的堆內存和棧內存}public?Object?pop(){if(size==0)?throw?new?EmptyStackException();return?element[--size];????// pop出element[size]，該對象不再有效。內存泄漏原因。}private?void?ensureCapacity(){if(elements.length==size)elements?=?Arrays.copyOf(elements,?2*size+1);} }

彈出的對象不再有效，但JVM不知道，所以會一直保持該對象，造成內存泄露。

解決：

public?Object?pop(){if(size==0)?throw?new?EmptyStackException();elements[size]?=?null;????????//?等待回收return?element[--size]; }

緩存

緩存的對象容易被程序員遺忘，需要設置機制來維護緩存，例如不定期回收不再使用的緩存（使用定時器）。某些情況下，使用WeakHashMap可以達到緩存回收的功效。注，只有緩存依賴于外部環境，而不是依賴于值時，WeakHashMap才有效。

監聽或回調

使用監聽和回調要記住取消注冊。確保回收的最好的實現是使用弱引用（weak reference），例如，只將他們保存成WeakHashMap的鍵。

7、避免顯示調用GC

Java的GC有強大的回收機制，可以簡單的記住：不要顯示調用finalizer。可以這樣理解：

jvm是針對具體的硬件設計的，然而程序卻不是針對具體硬件設計的，所以，java代碼無法很好的解決gc問題（因為他具有平臺差異化）。另外，finalizer的性能開銷也非常大，從這個角度上考慮也不應該使用它。

8、覆蓋equals方法請遵守通用約定

• 自反性。x.equals(x) == true

• 對稱性。當前僅當y.equals(x)==true時，x.equals(y)==true

• 傳遞性。if(x.equals(y)&&y.equals(z))，y.equals(z)==true

• 一致性。

• 非空性。x.equals(null)==false

9、覆蓋equals方法時總要覆蓋hashCode

為了保證基于散列的集合使用該類（HashMap、HashSet、HashTable），同時，也是Object.hashCode的通用約定，覆蓋equals方法時，必須覆蓋hashCode。

10、始終覆蓋toString

Object的toString方法的通用約定是該對象的描述。注意覆蓋時，如果有格式，請備注或者嚴格按照格式返回。

11、謹慎覆蓋clone

12、考慮實現Comparable接口

13、使類和成員的可訪問性最小化

目的是解耦。簡單來講，使用修飾符的優先級從大到小，private>protected>default(缺省)>public。如果在設計之初，設計為private修飾符后，在之后的編碼過程如果不得不擴大其作用于，應該先檢查是否設計的確如此。

子類覆蓋超類，不允許訪問級別低于超類的訪問級別。（超類的protected，子類覆蓋后不能改為default）。

成員變量決不允許是公有的。一旦設置為公有，則放棄了對他處理的能力。這種類并不是線程安全的。即使是final的，也不允許。除非希望通過public static final來暴露常量。成員變量總是需要使用setter和getter來維護。有一個例外：長度非零的數組。這是安全漏洞的一個根源。

//?安全漏洞！此處的數組，并不是不可變的 public?static?final?Thing[]?VALUES?=?{...}

改進：

private?static?final?Thing[]?PRIVATE_VALUES?=?{...} //?此時獲取到的才是“常量” public?static?final?List<Thing>?VALUS?=?Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES))

另一種：

private?static?final?Thing[]?PRIVATE_VALUES?=?{...} //?此時獲取到的才是“常量” public?static?final?Thing[]?values(){return?PRIVATE_VALUES.clone(); }

14、在公有類中使用訪問方法而非公有成員變量（類似13）

15、使可變性最小化

16、復合優先于繼承

繼承有利于代碼復用，但是盡可能不要進行跨包的繼承。包內的繼承是優秀的設計方式，一個包里的文件處在同一個程序員的控制之下。但是繼承有其局限性：子類依賴于超類。超類一旦發生更改，將可能破壞子類。并且，如果超類是有缺陷的，子類也會得“遺傳病”。

復合，即不擴展已有的類，而是在的類中新增一個現有類的。相當于現有類作為一個組建存在于新類中。如此，將只會用到需要用到的東西，而不表現現有類所有的方法和成員變量。新類也可以稱為“包裝類”，也就是設計模式中的Decorate模式。

17、要么就為繼承而設計，并提供文檔說明，要么就禁止繼承

18、接口優于抽象類

19、接口只用于定義類型

20、類層次優先于標簽類

21、用函數對象表示策略

函數參數可以傳入類似listener的對象，目的是使用listener中的方法。如果使用匿名的參數，每一次調用會創建新的對象。可以將listener聲明為成員變量，每次都復用同一個對象，并且可以使用靜態域（static變量）。比如String類的CASE_INSENSITIVE_ORDER域。

22、優先考慮靜態類成員

嵌套類的目的應該只是為了他的外圍類提供服務，如果以后還可能用于其他環境中，則應該設計為頂層類。靜態類相當于一個普通的外部類，只是恰好聲明在了一個類內部。通常的用戶是：Calculator.Operation.PLUS等。和普通類的區別只是，在PLUS前，有了2個前綴，來表明其含義。而非靜態類必須存在于外部類對象中。不要手動在外部創建一個內部非靜態類對象，創建的過程是：instance.New MemberClass()。這非常奇怪。

如果成員類不需要訪問外圍類，則需要添加static，是他成為靜態成員類，否則每個實例都將包含一個額外指向外圍對象的引用。將會影響垃圾回收機制。

23、應指定泛型的具體類型，而不是直接使用原生類型。

例如，應該指定List<E>，而不建議直接使用List。

24、消除非首檢警告

在使用IDE進行編碼時，強大的IDE都會在你編碼過程中提示warning，需要盡可能的消除warning，至少，應該小心這些warning。慎用SuppresWarning，如果IDE提示你可以通過添加該注解解決掉warning，請不要那么做。如果實在要使用，請添加注釋說明原因。

25、列表優先于數組

類比泛型，數組是有一定缺陷的。List和List是沒有關系的，而Sub[]是Super[]的子類。

//?Fails?at?runtime Object[]?objectArray?=?new?Long[1]; objectArray[0]?=?"I?don't?fit?in";???????//?throw?exception//?won't?compile List<Object>?ol?=?new?ArrayList<Long>();???//?Incompatible?types ol.add("I?don't?fit?in");

從代碼中可以看到，使用泛型，會提前發現錯誤。

26、優先考慮泛型

27、優先考慮泛型方法

28、利用有限制通配符來提升API的靈活性

PECS，producer-extends，consumer-super。

//public?class?Stack<E>{ //????public?Stack(); //????public?void?push(E?e); //????public?E?pop(); //????public?boolean?isEmpty(); //}public?void?pushAll(Iterator<??extends?E>?src){for(E?e?:?src)push(e); }public?void?popAll(Collection<??super?E>?dst){while(!isEmpty()){dst.add(pop());} }//?Get?and?Put?Principle

所有comparable和comparator都是消費者（Consumer）。

29、優先考慮類型安全的異構容器

30、用enum代替int常量

public?enum?Apple?{?FUJI,?PIPPIN,?GRANNY_SMITH?} public?enum?Orange?{?NAVEL,?TEMPLE,?BLOOD?}

枚舉型在java中非常強大，當需要一組固定常量時，使用enum比int好很多。比如代碼可讀性，安全性等。

31、enum用實例域代替序數

//?bad?solution public?enum?Ensemble?{SOLO,?DUET,?TRIO,?QUARTET,?QUINTET,?SEXTET,?SEPTET,?OCTET,?NONET,?DECTET;public?int?numberOfMusicians()?{?return?ordinal()?+?1;?} } //?//?improvement public?enum?Ensemble?{SOLO(1),?DUET(2),?TRIO(3),?QUARTET(4),?QUINTET(5),?SEXTET(6),?SEPTET(7),?OCTET(8),?NONET(9),?DECTET(10),?TRIPLE_QUARTET(12);private?final?int?numberOfMusicians;Ensemble(int?size)?{?this.numberOfMusicians?=?size;?}public?int?numberOfMusicians()?{?return?numberOfMusicians;?} }

永遠不要像第一種的方式，利用序數訪問enum，需要在構造函數中使用參數來初始化。

32、用EnumSet代替位域

public?class?Text{public?static?final?int?STYLE_BOLD?????????????????????=?1?<<?0;????//?1public?static?final?int?STYLE_ITALIC????????????????????=?1?<<?1;????//?2public?static?final?int?STYLE_UNDERLINE??????????=?1?<<?2;????//?4public?static?final?int?STYLE_STRIKETHROUGH?=?1?<<?3;????//?8public?void?applyStyles(int?styles){??//?...} }//? text.applyStyles(STYLE_BOLD?|?STYLE_ITALIC);

以上叫做位圖法，但是有更好的方案來傳遞多組常量——EnumSet。

public?class?Text{public?enum?Style?{?BOLD,?ITALIC,?UNDERLINE,?STRIKETHROUGH?}//?注意此處，使用的是Set而不是EnumSetpublic?void?applyStyles(Set<Style>?styles){??//?...} }//? text.applyStyles(EnumSet.of(Style.BOLD,?Style.ITALIC));

33、用EnumMap代替序數索引

任何時候都不要使用enum的ordinal()方法。

34、用接口模擬可伸縮的枚舉

35、注解優先于命名模式

36、堅持使用Override注解

38、檢查參數的有效性

公有方法檢查參數，參數異常需要跑出Exception。私有方法利用斷言assertion檢查參數。

39、必要時進行保護性拷貝

假設類的客戶端會盡其所能來破壞這個類的約束條件，因此你必須保護性的設計程序。以下是一個不可變類的設計。

public?Period(Date?start,?Date?end){this.start??=?new?Date(start);????????//?使用了值的拷貝，沒有使用原對象（指針）this.end?=?new?Date(end);if(this.start.compareTo(this.end)>0)throw?new?IllegalArgumentException(start?+?"?after?"?+?end) }

注意：保護性拷貝是在檢查參數之前進行的，防止多線程的影響。不要使用clone方法進行保護性拷貝。

以上方法防御了傳入參數的修改，但是對于get方法獲取到的對象，仍然可以被修改，通過以下方法可以防止這種攻擊。

public?Date?start(){return?new?Date(start); }public?Date?end(){return?new?Date(end); }

40、謹慎設計方法簽名

41、慎用重載

42、慎用可變參數

43、返回0長度的數組或者集合，而不是null

null一般用于表示沒有被初始化或處理，如果方法返回了null，則需要在上層做更多的處理，以防止NPE。

44、為所有導出的API元素編寫文檔注釋

正確的javadoc文檔，需要每個被導出的類、接口、構造器、方法和域之前增加文檔注釋。注釋應該是對實現透明的，只需要簡潔的描述它和客戶端之間的約定。并且，還應該附上該方法的副作用。

45、將局部變量的作用域最小化

46、for-each優先于for循環

for-each規避掉了for循環的index變量的引用，通常來說它是不必要的——會增加引入錯誤的風險，并且風險一旦發生，很難被發現。不過有三種情況下，無法使用for-each（注：在jdk1.8中已經很好的解決了這些問題）。

• 過濾

• 轉換

• 平行迭代

48、如果需要精確的答案，請避免使用float和double

float和double是執行的二進制浮點運算，目的是在廣泛數值范圍上使用精確的快速近似計算而設計的。然而他們并沒有提供完全精確的計算（實際應用中，經常會碰到出現x.99999等結果）。尤其是，在進行貨幣計算時，他們并不適用。比如：

System.out.println(1.03-.42);

得到的結果將是：0.610000000001。

為了解決這個問題，需要使用BigDecimal。然而這也有一些問題，相對于普通的運算，它顯得更加麻煩，而且也更慢。通常來說后一個缺點可以忽略，但是前者可能會讓人很不舒服。有一種做法是將需要處理的數值*10(或更多），使用int進行計算，不過需要你自己處理四舍五入等操作。

49、基本類型優先于裝箱基本類型

• 基本類型只有值，裝箱類具有與他們值不同的同一性。

• 基本類型只有功能完備的值，裝箱類還具有非功能值：null。所以你可能會碰到NPE

• 基本類型省空間省時間

50、如果有更精確的類型，請避免使用字符串

• 字符串不適合代替其他值的類型。例如：int，boolean等

• 不適合代替枚舉類型（第30條）

• 不適合聚集類型

51、當心字符串連接的性能

操作符“+”可以將多個字符串進行連接。但是在大規模使用“+”的情況下，連接n個字符串的開銷是n的平房級時間。這是由于字符串的不可變性導致的。在這種情況下請使用StringBuilder進行連接。

52、通過接口引用對象

53、接口優先于反射機制

使用反射機制會帶來以下的問題：

• 喪失了編譯期類型檢查

• 代碼笨拙冗長

• 性能損失

反射基本上只適合用在編寫組件時、代碼分析器、RPC等場景下使用。在使用反射機制時，如果可能，盡可能只通過反射機制實例化對象，而訪問方法時，使用已知的接口或者超類。

54、謹慎使用JNI

55、謹慎進行優化

很多計算上的過失都被歸咎于效率（沒有必要達到的效率），而不是任何其他原因——甚至包括盲目的做傻事。

——William A. Wulf

不要去計較效率上的一些小小的得失，在97%的情況下，不成熟的優化才是一切問題的根源。

——Donald E. Knuth

在優化方面，我們應該遵守兩條規則：

規則1:不要進行優化。

規則2（僅針對專家）：還是不要進行優化——也就是說，在你還沒有絕對清晰的優化方案前，請不要進行優化。

——M. A. Jackson

這些格言比java的出現還要早20年。他們講述了一個關于優化的深刻事實：優化的弊大于利。

要努力編寫好的程序，而不是快的程序。低耦合的重要性遠遠大于性能。當程序編寫得足夠低耦合后，通過工具發現了性能瓶頸的代碼塊，才可以保證對其的修改不影響任何外部環境。

56、遵守普遍的命名規則

57、只針對異常情況才使用異常

不要嘗試通過異常機制來做正常代碼應該做的事情，比如，檢查數組下標。

jvm很少對異常進行優化，因為它只用于不正常的情況。并且，如果你將代碼放入try-catch代碼塊，jvm就喪失了本來可以對它進行的優化。

58、對于可恢復的情況使用受檢異常，對于編程錯誤的情況使用運行時異常

• 如果期望調用者適當的恢復，則需要使用受檢異常，強迫調用者食用try-catch代碼塊，或者將他們拋出去

• 當調用發生前提違例——違反約定的情況時，使用運行時異常，這個時候程序已經無法再執行下去了。例如調用數組的-1索引。

59、避免不必要的受檢異常

往期推薦

報告老板：這次的緩存事故是這樣的...

面試官：你說說互斥鎖、自旋鎖、讀寫鎖、悲觀鎖、樂觀鎖的應用場景？

2萬字，看完這篇才敢說自己真的懂線程池！

關注我，每天陪你進步一點點！

總結

以上是生活随笔為你收集整理的Java中不可或缺的59个小技巧，贼好用！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。