java 不可變類型

1. java不可變性初探

我們先看下面一個例子：代碼如下:

    import java.math.BigInteger;  
    public class BigProblem {  
        public static void main(String[ ] args) {  
            BigInteger fiveThousand  = new BigInteger("5000");  
            BigInteger fiftyThousand = new BigInteger("50000");  
            BigInteger fiveHundredThousand = new BigInteger("500000");  
            BigInteger total = BigInteger.ZERO;  
            total.add(fiveThousand);  
            total.add(fiftyThousand);  
            total.add(fiveHundredThousand);  
            System.out.println(total);  
        }  
    }

你可能會認為這個程序會打印出555000。畢竟，它將total設置為用BigInteger表示的0，然后將5,000、50,000和500,000加到了這個變量上。如果你運行該程序，你就會發現它打印的不是555000，而是0。很明顯，所有這些加法對total沒有產生任何影響。

對此有一個很好理由可以解釋：BigInteger實例是不可變的。String、BigDecimal以及包裝器類型：Integer、Long、Short、Byte、Character、Boolean、Float和Double也是如此，你不能修改它們的值。我們不能修改現有實例的值，對這些類型的操作將返回新的實例。起先，不可變類型看起來可能很不自然，但是它們具有很多勝過與其向對應的可變類型的優勢。不可變類型更容易設計、實現和使用；它們出錯的可能性更小，並且更加安全[EJ Item 13]。

為了在一個包含對不可變對象引用的變量上執行計算，我們需要將計算的結果賦值給該變量。這樣做就會產生下面的程序，它將打印出我們所期望的555000, 代碼如下:

 

 1     import java.math.BigInteger;  
 2     public class BigProblem {  
 3         public static void main(String[] args) {  
 4             BigInteger fiveThousand  = new BigInteger("5000");  
 5             BigInteger fiftyThousand = new BigInteger("50000");  
 6             BigInteger fiveHundredThousand = new BigInteger("500000");  
 7             BigInteger total = BigInteger.ZERO;  
 8             total = total.add(fiveThousand);  
 9             total = total.add(fiftyThousand);  
10             total = total.add(fiveHundredThousand);  
11             System.out.println(total);  
12         }  
13     }

2.String不可變性實現分析

根據JDK中java.lang.String的源碼進行分析，從中可以得出String類型的對象不可變的原因，大致上有如下兩個：
1、java.lang.String類型在實現時，其內部成員變量全部使用final來修飾，保證成員變量的引用值只能通過構造函數來修改；
2、java.lang.String類型在實現時，在外部可能修改其內部存儲值的函數實現中，返回時一律構造新的String對象或者新的byte數組或者char數組；
第2的重要性在於，假如通過String類型的toCharArray方法可以直接訪問String類型內部定義的char數組，那么即便String類型內部的char數組使用了final來修飾，也僅僅保證這個成員變量的引用不可變，而無法保證引用指向的內存區域不可變。由上述兩點，保證外部不可能修改java.lang.String類型對象的內部屬性，從而保證String對象是不可變的。
提到String，就不得不提一下JDK中存在另外兩個常用來表示字符串的類，StringBuffer和StringBuilder。根據注釋，StringBuffer可謂老資格了，從JDK1.0時即伴隨Java征戰世界，而StringBuilder直到JDK1.5時才出現。
面試時，StringBuffer和StringBuilder的區別也是常問的話題，有些沒有開發經驗，對多線程編碼不了解、對synchronized的使用不熟悉的兄弟，很容易在這個問題上吃虧。
StringBuffer和StringBuilder的共同點：
1、都是可變對象，對象內的字符緩存會隨着拼接操作而動態擴展；
2、用來完成字符串拼接操作；
3、構造時傳入內部緩存大小時，可以降低緩存擴展的次數，明顯提升字符串拼接操作的效率；
StringBuffer和StringBuilder的區別：
1、StringBuilder的方法都是線程不安全的，從另外一個角度講，StringBuilder類型的對象在做字符串拼接操作時，由於少了線程同步的操作，執行效率上有很大提升；
2、StringBuffer的方法都加上了synchronized關鍵字，因而在一定的場景下，StringBuffer類型的對象都是線程安全的，但在執行效率上，由於多了線程同步的操作，因而會有少許的損失；
在大多數場景下，字符串拼接操作都是不需要考慮多線程環境下對結果的影響的，因而使用StringBuilder類型可以提升代碼的執行效率。
在多個線程的代碼中共享同一個StringBuffer類型的對象時，需要關注synchronized關鍵字對最終結果的影響。由於StringBuffer類的實現中，僅僅對每個方法使用了synchronized修飾，這只能保證在多線程場景下，訪問StringBuffer對象的同一個方法時可以保證最終結果的一致性，假如一個線程訪問A方法，另外一個線程方法B方法，則由於加鎖對象的不同，可能會出現不一致的現象，這是需要程序員特別要注意的地方。類似的，可以參考Vector的實現和應用場景。

