String和StringBuffer作為方法引數引起的值傳遞和方法傳遞
阿新 • • 發佈：2019-02-12
一、 最開始的示例
寫程式碼最重要的就是實踐，不經過反覆試驗而得出的說辭只能說是憑空遐想罷了。所以，在本文中首先以一個簡單示例來丟擲核心話題：
public class StringAsParamOfMethodDemo {
public static void main(String[] args) {
StringAsParamOfMethodDemo StringAsParamOfMethodDemo =
new StringAsParamOfMethodDemo();
StringAsParamOfMethodDemo.testA();
}
private void testA() {
String originalStr = "original";
System.out.println("Test A Begin:");
System.out.println("The outer String: " + originalStr);
simpleChangeString(originalStr);
System.out.println("The outer String after inner change: " + originalStr);
System.out.println("Test A End.");
System.out.println();
}
public void simpleChangeString(String original) {
original = original + " is changed!";
System.out.println("The changed inner String: " + original);
}
}
這段程式碼的邏輯是這樣的：先賦值一個String型別的區域性變數，然後把這個變數作為引數送進一個方法中，在這個方法中改變該變數的值。編譯執行之後，發現輸出結果是這樣的：
Test A Begin:
The outer String: original
The changed inner String: original is changed!
The outer String after inner change: original
Test A End.
這個結果表明在方法內部對String型別的變數的重新賦值操作並沒有對這個變數的原型產生任何影響。好了，這個示例的邏輯和執行結果都展示清楚了，接下來我們來對這個小程式進行分析。在這之前我們先來回顧下Java中所謂的“傳值”和“傳引用”問題。
二、 Java中的“傳值”和“傳引用”問題
許多初學Java的程式設計師都在這個問題上有所思索，那是因為這是所謂的“C語言的傳值和傳指標問題”在Java語言上同類表現。
最後得出的結論是：
在Java中，當基本型別作為引數傳入方法時，無論該引數在方法內怎樣被改變，外部的變數原型總是不變的，程式碼類似上面的示例：
int number = 0;
changeNumber(number) {number++}; //改變送進的int變數
System.out.println(number); //這時number依然為0
這就叫做“值傳遞”，即方法操作的是引數變數（也就是原型變數的一個值的拷貝）改變的也只是原型變數的一個拷貝而已，而非變數本身。所以變數原型並不會隨之改變。
但當方法傳入的引數為非基本型別時（也就是說是一個物件型別的變數）， 方法改變引數變數的同時變數原型也會隨之改變，程式碼同樣類似上面的示例：
StringBuffer strBuf = new StringBuffer(“original”);
changeStringBuffer(strBuf) {strbuf.apend(“ is changed!”)} //改變送進的StringBuffer變數
System.out.println(strBuf); //這時strBuf的值就變為了original is changed!
這 種特性就叫做“引用傳遞”，也叫做傳址，即方法操作引數變數時是拷貝了變數的引用，而後通過引用找到變數（在這裡是物件）的真正地址，並對其進行操作。當 該方法結束後，方法內部的那個引數變數隨之消失。但是要知道這個變數只是物件的一個引用而已，它只是指向了物件所在的真實地址，而非物件本身，所以它的消 失並不會帶來什麼負面影響。回頭來看原型變數，原型變數本質上也是那個物件的一個引用（和引數變數是一樣一樣的），當初對引數變數所指物件的改變就根本就 是對原型變數所指物件的改變。所以原型變數所代表的物件就這樣被改變了，而且這種改變被儲存了下來。
瞭解了這個經典問題，很多細心的讀者肯定會立刻提出新的疑問：“可是String型別在Java語言中屬於非基本型別啊！它在方法中的改變為什麼沒有被保 存下來呢！”的確，這是個問題，而且這個新疑問幾乎推翻了那個經典問題的全部結論。真是這樣麼？好，現在我們就來繼續分析。
三、 關於String引數傳遞問題的曲解之一——直接賦值與物件賦值
String型別的變數作為引數時怎麼會像基本型別變數那樣以傳值方式傳遞呢？關於這個問題，有些朋友給出過解釋，但可惜並不正確。
一 種解釋就是，對String型別的變數賦值時並沒有new出物件，而是直接用字串賦值，所以Java就把這個String型別的變數當作基本型別看待 了。即，應該String str = new String(“original”);，而不是String str = “original”;。這是問題所在麼？我們來為先前的示例稍微改造下，執行之後看看結果就知道了。改造後的程式碼如下：
private void testB() {
String originalStr = new String("original");
System.out.println("Test B Begin:");
System.out.println("The outer String: " + originalStr);
changeNewString(originalStr);
System.out.println("The outer String after inner change: " + originalStr);
System.out.println("Test B End:");
System.out.println();
}
public void changeNewString(String original) {
original = new String(original + " is changed!");
System.out.println("The changed inner String: " + original);
}
我們來看看這次執行結果是怎麼樣的：
Test B Begin:
The outer String: original
The changed inner String: original is changed!
The outer String after inner change: original
Test B End.
實踐證明，這種說法是錯的。
實際上，字串直接賦值和用new出的物件賦值的區別僅僅在於儲存方式不同。
簡單說明下：
字 符串直接賦值時，String型別的變數所引用的值是儲存在類的常量池中的。因為”original”本身是個字串常量，另一方面String是個不可 變型別，所以這個String型別的變數相當於是滴對一個常量的引用。這種情況下，變數的記憶體空間大小是在編譯期就已經確定的。
而new物件的方式是將”original”儲存到String物件的記憶體空間中，而這個儲存動作是在執行期進行的。在這種情況下，Java並不是把”original”這個字串當作常量對待的，因為這時它是作為建立String物件的引數出現的。
所以對String的賦值方式和其引數傳值問題並沒有直接聯絡。總之，這種解釋並不是正解。
四、 關於String引數傳遞問題的曲解之二——“=”變值與方法變值
又有些朋友認為，變值不同步的問題是處在改變值的方式上。
這 種說法認為：“在Java 中，改變引數的值有兩種情況，第一種，使用賦值號“=”直接進行賦值使其改變；第二種，對於某些物件的引用，通過一定途徑對其成員資料進行改變，如通過對 象的本身的方法。對於第一種情況，其改變不會影響到被傳入該引數變數的方法以外的資料，或者直接說源資料。而第二種方法，則相反，會影響到源資料——因為 引用指示的物件沒有變，對其成員資料進行改變則實質上是改變的該物件。”
這種方式聽起來似乎有些…，我們還是用老辦法，編寫demo，做個小試驗，程式碼如下：
private void testC() {
String originalStr = new String("original");
System.out.println("Test C Begin:");
System.out.println("The outer String: " + originalStr);
changeStrWithMethod(originalStr);
System.out.println("The outer String after inner change: " + originalStr);
System.out.println("Test C End.");
System.out.println();
}
private static void changeStrWithMethod(String original) {
original = original.concat(" is changed!");
System.out.println("The changed inner String: " + original);
}
結果如下：
Test C Begin:
The outer String: original
The changed inner String: original is changed!
The outer String after inner change: original
Test C End.
怎麼樣，這證明了問題並不是出在這，又一個解釋在實踐論據下夭折了。
那到底是什麼原因導致了這種狀況呢？
好了，不賣關子了，下面說下我的解釋。
五、 String引數傳遞問題的癥結所在
其實，要想真正理解一個類或者一個API/框架的最直接的方法就是看原始碼。
下面我們來看看new出String物件的那小段程式碼（String類中），也就是String類的建構函式：
public String(String original) {
int size = original.count;
char[] originalValue = original.value;
char[] v;
if (originalValue.length > size) {
// The array representing the String is bigger than the new
// String itself. Perhaps this constructor is being called
// in order to trim the baggage, so make a copy of the array.
int off = original.offset;
v = Arrays.copyOfRange(originalValue, off, off+size);
} else {
// The array representing the String is the same
// size as the String, so no point in making a copy.
v = originalValue;
}
this.offset = 0;
this.count = size;
this.value = v;
}
也 許你注意到了裡面的char[],這說明對String的儲存實際上通過char[]來實現的。怎麼樣？其實就是一層窗戶紙。不知道大家還記不記得在 Java API中定義的那些基本型別的包裝類。比如Integer是int包裝類、Float是float的包裝類等等。對這些包裝類的值操作實際上都是通過對其 對應的基本型別操作而實現的。是不是有所感悟了？對，String就相當於是char[]的包裝類。包裝類的特質之一就是在對其值進行操作時會體現出其對 應的基本型別的性質。在引數傳遞時，包裝類就是如此體現的。所以，對於String在這種情況下的展現結果的解釋就自然而然得出了。同樣 的，Integer、Float等這些包裝類和String在這種情況下的表現是相同的，具體的分析在這裡就省略了，有興趣的朋友可以自己做做試驗。
這也就是為什麼若組串操作是通過不同方法來實現的時候，推薦大家使用StringBuffer的真正原因了。至於StringBuffer為什麼不會表現出String這種現象，大家再看看的StringBuffer的實現就會明白了，在此也不再贅述了。
六、 寫在最後
由此String型別的引數傳遞問題的原理也就展現出來了。其實可以看出，只要分析方式正確，思考終究得出正確結論的。
正確分析方法的基礎有二：
1、 多實踐：手千萬不要犯懶，實踐必會出真知。
2、 基於原理：搞清楚程式邏輯的最直接最簡單的方式就是看原始碼，這毋庸置疑。
只要基於這兩個基礎進行分析，在很多情況下會達到事半功倍的效果。這算是經驗之談吧，也算是分析程式的“捷徑”方式之一。
寫程式碼最重要的就是實踐，不經過反覆試驗而得出的說辭只能說是憑空遐想罷了。所以，在本文中首先以一個簡單示例來丟擲核心話題：
public class StringAsParamOfMethodDemo {
public static void main(String[] args) {
StringAsParamOfMethodDemo StringAsParamOfMethodDemo =
new StringAsParamOfMethodDemo();
StringAsParamOfMethodDemo.testA();
}
private void testA() {
String originalStr = "original";
System.out.println("Test A Begin:");
System.out.println("The outer String: " + originalStr);
simpleChangeString(originalStr);
System.out.println("The outer String after inner change: " + originalStr);
System.out.println("Test A End.");
System.out.println();
}
public void simpleChangeString(String original) {
original = original + " is changed!";
System.out.println("The changed inner String: " + original);
}
}
這段程式碼的邏輯是這樣的：先賦值一個String型別的區域性變數，然後把這個變數作為引數送進一個方法中，在這個方法中改變該變數的值。編譯執行之後，發現輸出結果是這樣的：
Test A Begin:
The outer String: original
The changed inner String: original is changed!
The outer String after inner change: original
Test A End.
這個結果表明在方法內部對String型別的變數的重新賦值操作並沒有對這個變數的原型產生任何影響。好了，這個示例的邏輯和執行結果都展示清楚了，接下來我們來對這個小程式進行分析。在這之前我們先來回顧下Java中所謂的“傳值”和“傳引用”問題。
二、 Java中的“傳值”和“傳引用”問題
許多初學Java的程式設計師都在這個問題上有所思索，那是因為這是所謂的“C語言的傳值和傳指標問題”在Java語言上同類表現。
最後得出的結論是：
在Java中，當基本型別作為引數傳入方法時，無論該引數在方法內怎樣被改變，外部的變數原型總是不變的，程式碼類似上面的示例：
int number = 0;
changeNumber(number) {number++}; //改變送進的int變數
System.out.println(number); //這時number依然為0
這就叫做“值傳遞”，即方法操作的是引數變數（也就是原型變數的一個值的拷貝）改變的也只是原型變數的一個拷貝而已，而非變數本身。所以變數原型並不會隨之改變。
但當方法傳入的引數為非基本型別時（也就是說是一個物件型別的變數）， 方法改變引數變數的同時變數原型也會隨之改變，程式碼同樣類似上面的示例：
StringBuffer strBuf = new StringBuffer(“original”);
changeStringBuffer(strBuf) {strbuf.apend(“ is changed!”)} //改變送進的StringBuffer變數
System.out.println(strBuf); //這時strBuf的值就變為了original is changed!
這 種特性就叫做“引用傳遞”，也叫做傳址，即方法操作引數變數時是拷貝了變數的引用，而後通過引用找到變數（在這裡是物件）的真正地址，並對其進行操作。當 該方法結束後，方法內部的那個引數變數隨之消失。但是要知道這個變數只是物件的一個引用而已，它只是指向了物件所在的真實地址，而非物件本身，所以它的消 失並不會帶來什麼負面影響。回頭來看原型變數，原型變數本質上也是那個物件的一個引用（和引數變數是一樣一樣的），當初對引數變數所指物件的改變就根本就 是對原型變數所指物件的改變。所以原型變數所代表的物件就這樣被改變了，而且這種改變被儲存了下來。
瞭解了這個經典問題，很多細心的讀者肯定會立刻提出新的疑問：“可是String型別在Java語言中屬於非基本型別啊！它在方法中的改變為什麼沒有被保 存下來呢！”的確，這是個問題，而且這個新疑問幾乎推翻了那個經典問題的全部結論。真是這樣麼？好，現在我們就來繼續分析。
三、 關於String引數傳遞問題的曲解之一——直接賦值與物件賦值
String型別的變數作為引數時怎麼會像基本型別變數那樣以傳值方式傳遞呢？關於這個問題，有些朋友給出過解釋，但可惜並不正確。
一 種解釋就是，對String型別的變數賦值時並沒有new出物件，而是直接用字串賦值，所以Java就把這個String型別的變數當作基本型別看待 了。即，應該String str = new String(“original”);，而不是String str = “original”;。這是問題所在麼？我們來為先前的示例稍微改造下，執行之後看看結果就知道了。改造後的程式碼如下：
private void testB() {
String originalStr = new String("original");
System.out.println("Test B Begin:");
System.out.println("The outer String: " + originalStr);
changeNewString(originalStr);
System.out.println("The outer String after inner change: " + originalStr);
System.out.println("Test B End:");
System.out.println();
}
public void changeNewString(String original) {
original = new String(original + " is changed!");
System.out.println("The changed inner String: " + original);
}
我們來看看這次執行結果是怎麼樣的：
Test B Begin:
The outer String: original
The changed inner String: original is changed!
The outer String after inner change: original
Test B End.
實踐證明，這種說法是錯的。
實際上，字串直接賦值和用new出的物件賦值的區別僅僅在於儲存方式不同。
簡單說明下：
字 符串直接賦值時，String型別的變數所引用的值是儲存在類的常量池中的。因為”original”本身是個字串常量，另一方面String是個不可 變型別，所以這個String型別的變數相當於是滴對一個常量的引用。這種情況下，變數的記憶體空間大小是在編譯期就已經確定的。
而new物件的方式是將”original”儲存到String物件的記憶體空間中，而這個儲存動作是在執行期進行的。在這種情況下，Java並不是把”original”這個字串當作常量對待的，因為這時它是作為建立String物件的引數出現的。
所以對String的賦值方式和其引數傳值問題並沒有直接聯絡。總之，這種解釋並不是正解。
四、 關於String引數傳遞問題的曲解之二——“=”變值與方法變值
又有些朋友認為，變值不同步的問題是處在改變值的方式上。
這 種說法認為：“在Java 中，改變引數的值有兩種情況，第一種，使用賦值號“=”直接進行賦值使其改變；第二種，對於某些物件的引用，通過一定途徑對其成員資料進行改變，如通過對 象的本身的方法。對於第一種情況，其改變不會影響到被傳入該引數變數的方法以外的資料，或者直接說源資料。而第二種方法，則相反，會影響到源資料——因為 引用指示的物件沒有變，對其成員資料進行改變則實質上是改變的該物件。”
這種方式聽起來似乎有些…，我們還是用老辦法，編寫demo，做個小試驗，程式碼如下：
private void testC() {
String originalStr = new String("original");
System.out.println("Test C Begin:");
System.out.println("The outer String: " + originalStr);
changeStrWithMethod(originalStr);
System.out.println("The outer String after inner change: " + originalStr);
System.out.println("Test C End.");
System.out.println();
}
private static void changeStrWithMethod(String original) {
original = original.concat(" is changed!");
System.out.println("The changed inner String: " + original);
}
結果如下：
Test C Begin:
The outer String: original
The changed inner String: original is changed!
The outer String after inner change: original
Test C End.
怎麼樣，這證明了問題並不是出在這，又一個解釋在實踐論據下夭折了。
那到底是什麼原因導致了這種狀況呢？
好了，不賣關子了，下面說下我的解釋。
五、 String引數傳遞問題的癥結所在
其實，要想真正理解一個類或者一個API/框架的最直接的方法就是看原始碼。
下面我們來看看new出String物件的那小段程式碼（String類中），也就是String類的建構函式：
public String(String original) {
int size = original.count;
char[] originalValue = original.value;
char[] v;
if (originalValue.length > size) {
// The array representing the String is bigger than the new
// String itself. Perhaps this constructor is being called
// in order to trim the baggage, so make a copy of the array.
int off = original.offset;
v = Arrays.copyOfRange(originalValue, off, off+size);
} else {
// The array representing the String is the same
// size as the String, so no point in making a copy.
v = originalValue;
}
this.offset = 0;
this.count = size;
this.value = v;
}
也 許你注意到了裡面的char[],這說明對String的儲存實際上通過char[]來實現的。怎麼樣？其實就是一層窗戶紙。不知道大家還記不記得在 Java API中定義的那些基本型別的包裝類。比如Integer是int包裝類、Float是float的包裝類等等。對這些包裝類的值操作實際上都是通過對其 對應的基本型別操作而實現的。是不是有所感悟了？對，String就相當於是char[]的包裝類。包裝類的特質之一就是在對其值進行操作時會體現出其對 應的基本型別的性質。在引數傳遞時，包裝類就是如此體現的。所以，對於String在這種情況下的展現結果的解釋就自然而然得出了。同樣 的，Integer、Float等這些包裝類和String在這種情況下的表現是相同的，具體的分析在這裡就省略了，有興趣的朋友可以自己做做試驗。
這也就是為什麼若組串操作是通過不同方法來實現的時候，推薦大家使用StringBuffer的真正原因了。至於StringBuffer為什麼不會表現出String這種現象，大家再看看的StringBuffer的實現就會明白了，在此也不再贅述了。
六、 寫在最後
由此String型別的引數傳遞問題的原理也就展現出來了。其實可以看出，只要分析方式正確，思考終究得出正確結論的。
正確分析方法的基礎有二：
1、 多實踐：手千萬不要犯懶，實踐必會出真知。
2、 基於原理：搞清楚程式邏輯的最直接最簡單的方式就是看原始碼，這毋庸置疑。
只要基於這兩個基礎進行分析，在很多情況下會達到事半功倍的效果。這算是經驗之談吧，也算是分析程式的“捷徑”方式之一。