分享
 
 
 

String和StringBuffer之概览

王朝other·作者佚名  2008-05-19
窄屏简体版  字體: |||超大  

String和StringBuffer之概览

非可变对象一旦创建之后就不能再被改变,可变对象则可以在创建之后被改变。String对象是非可变对象,StringBuffer对象则是可变对象。为获得更佳的性能你需要根据实际情况小心谨慎地选择到底使用这两者中的某一个。下面的话题会作详细的阐述。(注意:这个章节假设读者已经具备Java的String和StringBuffer的相关基础知识。)

创建字符串的较佳途径

你可以按照以下方式创建字符串对象:

1.Strings1="hello";

Strings2="hello";

2.Strings3=newString("hello");

Strings4=newString("hello");

上面哪种方式会带来更好的性能呢?下面的代码片断用来测量二者之间的区别。

StringTest1.java

packagecom.performance.string;

/**Thisclassshowsthetimetakenforcreationof

*StringliteralsandStringobjects.

*/

publicclassStringTest1{

publicstaticvoidmain(String[]args){

//createStringliterals

longstartTime=System.currentTimeMillis();

for(inti=0;i<50000;i++){

Strings1="hello";

Strings2="hello";

}

longendTime=System.currentTimeMillis();

System.out.println("TimetakenforcreationofStringliterals:"

+(endTime-startTime)+"milliseconds");

//createStringobjectsusing'new'keyword

longstartTime1=System.currentTimeMillis();

for(inti=0;i<50000;i++){

Strings3=newString("hello");

Strings4=newString("hello");

}

longendTime1=System.currentTimeMillis();

System.out.println("TimetakenforcreationofStringobjects:"

+(endTime1-startTime1)+"milliseconds");

}

}

这段代码的输出:

TimetakenforcreationofStringliterals:0milliseconds

TimetakenforcreationofStringobjects:170milliseconds

JVM是怎样处理字符串的呢?

Java虚拟机会维护一个内部的滞留字符串对象的列表(唯一字符串的池)来避免在堆内存中产生重复的String对象。当JVM从class文件里加载字符串字面量并执行的时候,它会先检查一下当前的字符串是否已经存在于滞留字符串列表,如果已经存在,那就不会再创建一个新的String对象而是将引用指向已经存在的String对象,JVM会在内部为字符串字面量作这种检查,但并不会为通过new关键字创建的String对象作这种检查。当然你可以明确地使用String.intern()方法强制JVM为通过new关键字创建的String对象作这样的检查。这样可以强制JVM检查内部列表而使用已有的String对象。

所以结论是,JVM会内在地为字符串字面量维护一些唯一的String对象,程序员不需要为字符串字面量而发愁,但是可能会被一些通过new关键字创建的String对象而困扰,不过他们可以使用intern()方法来避免在堆内存上创建重复的String对象来改善Java的运行性能。下一小节会向大家展示更多的信息。

下图展示了未使用intern()方法来创建字符串的情况。

string_creating_without_intern()method

你可以自己使用==操作符和String.equals()方法来编码测试上面提到的区别。==操作符会返回true如果一些引用指向一个相同的对象但不会判断String对象的内容是否相同;String.equals()方法会返回true如果被操作的String对象的内容相同。对于上面的代码会有s1==s2,因为s1和s2两个引用指向同一个对象,对于上面的代码,s3.equals(s4)会返回true因为两个对象的内容都一样为”hello”。你可以从上图看出这种机制。在这里有三个独立的包含了相同的内容(”hello”)的对象,实际上我们不需要这么三个独立的对象――因为要运行它们的话既浪费时间又浪费内存。

那么怎样才能确保String对象不会重复呢?下一个话题会涵盖对于内建String机制的兴趣。

滞留字符串的优化作用

同一个字符串对象被重复地创建是不必要的,String.intern()方法可以避免这种情况。下图说明了String.intern()方法是如何工作的,String.intern()方法检查字符串对象的存在性,如果需要的字符串对象已经存在,那么它会将引用指向已经存在的字符串对象而不是重新创建一个。下图描绘了使用了intern()方法的字符串字面量和字符串对象的创建情况。

string_creating_with_intern()method

下面的例程帮助大家了解String.intern()方法的重要性。

StringTest2.java