3.String不可變性的好處

最流行的Java面試題之一就是：什么是不可變對象(immutable object)，不可變對象有什么好處，在什么情況下應該用，或者更具體一些，Java的String類為什么要設成immutable類型？
不可變對象，顧名思義就是創建后不可以改變的對象，典型的例子就是Java中的String類。

 代碼如下:

String s = "ABC";  
s.toLowerCase();

如上s.toLowerCase()並沒有改變“ABC“的值，而是創建了一個新的String類“abc”，然后將新的實例的指向變量s。

相對於可變對象，不可變對象有很多優勢：
1).不可變對象可以提高String Pool的效率和安全性。如果你知道一個對象是不可變的，那么需要拷貝這個對象的內容時，就不用復制它的本身而只是復制它的地址，復制地址（通常一個指針的大小）需要很小的內存效率也很高。對於同時引用這個“ABC”的其他變量也不會造成影響。
2).不可變對象對於多線程是安全的，因為在多線程同時進行的情況下，一個可變對象的值很可能被其他進程改變，這樣會造成不可預期的結果，而使用不可變對象就可以避免這種情況。
當然也有其他方面原因，但是Java把String設成immutable最大的原因應該是效率和安全。

 

答案二：

這是一個老生常談的話題(This is an old yet still popular question). 在Java中將String設計成不可變的是綜合考慮到各種因素的結果,想要理解這個問題,需要綜合內存,同步,數據結構以及安全等方面的考慮. 在下文中,我將為各種原因做一個小結。

1. 字符串常量池的需要

字符串常量池(String pool, String intern pool, String保留池) 是Java堆內存中一個特殊的存儲區域, 當創建一個String對象時,假如此字符串值已經存在於常量池中,則不會創建一個新的對象,而是引用已經存在的對象。
如下面的代碼所示,將會在堆內存中只創建一個實際String對象. 代碼如下:

String s1 = "abcd";  
String s2 = "abcd";  

 

示意圖如下所示:

 

假若字符串對象允許改變,那么將會導致各種邏輯錯誤,比如改變一個對象會影響到另一個獨立對象. 嚴格來說，這種常量池的思想,是一種優化手段.

請思考: 假若代碼如下所示，s1和s2還會指向同一個實際的String對象嗎? 代碼如下:

String s1= "ab" + "cd";  
String s2= "abc" + "d";  

 

也許這個問題違反新手的直覺, 但是考慮到現代編譯器會進行常規的優化, 所以他們都會指向常量池中的同一個對象. 或者,你可以用 jd-gui 之類的工具查看一下編譯后的class文件.

2. 允許String對象緩存HashCode

Java中String對象的哈希碼被頻繁地使用, 比如在hashMap 等容器中。

 

字符串不變性保證了hash碼的唯一性,因此可以放心地進行緩存.這也是一種性能優化手段,意味着不必每次都去計算新的哈希碼. 在String類的定義中有如下代碼:代碼如下:

private int hash;//用來緩存HashCode  

3. 安全性

String被許多的Java類(庫)用來當做參數,例如 網絡連接地址URL,文件路徑path,還有反射機制所需要的String參數等, 假若String不是固定不變的,將會引起各種安全隱患。
假如有如下的代碼:

boolean connect(string s){
    if (!isSecure(s)) { 
throw new SecurityException(); 
}
    // 如果在其他地方可以修改String,那么此處就會引起各種預料不到的問題/錯誤 
    causeProblem(s);
}

總體來說, String不可變的原因包括 設計考慮,效率優化問題,以及安全性這三大方面. 事實上,這也是Java面試中的許多 "為什么" 的答案。

答案三：String類不可變性的好處

String是所有語言中最常用的一個類。我們知道在Java中，String是不可變的、final的。Java在運行時也保存了一個字符串池(String pool)，這使得String成為了一個特別的類。

String類不可變性的好處

