最新国产好看的视频,伊人天堂AV在线,国产Aaaaaa视频,蜜臀视频在线观看一区,人妻av色图,密臀久久久精品影片,青青视频免费观看毛片,久草在线观看视,国产三级精品色情在线

簡單談?wù)凧ava中String類型的參數(shù)傳遞問題

 更新時間:2015年12月07日 11:58:27   投稿:hebedich  
這篇文章主要介紹了簡單談?wù)凧ava中String類型的參數(shù)傳遞問題的相關(guān)資料,需要的朋友可以參考下

提要:本文從實現(xiàn)原理的角度上闡述和剖析了:在Java語言中,以 String 作為類型的變量在作為方法參數(shù)時所表現(xiàn)出的“非對象”的特性。

一、最開始的示例

寫代碼最重要的就是實踐,不經(jīng)過反復(fù)試驗而得出的說辭只能說是憑空遐想罷了。所以,在本文中首先以一個簡單示例來拋出核心話題:

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類型的局部變量,然后把這個變量作為參數(shù)送進一個方法中,在這個方法中改變該變量的值。編譯運行之后,發(fā)現(xiàn)輸出結(jié)果是這樣的:

Test A Begin:
The outer String: original
The changed inner String: original is changed!
The outer String after inner change: original
Test A End.

這個結(jié)果表明在方法內(nèi)部對String類型的變量的重新賦值操作并沒有對這個變量的原型產(chǎn)生任何影響。好了,這個示例的邏輯和運行結(jié)果都展示清楚了,接下來我們來對這個小程序進行分析。在這之前我們先來回顧下Java中所謂的“傳值”和“傳引用”問題。

二、Java中的“傳值”和“傳引用”問題

許多初學Java的程序員都在這個問題上有所思索,那是因為這是所謂的“C語言的傳值和傳指針問題”在Java語言上同類表現(xiàn)。

最后得出的結(jié)論是:

在Java中,當基本類型作為參數(shù)傳入方法時,無論該參數(shù)在方法內(nèi)怎樣被改變,外部的變量原型總是不變的,代碼類似上面的示例:

int number = 0; 

changeNumber(number) {number++}; //改變送進的int變量 

System.out.println(number); //這時number依然為0
這就叫做“值傳遞”,即方法操作的是參數(shù)變量(也就是原型變量的一個值的拷貝)改變的也只是原型變量的一個拷貝而已,而非變量本身。所以變量原型并不會隨之改變。

但當方法傳入的參數(shù)為非基本類型時(也就是說是一個對象類型的變量), 方法改變參數(shù)變量的同時變量原型也會隨之改變,代碼同樣類似上面的示例:

StringBuffer strBuf = new StringBuffer(“original”); 

changeStringBuffer(strBuf) {strbuf.apend(“ is changed!”)} //改變送進的StringBuffer變量 

System.out.println(strBuf); //這時strBuf的值就變?yōu)榱薿riginal is changed!   
這種特性就叫做“引用傳遞”,也叫做傳址,即方法操作參數(shù)變量時是拷貝了變量的引用,而后通過引用找到變量(在這里是對象)的真正地址,并對其進行操作。當該方法結(jié)束后,方法內(nèi)部的那個參數(shù)變量隨之消失。但是要知道這個變量只是對象的一個引用而已,它只是指向了對象所在的真實地址,而非對象本身,所以它的消失并不會帶來什么負面影響?;仡^來看原型變量,原型變量本質(zhì)上也是那個對象的一個引用(和參數(shù)變量是一樣一樣的),當初對參數(shù)變量所指對象的改變就根本就是對原型變量所指對象的改變。所以原型變量所代表的對象就這樣被改變了,而且這種改變被保存了下來。

了解了這個經(jīng)典問題,很多細心的讀者肯定會立刻提出新的疑問:“可是String類型在Java語言中屬于非基本類型??!它在方法中的改變?yōu)槭裁礇]有被保存下來呢!”的確,這是個問題,而且這個新疑問幾乎推翻了那個經(jīng)典問題的全部結(jié)論。真是這樣么?好,現(xiàn)在我們就來繼續(xù)分析。

三、關(guān)于String參數(shù)傳遞問題的曲解之一——直接賦值與對象賦值

String類型的變量作為參數(shù)時怎么會像基本類型變量那樣以傳值方式傳遞呢?關(guān)于這個問題,有些朋友給出過解釋,但可惜并不正確。
一種解釋就是,對String類型的變量賦值時并沒有new出對象,而是直接用字符串賦值,所以Java就把這個String類型的變量當作基本類型看待了。即,應(yīng)該String str = new String(“original”);,而不是String str = “original”;。這是問題所在么?我們來為先前的示例稍微改造下,運行之后看看結(jié)果就知道了。改造后的代碼如下:

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); 
   } 