packagecom.performance.string;

//Thisclassshowstheuseofintern()methodtoimproveperformance

publicclassStringTest2{

publicstaticvoidmain(String[]args){

//createStringreferenceslikes1,s2,s3...soon..

Stringvariables[]=newString[50000];

for(inti=0;i<variables.length;i++){

variables[i]="s"+i;

}

//createStringliterals

longstartTime0=System.currentTimeMillis();

for(inti=0;i<variables.length;i++){

variables[i]="hello";

}

longendTime0=System.currentTimeMillis();

System.out.println("TimetakenforcreationofStringliterals:"

+(endTime0-startTime0)+"milliseconds");

//createStringobjectsusing'new'keyword

longstartTime1=System.currentTimeMillis();

for(inti=0;i<variables.length;i++){

variables[i]=newString("hello");

}

longendTime1=System.currentTimeMillis();

System.out.println("TimetakenforcreationofStringobjectswith'new'keyword:"

+(endTime1-startTime1)+"milliseconds");

//internStringobjectswithintern()method

longstartTime2=System.currentTimeMillis();

for(inti=0;i<variables.length;i++){

variables[i]=newString("hello");

variables[i]=variables[i].intern();

}

longendTime2=System.currentTimeMillis();

System.out.println("TimetakenforcreationofStringobjectswithintern():"

+(endTime2-startTime2)+"milliseconds");

}

}

这是上面那段代码的输出结果:

TimetakenforcreationofStringliterals:0milliseconds

TimetakenforcreationofStringobjectswith'new'keyword:160milliseconds

TimetakenforcreationofStringobjectswithintern():60milliseconds

连接字符串时候的优化技巧

你可以使用+操作符或者String.concat()或者StringBuffer.append()等办法来连接多个字符串,那一种办法具有最佳的性能呢?

如何作出选择取决于两种情景,第一种情景是需要连接的字符串是在编译期决定的还是在运行期决定的,第二种情景是你使用的是StringBuffer还是String。通常程序员会认为StringBuffer.append()方法会优于+操作符或String.concat()方法,但是在一些特定的情况下这个假想是不成立的。

1)第一种情景:编译期决定相对于运行期决定

请看下面的StringTest3.java代码和输出结果。

packagecom.performance.string;

/**Thisclassshowsthetimetakenbystringconcatenationatcompiletimeandruntime.*/

publicclassStringTest3{

publicstaticvoidmain(String[]args){

//TesttheStringConcatination

longstartTime=System.currentTimeMillis();

for(inti=0;i<5000;i++){

Stringresult="Thisis"+"testingthe"+"difference"+"between"+

"String"+"and"+"StringBuffer";

}

longendTime=System.currentTimeMillis();

System.out.println("Timetakenforstringconcatenationusing+operator:"

+(endTime-startTime)+"milliseconds");

//TesttheStringBufferConcatination

longstartTime1=System.currentTimeMillis();

for(inti=0;i<5000;i++){

StringBufferresult=newStringBuffer();

result.append("Thisis");

result.append("testingthe");

result.append("difference");

result.append("between");

result.append("String");

result.append("and");

result.append("StringBuffer");

}

longendTime1=System.currentTimeMillis();

System.out.println("TimetakenforStringconcatenationusingStringBuffer:"

+(endTime1-startTime1)+"milliseconds");

}

}

这是上面的代码的输出结果:

TimetakenforStringconcatenationusing+operator:0milliseconds

TimetakenforStringconcatenationusingStringBuffer:50milliseconds

很有趣地,+操作符居然比StringBuffer.append()方法要快,为什么呢?

这里编译器的优化起了关键作用,编译器像下面举例的那样简单地在编译期连接多个字符串。它使用编译期决定取代运行期决定,在你使用new关键字来创建String对象的时候也是如此。

编译前:

Stringresult="Thisis"+"testingthe"+"difference"+"between"+"String"+"and"+"StringBuffer";

编译后:

Stringresult="ThisistestingthedifferencebetweenStringandStringBuffer";

这里String对象在编译期就决定了而StringBuffer对象是在运行期决定的。运行期决定需要额外的开销当字符串的值无法预先知道的时候,编译期决定作用于字符串的值可以预先知道的时候,下面是一个例子。