1.只有當字符串是不可變的，字符串池才有可能實現。字符串池的實現可以在運行時節約很多heap空間，因為不同的字符串變量都指向池中的同一個字符串。但如果字符串是可變的，那么String interning將不能實現(譯者注：String interning是指對不同的字符串僅僅只保存一個，即不會保存多個相同的字符串。)，因為這樣的話，如果變量改變了它的值，那么其它指向這個值的變量的值也會一起改變。
2.如果字符串是可變的，那么會引起很嚴重的安全問題。譬如，數據庫的用戶名、密碼都是以字符串的形式傳入來獲得數據庫的連接，或者在socket編程中，主機名和端口都是以字符串的形式傳入。因為字符串是不可變的，所以它的值是不可改變的，否則黑客們可以鑽到空子，改變字符串指向的對象的值，造成安全漏洞。
3.因為字符串是不可變的，所以是多線程安全的，同一個字符串實例可以被多個線程共享。這樣便不用因為線程安全問題而使用同步。字符串自己便是線程安全的。
4.類加載器要用到字符串，不可變性提供了安全性，以便正確的類被加載。譬如你想加載java.sql.Connection類，而這個值被改成了myhacked.Connection，那么會對你的數據庫造成不可知的破壞。
5.因為字符串是不可變的，所以在它創建的時候hashcode就被緩存了，不需要重新計算。這就使得字符串很適合作為Map中的鍵，字符串的處理速度要快過其它的鍵對象。這就是HashMap中的鍵往往都使用字符串。
以上就是我總結的字符串不可變性的好處。

4. 例子

package cn.xy.test;
public class StringTest
{
 /**
  * a的值在編譯時就被確定下來，故其值"xy"被放入String的駐留池(駐留池在堆中)並被a指向。
  * b的值在編譯時也被確定，那么b的值在String的駐留池中找是否有等於"xy"的值，有的話也被b指向。
  * 故兩個對象地址一致
  * @return true
  */
 public static Boolean testString1()
 {
  String a = "xy";
  String b = "xy";
  return a == b;
 }
 
 /**
  * b的值在是兩個常量相加，編譯時也被確定。
  * @return true
  */
 public static Boolean testString2()
 {
  String a = "xyy";
  String b = "xy" + "y";
  return a == b;
 }
 /**
  * b的值為一個變量和一個常量相加，無法編譯時被確定,而是會在堆里新生成一個值為"abc"的對象
  * @return false
  */
 public static Boolean testString3()
 {
  String a = "xyy";
  String b = "xy";
  b = b + "y";
  return a == b;
 }
 
 /**
  * b的值都無法編譯時被確定,而是會在堆里分別新生成一個對象叫"xyy"。
  * @return false
  */
 public static Boolean testString4()
 {
  String a = "xyy";
  String b = "xy".concat("y");
  return a == b;
 }
 
 /**
  * new String()創建的字符串不是常量，不能在編譯期就確定，所以new String() 創建的字符串不放入常量池中，它們有自己的地址空間。 
  * a,b的值都無法編譯時被確定,會在堆里分別新生成一個值為"xy"的對象。
  * @return fasle
  */
 public static Boolean testString5()
 {
  String a = new String("xy");
  String b = new String("xy");
  return a == b;
 }
 /**
  * intern()把駐留池中"xy"的引用賦給b。
  * @return true
  */
 public static Boolean testString6()
 {
  String a = "xy";
  String b = new String("xy");
  b = b.intern();
  return a == b.intern();
 }
 
 /**
  * char的toString方法返回的是一個char對象的字符串，而不是我們想象的"xy"
  * @return false
  */
 public static Boolean testString7()
 {
  String b = "xy";
  char[] a = new char[]{'x','y'};
  return a.toString().equals(b);
 }
 

 /**
  * char是一種新的類型，不存在駐留池的概念。
  * @return fasle
  */
 public static Boolean testString8()
 {
  String b = "xy";
  char[] a = new char[]{'x','y'};
  return a.toString() == b;
 }
 
/**
  * String不可變性的體現
  */
 String str = "xy";
 public String chage(String str)
 {
  str = "xyy";
  return str;
 }
 
 /**
  * 一般引用類型的可變性(傳值的時候把地址傳過去，相當於把倉庫的要是交給方法，方法拿到鑰匙去移動倉庫里的東西)
  */
 Person p = new Person("xy");
 public String changePerson(Person p)
 {
  p.setName("xyy");
  return p.toString();
 }
 public static void main(String[] args)
 {
  print(testString1()); // true
  print(testString2()); // true
  print(testString3()); // fasle
  print(testString4()); // false
  print(testString5()); // false
  print(testString6()); // true
  print(testString7()); // false
  print(testString8()); // false
  StringTest t = new StringTest();
  print(t.str); // xy
  print(t.chage(t.str)); // xxy
  print(t.str); // xy
  print(t.p.toString()); //xy
  print(t.changePerson(t.p)); //xyy
  print(t.p.toString()); //xyy
 }
 
 public static void print(Object o)
 {
  System.out.println(o);
 }
}

參考：

http://www.jb51.net/article/37889.htm

http://www.jb51.net/article/49092.htm

http://blog.csdn.net/woshixuye/article/details/8088453