我們來看看這次運行結(jié)果是怎么樣的:

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出的對象賦值的區(qū)別僅僅在于存儲方式不同。

簡單說明下:

字符串直接賦值時,String類型的變量所引用的值是存儲在類的常量池中的。因為original本身是個字符串常量,另一方面String是個不可變類型,所以這個String類型的變量相當于是對一個常量的引用。這種情況下,變量的內(nèi)存空間大小是在編譯期就已經(jīng)確定的。

而new對象的方式是將original存儲到String對象的內(nèi)存空間中,而這個存儲動作是在運行期進行的。在這種情況下,Java并不是把original這個字符串當作常量對待的,因為這時它是作為創(chuàng)建String對象的參數(shù)出現(xiàn)的。

所以對String的賦值方式和其參數(shù)傳值問題并沒有直接聯(lián)系。總之,這種解釋并不是正解。

四、關(guān)于String參數(shù)傳遞問題的曲解之二——“=”變值與方法變值

又有些朋友認為,變值不同步的問題是處在改變值的方式上。

這種說法認為:“在Java 中,改變參數(shù)的值有兩種情況,第一種,使用賦值號“=”直接進行賦值使其改變;第二種,對于某些對象的引用,通過一定途徑對其成員數(shù)據(jù)進行改變,如通過對象的本身的方法。對于第一種情況,其改變不會影響到被傳入該參數(shù)變量的方法以外的數(shù)據(jù),或者直接說源數(shù)據(jù)。而第二種方法,則相反,會影響到源數(shù)據(jù)——因為引用指示的對象沒有變,對其成員數(shù)據(jù)進行改變則實質(zhì)上是改變的該對象?!?/p>

這種方式聽起來似乎有些…,我們還是用老辦法,編寫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); 
}

結(jié)果如下:

Test C Begin:
The outer String: original
The changed inner String: original is changed!
The outer String after inner change: original
Test C End.

怎么樣,這證明了問題并不是出在這,又一個解釋在實踐論據(jù)下夭折了。

那到底是什么原因?qū)е铝诉@種狀況呢?

好了,不賣關(guān)子了,下面說下我的解釋。

五、String參數(shù)傳遞問題的癥結(jié)所在

其實,要想真正理解一個類或者一個API框架的最直接的方法就是看源碼。

下面我們來看看new出String對象的那小段代碼(String類中),也就是String類的構(gòu)造函數(shù):

  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[]來實現(xiàn)的。怎么樣?其實就是一層窗戶紙。不知道大家還記不記得在Java API中定義的那些基本類型的包裝類。比如Integer是int包裝類、Float是float的包裝類等等。對這些包裝類的值操作實際上都是通過對其對應(yīng)的基本類型操作而實現(xiàn)的。是不是有所感悟了?對,String就相當于是char[]的包裝類。包裝類的特質(zhì)之一就是在對其值進行操作時會體現(xiàn)出其對應(yīng)的基本類型的性質(zhì)。在參數(shù)傳遞時,包裝類就是如此體現(xiàn)的。所以,對于String在這種情況下的展現(xiàn)結(jié)果的解釋就自然而然得出了。同樣的,Integer、Float等這些包裝類和String在這種情況下的表現(xiàn)是相同的,具體的分析在這里就省略了,有興趣的朋友可以自己做做試驗。

這也就是為什么當對字符串的操作在通過不同方法來實現(xiàn)的時候,推薦大家使用StringBuffer的真正原因了。至于StringBuffer為什么不會表現(xiàn)出String這種現(xiàn)象,大家再看看的StringBuffer的實現(xiàn)就會明白了,在此也不再贅述了。

六、寫在最后

由此String類型的參數(shù)傳遞問題的原理也就展現(xiàn)出來了。其實可以看出,只要分析方式正確,思考終究得出正確結(jié)論的。
正確分析方法的基礎(chǔ)有二:

1、多實踐:手千萬不要犯懶,實踐必會出真知。

2、基于原理:搞清楚程序邏輯的最直接最簡單的方式就是看源碼,這毋庸置疑。

只要基于這兩個基礎(chǔ)進行分析,在很多情況下會達到事半功倍的效果。這算是經(jīng)驗之談吧,也算是分析程序的“捷徑”方式之一。