编译前:

publicStringgetString(Stringstr1,Stringstr2){

returnstr1+str2;

}

编译后:

returnnewStringBuffer().append(str1).append(str2).toString();

运行期决定需要更多的时间来运行。

2)第二种情景:使用StringBuffer取代String

看看下面的代码你会发现与情景一相反的结果――连接多个字符串的时候StringBuffer要比String快。

StringTest4.java

packagecom.performance.string;

/**Thisclassshowsthetimetakenbystringconcatenation

using+operatorandStringBuffer*/

publicclassStringTest4{

publicstaticvoidmain(String[]args){

//TesttheStringConcatenationusing+operator

longstartTime=System.currentTimeMillis();

Stringresult="hello";

for(inti=0;i<1500;i++){

result+="hello";

}

longendTime=System.currentTimeMillis();

System.out.println("Timetakenforstringconcatenationusing+operator:"

+(endTime-startTime)+"milliseconds");

//TesttheStringConcatenationusingStringBuffer

longstartTime1=System.currentTimeMillis();

StringBufferresult1=newStringBuffer("hello");

for(inti=0;i<1500;i++){

result1.append("hello");

}

longendTime1=System.currentTimeMillis();

System.out.println("TimetakenforstringconcatenationusingStringBuffer:"

+(endTime1-startTime1)+"milliseconds");

}

}

这是上面的代码的输出结果:

Timetakenforstringconcatenationusing+operator:280milliseconds

TimetakenforStringconcatenationusingStringBuffer:0milliseconds

看得出StringBuffer.append()方法要比+操作符要快得多,为什么呢?

原因是两者都是在运行期决定字符串对象,但是+操作符使用不同于StringBuffer.append()的规则通过String和StringBuffer来完成字符串连接操作。(译注:什么样的规则呢?)

借助StringBuffer的初始化过程的优化技巧

你可以通过StringBuffer的构造函数来设定它的初始化容量,这样可以明显地提升性能。这里提到的构造函数是StringBuffer(intlength),length参数表示当前的StringBuffer能保持的字符数量。你也可以使用ensureCapacity(intminimumcapacity)方法在StringBuffer对象创建之后设置它的容量。首先我们看看StringBuffer的缺省行为,然后再找出一条更好的提升性能的途径。

StringBuffer的缺省行为:

StringBuffer在内部维护一个字符数组,当你使用缺省的构造函数来创建StringBuffer对象的时候,因为没有设置初始化字符长度,StringBuffer的容量被初始化为16个字符,也就是说缺省容量就是16个字符。当StringBuffer达到最大容量的时候,它会将自身容量增加到当前的2倍再加2,也就是(2*旧值+2)。

如果你使用缺省值,初始化之后接着往里面追加字符,在你追加到第16个字符的时候它会将容量增加到34(2*16+2),当追加到34个字符的时候就会将容量增加到70(2*34+2)。无论何事只要StringBuffer到达它的最大容量它就不得不创建一个新的字符数组然后重新将旧字符和新字符都拷贝一遍――这也太昂贵了点。所以总是给StringBuffer设置一个合理的初始化容量值是错不了的,这样会带来立竿见影的性能增益。

我利用两个StringBuffer重新测试了上面的StringTest4.java代码,一个未使用初始化容量值而另一个使用了。这次我追加了50000个’hello’对象没有使用+操作符。区别是我使用StringBuffer(250000)的构造函数来初始化第二个StringBuffer了。

输出结果如下:

TimetakenforStringconcatenationusingStringBufferwithoutsettingsize:280milliseconds

TimetakenforStringconcatenationusingStringBufferwithsettingsize:0milliseconds

StringBuffer初始化过程的调整的作用由此可见一斑。所以,使用一个合适的容量值来初始化StringBuffer永远都是一个最佳的建议。

关键点

1.无论何时只要可能的话使用字符串字面量来常见字符串而不是使用new关键字来创建字符串。

2.无论何时当你要使用new关键字来创建很多内容重复的字符串的话,请使用String.intern()方法。

3.+操作符会为字符串连接提供最佳的性能――当字符串是在编译期决定的时候。

4.如果字符串在运行期决定,使用一个合适的初期容量值初始化的StringBuffer会为字符串连接提供最佳的性能。

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有