不可變類只是其例項不能被修改的類。每個例項中包含的所有資訊都必須在建立該例項的時候就提供，並在物件的整個生命週期（lifetime）內固定不變。Java平臺類庫中包含許多不可變的類，其中有String、基本型別的包裝類、BigInteger和BigDecimal。存在不可變的類有許多理由：不可變的類比可變的淚更加易於設計、實現和使用。他們不容易出錯，且更加安全。

為了使類成為不可變，要遵循下面五條規則：

1、不要提供任何會修改物件狀態的方法（也稱為mutator），即改變物件屬性的方法。

2、保證類不會被擴充套件。這樣可以防止粗心或者惡意的子類假裝物件的狀態已經改變，從而破壞該類的不可變行為。為了防止子類化，一般做法是使這個類成為final的。

3、使所有的域都是final的。通過系統的強制方式，這可以清楚地表明你的意圖。而且，如果一個指向新建立例項的引用在缺乏同步機制的情況下，從一個執行緒被傳遞到另一個執行緒，就必須確保正確的行為。

4、使所有的域都成為私有的。這樣可以防止客戶端獲得訪問被域引用的可變物件的許可權，並防止客戶端直接修改這些物件。雖然從技術上講，允許不可變的類具有公有的final域，只要這些域包含基本型別的值或者指向不可變物件的引用，但是不建議這樣做，因為這樣會使得在以後的版本中無法再改變內部的表示法。

5、確保對於任何可變元件的互斥訪問。如果類具有指向可變物件的域，則必須確保該類的客戶端無法獲得指向這些物件的引用。並且，永遠不要用客戶端提供的物件引用初始化這樣的域，也不要從任何訪問方法（accessor）中返回該物件引用。在構造器、訪問方法和readObject中請使用保護性拷貝（defensive copy）技術。

大多數重要的不可變類都使用了函式的（functional）做法，因為這些方法返回了一個函式的結果，這些函式對運算元進行運算但並不修改他。與之相對應的更常見的是過程的（procedural）或者命令式的（imperative）做法，使用這些方式時，將一個過程作用在它的運算元上，會導致它的狀態發生改變。

不可變物件比較簡單。不可變物件可以只有一種狀態，即被建立時的狀態。如果你能夠確保所有的構造器都建立了這個類的約束關係，就可以確保這些約束關係在整個生命週期內永遠不再發生變化，你和使用這個類的程式設計師都無需再做額外的工作來維護這些約束關係。另一方面，可變的物件可以有任意複雜的狀態空間。如果文件中沒有對mutator方法所執行的狀態轉換提供精確地描述，要可靠地使用一個可變類是非常困難的，甚至是不可能的。

不可變物件本質上是執行緒安全的，他們不要求同步。當多個執行緒併發訪問這樣的物件時，他們不會遭到破壞。這無疑是獲得執行緒安全最容易的辦法。實際上，沒有任何執行緒會注意到其他執行緒對於不可變物件的影響。所以，不可變物件可以被自由地共享。不可變類應該充分利用這種優勢，鼓勵客戶端儘可能地重用現有的例項。要做到這一點，一個很簡單的辦法就是，對於頻繁使用的值，為他們提供公有的靜態final常量。

這種方法可以被進一步擴充套件。不可變的類可以提供一些靜態工廠，他們把頻繁被請求的例項快取起來，從而當現有例項可以符合請求的時候，就不必建立新的例項。所有基本型別的包裝類和BigInteger都有這樣的靜態工廠。使用這樣的靜態工廠也使得客戶端之間可以共享現有的例項，而不用建立新的例項，從而降低記憶體佔用和垃圾回收的成本。在設計新的類時，選擇用靜態工廠代替公有的構造器可以讓你以後有新增快取的靈活性，而不必影響客戶端。

“不可變物件可以被自由的共享”導致的結果是，永遠也不需要進行保護性拷貝。實際上，你根本不需做任何拷貝，因為這些拷貝始終等於原始的物件。因此，你不需要也不應該為不可變的類提供clone方法或者拷貝構造器（copy constructor）。

不僅可以共享不可變物件，甚至也可以共享他們的內部資訊，例如BigInteger類內部使用了符號數值表示法。符號用一個int型別的值來表示，數值則用一個int陣列表示。negate方法產生一個新的BigInteger，其中數值是一樣的，符號則是相反的。他並不需要拷貝陣列；新建的BigInteger也指向原始例項中的同一個內部陣列。

