深入了解Java中的不可變對象
不可變對象想必大部分朋友都不陌生，大家在平時寫代碼的過程中100%會使用到不可變對象，比如最常見的String對象、包裝器對象等，那麼到底為何Java語言要這麼設計，真正意圖和考慮點是什麼？可能一些朋友沒有細想過這些問題，今天我們就來聊聊跟不可變對象有關的話題。
以下是本文目錄大綱：
一.什麼是不可變對象
二.深入了解不可變性
三.如何建立不可變對象
四.不可變對象真的"完全不可改變"嗎？
若有不正之處，希望諒解并歡迎批評指正。
請尊重作者勞動成果，轉載請标明原文連結：
https://www.cnblogs.com/dolphin0520/p/10693891.html
一.什麼是不可變對象
下面是《Effective Java》這本書對于不可變對象的定義：
不可變對象(Immutable Object)：對象一旦被建立後，對象所有的狀态及屬性在其生命周期内不會發生任何變化。 從不可變對象的定義來看，其實比較簡單，就是一個對象在建立後，不能對該對象進行任何更改。比如下面這段代碼：
public class ImmutableObject {
private int value;
public ImmutableObject(int value) {
this.value = value;
}
public int getValue() {
return this.value;
}
}
由于ImmutableObject不提供任何setter方法，并且成員變量value是基本資料類型，getter方法傳回的是value的拷貝，是以一旦ImmutableObject執行個體被建立後，該執行個體的狀态無法再進行更改，是以該類具備不可變性。
再比如我們平時用的最多的String：
public class Test {
public static void main(String[] args) {
String str = "I love java";
String str1 = str;
System.out.println("after replace str:" + str.replace("java", "Java"));
System.out.println("after replace str1:" + str1);
}
}
輸出結果：
從輸出結果可以看出，在對str進行了字元串替換替換之後，str1指向的字元串對象仍然沒有發生變化。
二.深入了解不可變性
我們是否考慮過一個問題：假如Java中的String、包裝器類設計成可變的ok麼？如果String對象可變了，會帶來哪些問題？
我們這一節主要來聊聊不可變對象存在的意義。
1）讓并發程式設計變得更簡單
說到并發程式設計，可能很多朋友都會覺得最苦惱的事情就是如何處理共享資源的互斥通路，可能稍不留神，就會導緻代碼上線後出現莫名其妙的問題，并且大部分并發問題都不是太容易進行定位和複現。是以即使是非常有經驗的程式員，在進行并發程式設計時，也會非常的小心，内心如履薄冰。
大多數情況下，對于資源互斥通路的場景，都是采用加鎖的方式來實作對資源的串行通路，來保證并發安全，如synchronize關鍵字，Lock鎖等。但是這種方案最大的一個難點在于：在進行加鎖和解鎖時需要非常地慎重。如果加鎖或者解鎖時機稍有一點偏差，就可能會引發重大問題，然而這個問題Java編譯器無法發現，在進行單元測試、內建測試時可能也發現不了，甚至程式上線後也能正常運作，但是可能突然在某一天，它就莫名其妙地出現了。
既然采用串行方式來通路共享資源這麼容易出現問題，那麼有沒有其他辦法來解決呢？
事實上，引起線程安全問題的根本原因在于：多個線程需要同時通路同一個共享資源。
假如沒有共享資源，那麼多線程安全問題就自然解決了，Java中提供的ThreadLocal機制就是采取的這種思想。
然而大多數時候，線程間是需要使用共享資源互通資訊的，如果共享資源在建立之後就完全不再變更，如同一個常量，而多個線程間并發讀取該共享資源是不會存線上上安全問題的，因為所有線程無論何時讀取該共享資源，總是能擷取到一緻的、完整的資源狀态。
不可變對象就是這樣一種在建立之後就不再變更的對象，這種特性使得它們天生支援線程安全，讓并發程式設計變得更簡單。
我們來看一個例子，這個例子來源于：http://ifeve.com/immutable-objects/
public class SynchronizedRGB {
private int red; // 顔色對應的紅色值
private int green; // 顔色對應的綠色值
private int blue; // 顔色對應的藍色值
private String name; // 顔色名稱
private void check(int red, int green, int blue) {
if (red < 0 || red > 255 || green < 0 || green > 255
|| blue < 0 || blue > 255) {
throw new IllegalArgumentException();
}
}
public SynchronizedRGB(int red, int green, int blue, String name) {
check(red, green, blue);
this.red = red;
this.green = green;
this.blue = blue;
this.name = name;
}
public void set(int red, int green, int blue, String name) {
check(red, green, blue);
synchronized (this) {
this.red = red;
this.green = green;
this.blue = blue;
this.name = name;
}
}
public synchronized int getRGB() {
return ((red << 16) | (green << 8) | blue);
}
public synchronized String getName() {
return name;
}
}
例如一個有個線程1執行了以下代碼：
SynchronizedRGB color = new SynchronizedRGB(0, 0, 0, "Pitch Black");
int myColorInt = color.getRGB(); // Statement1
String myColorName = color.getName(); // Statement2
然後有另外一個線程2在Statement 1之後、Statement 2之前調用了color.set方法：
color.set(0, 255, 0, "Green");
那麼線上程1中變量myColorInt的值和myColorName的值就會不比對。為了避免出現這樣的結果，必須要像下面這樣把這兩條語句綁定到一塊執行：
synchronized (color) {
int myColorInt = color.getRGB();
String myColorName = color.getName();
}
假如SynchronizedRGB是不可變類，那麼就不會出現這個問題，比如将SynchronizedRGB改成下面這種實作方式：
public class ImmutableRGB {
private int red;
private int green;
private int blue;
private String name;
private void check(int red, int green, int blue) {
if (red < 0 || red > 255 || green < 0 || green > 255
|| blue < 0 || blue > 255) {
throw new IllegalArgumentException();
}
}
public ImmutableRGB(int red, int green, int blue, String name) {
check(red, green, blue);
this.red = red;
this.green = green;
this.blue = blue;
this.name = name;
}
public ImmutableRGB set(int red, int green, int blue, String name) {
return new ImmutableRGB(red, green, blue, name);
}
public int getRGB() {
return ((red << 16) | (green << 8) | blue);
}
public String getName() {
return name;
}
}
由于set方法并沒有改變原來的對象，而是新建立了一個對象，是以無論線程1或者線程2怎麼調用set方法，都不會出現并發通路導緻的資料不一緻的問題。
2）消除副作用
很多時候一些很嚴重的bug是由于一個很小的副作用引起的，并且由于副作用通常不容易被察覺，是以很難在編寫代碼以及代碼review過程中發現，并且即使發現了也可能會花費很大的精力才能定位出來。
舉個簡單的例子：
class Person {
private int age; // 年齡
private String identityCardID; // 身份證号碼
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
public String getIdentityCardID() {
return identityCardID;
}
public void setIdentityCardID(String identityCardID) {
this.identityCardID = identityCardID;
}
}
public class Test {
public static void main(String[] args) {
Person jack = new Person();
jack.setAge(101);
jack.setIdentityCardID("42118220090315234X");
System.out.println(validAge(jack));
// 後續使用可能沒有察覺到jack的age被修改了
// 為後續埋下了不容易察覺的問題
}
public static boolean validAge(Person person) {
if (person.getAge() >= 100) {
person.setAge(100); // 此處産生了副作用
return false;
}
return true;
}
}
validAge函數本身隻是對age大小進行判斷，但是在這個函數裡面有一個副作用，就是對參數person指向的對象進行了修改，導緻在外部的jack指向的對象也發生了變化。
如果Person對象是不可變的，在validAge函數中是無法對參數person進行修改的，進而避免了validAge出現副作用，減少了出錯的機率。
3）減少容器使用過程出錯的機率
我們在使用HashSet時，如果HashSet中元素對象的狀态可變，就會出現元素丢失的情況，比如下面這個例子：
class Person {
private int age; // 年齡
private String identityCardID; // 身份證号碼
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
public String getIdentityCardID() {
return identityCardID;
}
public void setIdentityCardID(String identityCardID) {
this.identityCardID = identityCardID;
}
@Override
public boolean equals(Object obj) {
if (obj == null) {
return false;
}
if (!(obj instanceof Person)) {
return false;
}
Person personObj = (Person) obj;
return this.age == personObj.getAge() && this.identityCardID.equals(personObj.getIdentityCardID());
}
@Override
public int hashCode() {
return age * 37 + identityCardID.hashCode();
}
}
public class Test {
public static void main(String[] args) {
Person jack = new Person();
jack.setAge(10);
jack.setIdentityCardID("42118220090315234X");
Set<Person> personSet = new HashSet<Person>();
personSet.add(jack);
jack.setAge(11);
System.out.println(personSet.contains(jack));
}
}
輸出結果：
是以在Java中，對于String、包裝器這些類，我們經常會用他們來作為HashMap的key，試想一下如果這些類是可變的，将會發生什麼？後果不可預知，這将會大大增加Java代碼編寫的難度。
三.如何建立不可變對象
通常來說，建立不可變類原則有以下幾條：
1）所有成員變量必須是private
2）最好同時用final修飾(非必須)
3）不提供能夠修改原有對象狀态的方法
-
- 最常見的方式是不提供setter方法
- 如果提供修改方法，需要新建立一個對象，并在新建立的對象上進行修改
4）通過構造器初始化所有成員變量，引用類型的成員變量必須進行深拷貝(deep copy)
5）getter方法不能對外洩露this引用以及成員變量的引用
6）最好不允許類被繼承(非必須)
JDK中提供了一系列方法友善我們建立不可變集合，如：
Collections.unmodifiableList(List<? extends T> list)
另外，在Google的Guava包中也提供了一系列方法來建立不可變集合，如：
ImmutableList.copyOf(list)
這2種方式雖然都能建立不可變list，但是兩者是有差別的，JDK自帶提供的方式實際上建立出來的不是真正意義上的不可變集合，看unmodifiableList方法的實作就知道了：
可以看出，實際上UnmodifiableList是将入參list的引用複制了一份，同時将所有的修改方法抛出UnsupportedOperationException。是以如果在外部修改了入參list，實際上會影響到UnmodifiableList，而Guava包提供的ImmutableList是真正意義上的不可變集合，它實際上是對入參list進行了深拷貝。看下面這段測試代碼的結果便一目了然：
public class Test {
public static void main(String[] args) {
List<Integer> list = new ArrayList<Integer>();
list.add(1);
System.out.println(list);
List unmodifiableList = Collections.unmodifiableList(list);
ImmutableList immutableList = ImmutableList.copyOf(list);
list.add(2);
System.out.println(unmodifiableList);
System.out.println(immutableList);
}
}
四.不可變對象真的"完全不可改變"嗎？
不可變對象雖然具備不可變性，但是不是"完全不可變"的，這裡打上引号是因為通過反射的手段是可以改變不可變對象的狀态的。
大家看到這裡可能有疑惑了，為什麼既然能改變，為何還叫不可變對象？這裡面大家不要誤會不可變的本意，從不可變對象的意義分析能看出來對象的不可變性隻是用來輔助幫助大家更簡單地去編寫代碼，減少程式編寫過程中出錯的機率，這是不可變對象的初衷。如果真要靠通過反射來改變一個對象的狀态，此時編寫代碼的人也應該會意識到此類在設計的時候就不希望其狀态被更改，進而引起編寫代碼的人的注意。下面是通過反射方式改變不可變對象的例子：
public class Test {
public static void main(String[] args) throws Exception {
String s = "Hello World";
System.out.println("s = " + s);
Field valueFieldOfString = String.class.getDeclaredField("value");
valueFieldOfString.setAccessible(true);
char[] value = (char[]) valueFieldOfString.get(s);
value[5] = '_';
System.out.println("s = " + s);
}
}
參考文章：
http://ifeve.com/immutable-objects/
作者：Matrix海子
出處：http://www.cnblogs.com/dolphin0520/
本部落格中未标明轉載的文章歸作者Matrix海子和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。