<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    String,StringBuffer,StringBuilder之間的區(qū)別,以及使用中該注意什么(轉(zhuǎn))

        只是了解個大概,具體細(xì)節(jié)上不太清楚,這篇文章不錯,基本上都講清楚了。。。 嘿嘿,學(xué)習(xí)下。。。                                      相信大家對 String 和 StringBuffer 的區(qū)別也已經(jīng)很了解了,但是估計還是會有很多同志對這兩個類的工作原理有些不清楚的地方,今天我在這里重新把這個概念給大家復(fù)習(xí)一下,順便牽出 J2SE 5.0 里面帶來的一個新的字符操作的類—— StringBuilder (先別忙著扔我磚頭,我還算清醒,我這里說的不是 C #, Java 也有 StringBuilder 類)。那么這個 StringBuilderStringBuffer 以及我們最早遇見的 String 類有那些區(qū)別呢?在不同的場合下我們應(yīng)該用哪個呢?我講講自己對這幾個類的一點看法,也希望大家提出意見,每個人都有錯的地方,在錯了改的同時更是一個學(xué)習(xí)的好機(jī)會。

        簡要的說, String 類型和 StringBuffer 類型的主要性能區(qū)別其實在于 String 是不可變的對象(為什么?問問 Java 的設(shè)計者吧,為什么 String 不是原生類型呢?)因此在每次對 String 類型進(jìn)行改變的時候其實都等同于生成了一個新的 String 對象,然后將指針指向新的 String 對象,所以經(jīng)常改變內(nèi)容的字符串最好不要用 String ,因為每次生成對象都會對系統(tǒng)性能產(chǎn)生影響,特別當(dāng)內(nèi)存中無引用對象多了以后, JVM 的 GC 就會開始工作,那速度是一定會相當(dāng)慢的。這里嘗試舉個不是很恰當(dāng)?shù)睦樱?

    String S1 = “abc”;
    For(int I = 0 ; I < 10000 ; I ++) // For 模擬程序的多次調(diào)用
    {
    S1 + = “def”;
    S1 = “abc”;
    }

        如果是這樣的話,到這個 for 循環(huán)完畢后,如果內(nèi)存中的對象沒有被 GC 清理掉的話,內(nèi)存中一共有 2 萬多個了,驚人的數(shù)目,而如果這是一個很多人使用的系統(tǒng),這樣的數(shù)目就不算很多了,所以大家使用的時候一定要小心。

        而如果是使用 StringBuffer 類則結(jié)果就不一樣了,每次結(jié)果都會對 StringBuffer 對象本身進(jìn)行操作,而不是生成新的對象,再改變對象引用。所以在一般情況下我們推薦使用 StringBuffer ,特別是字符串對象經(jīng)常改變的情況下。而在某些特別情況下, String 對象的字符串拼接其實是被 JVM 解釋成了 StringBuffer 對象的拼接,所以這些時候 String 對象的速度并不會比 StringBuffer 對象慢,而特別是以下的字符串對象生成中, String 效率是遠(yuǎn)要比 StringBuffer 快的:

    String S1 = “This is only a” + “ simple” + “ test”;
    StringBuffer Sb = new StringBuilder(“This is only a”).append(“ simple”).append(“ test”);

        你會很驚訝的發(fā)現(xiàn),生成 String S1 對象的速度簡直太快了,而這個時候 StringBuffer 居然速度上根本一點都不占優(yōu)勢。其實這是 JVM 的一個把戲,在 JVM 眼里,這個

    String S1 = “This is only a” + “ simple” + “test”; 其實就是: String S1 = “This is only a simple test”; 所以當(dāng)然不需要太多的時間了。但大家這里要注意的是,如果你的字符串是來自另外的 String 對象的話,速度就沒那么快了,譬如:

    String S2 = “This is only a”;
    String S3 = “ simple”;
    String S4 = “ test”;
    String S1 = S2 +S3 + S4;

        這時候 JVM 會規(guī)規(guī)矩矩的按照原來的方式去做, S1 對象的生成速度就不像剛才那么快了,一會兒我們可以來個測試作個驗證。

        由此我們得到第一步結(jié)論: 在大部分情況下 StringBuffer > String

        而 StringBuilder 跟他們比又怎么樣呢?先簡單介紹一下, StringBuilder 是 JDK5.0 中新增加的一個類,它跟 StringBuffer 的區(qū)別看下面的介紹(來源 JavaWorld ):

        Java.lang.StringBuffer 線程安全的可變字符序列。類似于 String 的字符串緩沖區(qū),但不能修改。可將字符串緩沖區(qū)安全地用于多個線程。可以在必要時對這些方法進(jìn)行同步,因此任意特定實例上的所有操作就好像是以串行順序發(fā)生的,該順序與所涉及的每個線程進(jìn)行的方法調(diào)用順序一致。

        每個字符串緩沖區(qū)都有一定的容量。只要字符串緩沖區(qū)所包含的字符序列的長度沒有超出此容量,就無需分配新的內(nèi)部緩沖區(qū)數(shù)組。如果內(nèi)部緩沖區(qū)溢出,則此容量自動增大。從 JDK 5.0 開始,為該類增添了一個單個線程使用的等價類,即 StringBuilder 。與該類相比,通常應(yīng)該優(yōu)先使用 StringBuilder 類,因為它支持所有相同的操作,但由于它不執(zhí)行同步,所以速度更快。

        但是如果將 StringBuilder 的實例用于多個線程是不安全的。需要這樣的同步,則建議使用 StringBuffer

        這樣說估計大家都能明白他們之間的區(qū)別了,那么下面我們再做一個一般性推導(dǎo):

        在大部分情況下 StringBuilder > StringBuffer

        因此,根據(jù)這個不等式的傳遞定理: 在大部分情況下 StringBuilder > StringBuffer > String

        既然有這樣的推導(dǎo)結(jié)果了,我們做個測試驗證一下:

        測試代碼如下:

    public class testssb {

    /** Creates a new instance of testssb */
    final static int ttime = 10000;// 測試循環(huán)次數(shù)
    public testssb() {
    }

    public void test(String s){
    long begin = System.currentTimeMillis();
    for(int i=0;i<ttime;i++){
    s += "add";
    }
    long over = System.currentTimeMillis();
    System.out.println(" 操作 "+s.getClass().getName()+" 類型使用的時間為: " + (over - begin) + " 毫秒 " );
    }

    public void test(StringBuffer s){
    long begin = System.currentTimeMillis();
    for(int i=0;i<ttime;i++){
    s.append("add");
    }
    long over = System.currentTimeMillis();
    System.out.println(" 操作 "+s.getClass().getName()+" 類型使用的時間為: " + (over - begin) + " 毫秒 " );
    }

    public void test(StringBuilder s){
    long begin = System.currentTimeMillis();
    for(int i=0;i<ttime;i++){
    s.append("add");
    }
    long over = System.currentTimeMillis();
    System.out.println(" 操作 "+s.getClass().getName()+" 類型使用的時間為: " + (over - begin) + " 毫秒 " );
    }

    // 對 String 直接進(jìn)行字符串拼接的測試
    public void test2(){
    String s2 = "abadf";
    long begin = System.currentTimeMillis();
    for(int i=0;i<ttime;i++){
    String s = s2 + s2 + s2 ;
    }
    long over = System.currentTimeMillis();
    System.out.println(" 操作字符串對象引用相加類型使用的時間為: " + (over - begin) + " 毫秒 " );
    }

    public void test3(){
    long begin = System.currentTimeMillis();
    for(int i=0;i<ttime;i++){
    String s = "abadf" + "abadf" + "abadf" ;
    }
    long over = System.currentTimeMillis();
    System.out.println(" 操作字符串相加使用的時間為: "+ (over - begin) + " 毫秒 " );
    }

    public static void main(String[] args){
    String s1 ="abc";
    StringBuffer sb1 = new StringBuffer("abc");
    StringBuilder sb2 = new StringBuilder("abc");

    testssb t = new testssb();
    t.test(s1);
    t.test(sb1);
    t.test(sb2);
    t.test2();
    t.test3();
    }
    }

        以上代碼在 NetBeans 5.0 IDE/JDK1.6 上編譯通過,循環(huán)次數(shù) ttime 為 10000 次的測試結(jié)果如下:
    操作 java.lang.String 類型使用的時間為: 4392 毫秒
    操作 java.lang.StringBuffer 類型使用的時間為: 0 毫秒
    操作 java.lang.StringBuilder 類型使用的時間為: 0 毫秒
    操作字符串對象引用相加類型使用的時間為: 15 毫秒
    操作字符串相加使用的時間為: 0 毫秒

        好像還看不出 StringBufferStringBuilder 的區(qū)別,把 ttime 加到 30000 次看看:
    操作 java.lang.String 類型使用的時間為: 53444 毫秒
    操作 java.lang.StringBuffer 類型使用的時間為: 15 毫秒
    操作 java.lang.StringBuilder 類型使用的時間為: 15 毫秒
    操作字符串對象引用相加類型使用的時間為: 31 毫秒
    操作字符串相加使用的時間為: 0 毫秒

        StringBufferStringBuilder 的性能上還是沒有太大的差異,再加大到 100000 看看,這里就不加入對 String 類型的測試了,因為對 String 類型這么大數(shù)據(jù)量的測試會很慢滴……
    操作 java.lang.StringBuffer 類型使用的時間為: 31 毫秒
    操作 java.lang.StringBuilder 類型使用的時間為: 16 毫秒

        能看出差別了,但其中有多次的測試結(jié)果居然是 StringBufferStringBuilder 快,再加大一些到 1000000 看看(應(yīng)該不會當(dāng)機(jī)吧?):
    操作 java.lang.StringBuffer 類型使用的時間為: 265 毫秒
    操作 java.lang.StringBuilder 類型使用的時間為: 219 毫秒

        有些少區(qū)別了,而且結(jié)果很穩(wěn)定,再大點看看, ttime = 5000000 :

    ······ Exception in thread "main" java.lang.OutOfMemoryError: Java heap space ······

        呵呵,算了,不去測試了,基本來說都是在性能上都是 StringBuilder > StringBuffer > String 的了。 

    posted on 2009-04-22 20:31 胡鵬 閱讀(2324) 評論(0)  編輯  收藏 所屬分類: java基礎(chǔ)

    導(dǎo)航

    <2009年4月>
    2930311234
    567891011
    12131415161718
    19202122232425
    262728293012
    3456789

    統(tǒng)計

    常用鏈接

    留言簿(3)

    隨筆分類

    隨筆檔案

    agile

    搜索

    最新評論

    閱讀排行榜

    評論排行榜

    主站蜘蛛池模板: 成人人观看的免费毛片| www成人免费观看网站| 中文字幕亚洲不卡在线亚瑟| 2021免费日韩视频网| 最近2019中文免费字幕在线观看| eeuss免费影院| 91久久成人免费| 三年片在线观看免费大全| 在线看片无码永久免费aⅴ| 亚洲午夜无码片在线观看影院猛| 亚洲中文字幕无码一区二区三区| 亚洲色图在线观看| 国产亚洲精品第一综合| 免费福利在线视频| 午夜一级毛片免费视频| 亚洲av日韩av激情亚洲| 国产精品亚洲专一区二区三区| 日韩免费电影网址| 亚洲午夜无码片在线观看影院猛| 亚洲自偷自偷在线成人网站传媒| 美女黄频免费网站| 国产在线一区二区综合免费视频 | 亚洲码国产精品高潮在线| 十八禁在线观看视频播放免费| 亚洲区视频在线观看| 亚洲国产成人爱av在线播放| 91精品国产免费网站| 一级全免费视频播放| 亚洲精品天堂成人片AV在线播放| 亚洲av永久无码精品秋霞电影影院 | 久久精品国产亚洲AV电影网| 亚洲AV无码精品色午夜果冻不卡 | 亚洲精品国产高清不卡在线| 亚洲天堂免费在线| 日本在线免费观看| 一级特黄色毛片免费看| 中文字幕乱码亚洲无线三区 | 亚洲成在人线中文字幕| 在线观看亚洲天天一三视| 国产区卡一卡二卡三乱码免费| a拍拍男女免费看全片|