Java StringBuilder myth debunked# Java - 爪哇娇娃b*g2013-04-03 07:041 楼http://www.javacodegeeks.com/2013/03/java-stringbuilder-myth-de
c*m2013-04-03 07:043 楼现在的JVM allocate/gc instance效率非常高,象这种不用string concatenation用stringbuffer/builder的事都是1.4以前的老黄历了,类似的还有object pool什么的也都是过时的东西了。何况作者才测试了1000个循环,还在一个loop里,VM很容易在编译的时候优化,就算1.4也未必能看出啥不同。测试一百万还差不多。这个作者一看就没正儿八经写过java,对jvm的基本性能和最新进展一点数都没有。对于一般的app development,早没人在乎string concatenation了,我用stringbuilder主要是觉得它自带的methods比较handy。【在 b**g 的大作中提到】: http://www.javacodegeeks.com/2013/03/java-stringbuilder-myth-de
z*e2013-04-03 07:044 楼嗯,对于java的看法n多人还停留在上个世纪对于gc,一个常见的经验就是把内存使用控制在75%,最好是70%左右这样gc的pause就不会过长,应付大多数应用应该是够了【在 c*m 的大作中提到】: : 现在的JVM allocate/gc instance效率非常高,象这种不用string concatenation用: stringbuffer/builder的事都是1.4以前的老黄历了,类似的还有object pool什么的也: 都是过时的东西了。何况作者才测试了1000个循环,还在一个loop里,VM很容易在编译: 的时候优化,就算1.4也未必能看出啥不同。测试一百万还差不多。这个作者一看就没: 正儿八经写过java,对jvm的基本性能和最新进展一点数都没有。: 对于一般的app development,早没人在乎string concatenation了,我用: stringbuilder主要是觉得它自带的methods比较handy。
b*y2013-04-03 07:048 楼没具体看那篇文章,不过我原先听说的是StringBuilder里面没有multi threading的concurrency control, 速度比StringBuffer快一些。因为StringBuffer内置有threadcontrol, 也就是某段程序是一次只有一个thread可以执行的。【在 k***r 的大作中提到】: 科普一下真正使用场景是啥?
k*r2013-04-03 07:049 楼这个只是为了address StringBuffer的efficiency/deficiency,但如果stringconcatination不是问题了,大概这两个都没有使用的必要了thread【在 b******y 的大作中提到】: : 没具体看那篇文章,不过我原先听说的是StringBuilder里面没有multi threading的: concurrency control, 速度比StringBuffer快一些。因为StringBuffer内置有thread: control, 也就是某段程序是一次只有一个thread可以执行的。
t*e2013-04-03 07:0410 楼像str1 + str2 + ... + strN这样的代码根本没有必要用StringBuilder, 因为java会自动把它编译成使用StringBuilder. 只有java编译器不知道可以用一个StringBuilder来做的时候才需要直接用StringBuilder来写,比如String s = "";for (...) {s += ....}【在 k***r 的大作中提到】: 科普一下真正使用场景是啥?
F*n2013-04-03 07:0411 楼String concatenation 不可能没有问题因为Java String immutable,编译器最多只能通过上下文猜并不能涵盖所有需要StringBuilder的Case【在 k***r 的大作中提到】: 这个只是为了address StringBuffer的efficiency/deficiency,但如果string: concatination不是问题了,大概这两个都没有使用的必要了: : thread