相關(guān)文章

  • Java設(shè)置PDF有序和無序列表的知識點總結(jié)

    Java設(shè)置PDF有序和無序列表的知識點總結(jié)

    在本篇文章中小編給大家整理了關(guān)于Java設(shè)置PDF有序和無序列表的知識點,需要的朋友們參考下。
    2019-03-03
  • SpringMVC中轉(zhuǎn)發(fā)與重定向的區(qū)別淺析

    SpringMVC中轉(zhuǎn)發(fā)與重定向的區(qū)別淺析

    這篇文章主要給大家介紹了關(guān)于SpringMVC中轉(zhuǎn)發(fā)與重定向的區(qū)別,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
    2020-12-12
  • JAVA 中的大數(shù)字操作類詳解

    JAVA 中的大數(shù)字操作類詳解

    Java的BigInteger類用于處理超出int和long范圍的大整數(shù),而BigDecimal類則用于高精度的浮點數(shù)運算,這兩個類都是Number的子類,提供了一系列方法執(zhí)行加減乘除等運算,BigInteger不支持表示小數(shù),只能表示整數(shù),BigDecimal可以控制小數(shù)位數(shù)和舍入方式,感興趣的朋友一起看看吧
    2024-10-10
  • Java代碼是如何被CPU狂飆起來的

    Java代碼是如何被CPU狂飆起來的

    無論是剛剛?cè)腴TJava的新手還是已經(jīng)工作了的老司機,恐怕都不容易把Java代碼如何一步步被CPU執(zhí)行起來這個問題完全講清楚。本文就帶你詳細了解Java代碼到底是怎么運行起來的。感興趣的同學可以參考閱讀
    2023-03-03
  • SpringBoot3整合EasyExcel動態(tài)實現(xiàn)表頭重命名

    SpringBoot3整合EasyExcel動態(tài)實現(xiàn)表頭重命名

    這篇文章主要為大家詳細介紹了SpringBoot3整合EasyExcel如何通過WriteHandler動態(tài)實現(xiàn)表頭重命名,文中的示例代碼講解詳細,有需要的可以了解下
    2025-03-03
  • Java使用Scanner類獲取用戶輸入實例詳解

    Java使用Scanner類獲取用戶輸入實例詳解

    在本篇文章里小編給大家整理了關(guān)于Java使用Scanner類獲取用戶輸入實例內(nèi)容,有興趣的朋友們學習下。
    2019-11-11
  • java多線程之Future和FutureTask使用實例

    java多線程之Future和FutureTask使用實例

    這篇文章主要介紹了java多線程之Future和FutureTask使用實例,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧
    2020-09-09
  • Java實現(xiàn)mybatis批量插入數(shù)據(jù)到Oracle

    Java實現(xiàn)mybatis批量插入數(shù)據(jù)到Oracle

    這篇文章主要為大家詳細介紹了Java實現(xiàn)mybatis批量插入數(shù)據(jù)到Oracle 的相關(guān)資料,需要的朋友可以參考下
    2016-06-06
  • Java后端服務(wù)間歇性響應(yīng)慢的問題排查與解決

    Java后端服務(wù)間歇性響應(yīng)慢的問題排查與解決

    之前在公司內(nèi)其它團隊找到幫忙排查的一個后端服務(wù)連接超時問題,問題的表現(xiàn)是服務(wù)部署到線上后出現(xiàn)間歇性請求響應(yīng)非常慢(大于10s),但是后端業(yè)務(wù)分析業(yè)務(wù)日志時卻沒有發(fā)現(xiàn)慢請求,所以本文給大家介紹了Java后端服務(wù)間歇性響應(yīng)慢的問題排查與解決,需要的朋友可以參考下
    2025-03-03
  • 修改SpringBoot 中MyBatis的mapper.xml文件位置的過程詳解

    修改SpringBoot 中MyBatis的mapper.xml文件位置的過程詳解

    由于MyBatis默認的mapper.xml的掃描位置是resource文件下,但是不可能整個項目的mapper.xml文件都放在resource下,如果文件較少還行,但是如果文件比較多,太麻煩了,所以本文給大家介紹了修改SpringBoot 中MyBatis的mapper.xml文件位置的過程,需要的朋友可以參考下
    2024-08-08

最新評論

鲁山县| 句容市| 桃园县| 普兰县| 额敏县| 兴安盟| 军事| 梁河县| 丰台区| 平阳县| 怀来县| 龙川县| 共和县| 鹤岗市| 同心县| 阜新市| 文昌市| 安溪县| 遵化市| 托克逊县| 湘乡市| 长宁县| 黄平县| 科尔| 收藏| 三河市| 高安市| 沈丘县| 乌鲁木齐县| 青浦区| 封丘县| 大邑县| 墨竹工卡县| 沁阳市| 三门峡市| 陕西省| 榆林市| 榆树市| 苗栗县| 长白| 凌云县|