不可變物件為其他物件提供了大量的構件（building blocks），無論是可變的還是不可變的物件，如果知道一個複雜物件內部的元件物件不會改變，要維護他的不變性約束是比較容易的。這條原則的一種特例在於，不可變物件構成了大量的對映鍵（map key）和集合元素（set element）；一旦不可變物件進入到對映（map）或者集合（set）中，儘管這破壞了對映或者集合的不變性約束，但是也不用擔心他們的值會發生變化。

不可變類真正唯一的缺點是，對於每個不同的值都需要一個單獨的物件，建立這種物件的代價可能很高，特別是對於大型物件的情形。

如果你執行一個多步驟的操作，並且每個步驟都會產生一個新的物件，除了最後的結果之外其他的物件最終都會被丟棄，此時效能問題就會顯露出來。處理這種問題有兩種辦法。第一種辦法，先猜測一下會經常用到哪些多步驟的操作，然後將他們作為基本型別提供。如果某個多步驟操作已經作為基本型別提供，不可變的類就可以不必在每個步驟單獨建立一個物件。不可變的類在內部可以更加靈活。例如，BigInteger有一個包級私有的可變“配套類（companing class）”，它的用途是加速諸如“模指數（modular exponentiation）”這樣的多步驟操作。

如果能夠精確地預測出客戶端將要在不可變的類上執行哪些複雜的多階段操作，這種包級私有的可變配套類的方法就可以工作的很好。如果無法預測，最好的辦法是提供一個公有的可變配套類。在Java平臺類庫中，這種方法的主要例子是String類，它的可變配套類時StringBuilder（和基本上已經廢棄的StringBuffer）。

除了“使類成為final的”這種方法之外，還有另外一種更加靈活的方法可以做到這一點。讓不可變的類變成final的另一種辦法就是，讓類的所有構造器都變成私有的或者包級私有的，並新增公有的靜態工廠（static factory）來代替公有的構造器。

雖然這種方法並不常用，但它經常是最好的替代方法。它最靈活，因為它允許使用多個包級私有的實現類。對於處在它的包外部的客戶端而言，不可變的類實際上是final的，因為可能把來自另一個包的類，缺少公有的或受保護的構造器的類進行擴充套件。除了允許多個實現類的靈活性之外，這種方法還使得很可能通過改善靜態工廠的物件快取能力，在後續的發行版本中改進該類的效能。

沒有一個方法能夠對物件的狀態產生外部可見（externally visible）的改變。然而，許多不可變的類擁有一個或者多個非final的域，他們在第一次被請求執行這些計算的時候，把一些開銷昂貴的類擁有一個或者多個非final的域，他們在第一次被請求執行這些計算的時候，把一些開銷昂貴的計算結果快取在這些域中。如果將來再次請求同樣地計算，就直接返回這些快取的值，從而解決了重新計算所需要的開銷。這種技巧可以很好地工作，因為物件是不可變的，它的不可變性保證了這些計算如果被再次執行，就會產生同樣地結果。

有關序列化功能的一條告誡有必要在這裡提出來。如果你選擇讓自己的不可變類實現Serializable介面，並且他包含一個或者多個指向可變物件的域，就必須提供一個顯式的readObject或者readResolve方法，或者使用ObjectOutputStream.writeunshared和ObjectInputStream.readUnshared方法，即使預設的序列化形式是可以接受的，也是如此。否則攻擊者可能從不可變的類建立可變的例項。

總之，堅決不要為每個get方法編寫一個相應的set方法。除非有很好地理由要讓類成為可變的淚，否則就應該是不可變的。不可變的類有許多優點，唯一缺點是在特定的情況下存在潛在的效能問題。

對於有些類而言，其不可變性是不切實際的。如果類不能被做成不可變的，仍然應該儘可能地限制他的可變性。降低物件可以存在的狀態數，可以更容易的分析該物件的行為，同時降低出錯的可能性。因此，除非有令人信服的理由要使域變成是非final的，否則要使每個域都是final的。

構造器應該建立完全初始化的物件，並建立其所有的約束關係。不要在構造器或者靜態工廠之外再提供公有的初始化方法，除非有令人信服的理由必須這麼做。同樣地，也不應該提供“重新初始化”方法（它使得物件可以被重用，就好像這個物件是由另一不同的初始狀態構造出來一樣）。與所增加的複雜性相比，“重新初始化”方法通常並沒有帶來太多的效能優勢。

可以通過TimeTask類來說明這些原則。它是可變的，但是他的狀態空間被有意的設計的非常小。你可以建立一個例項，對它進行排程使他執行起來，也可以隨意的取消它。一旦一個定時器任務（time task）已經完成，或者已經被取消，就不可能再對它重新排程。