什么应该用于基本的字符串连接操作?
String randomString = "hello " + userName + " how are you" ?
或
String randomString = String.format("hello %s how are you ?",userName);
我觉得String.format()
可以更好地了解输出字符串。
但是在使用任何一个中实际上赞成和反对是什么?
字符串文字池中的性能或孤立条目是否有任何内容。
编辑:我在谈论字符串中的多个参数,而不只是一个。大约5 +。
红利问题:还请分享您的观点 哪一个应该实际使用?这些或第三个中的任何一个...... !! ?
答案 0 :(得分:22)
如果您只是在寻找性能,我相信使用StringBuilder/StringBuffer
是构建字符串的最有效方法。即使Java编译器足够智能,可以将大多数String连接转换为等效的StringBuilder
。
如果您正在寻找可读性,我认为String.format
更清晰,除非我需要依赖高性能,否则这也是我使用的。
因此,如果您的主要关注点不是性能,意味着此代码不在一个被调用的路径中,您可能更喜欢使用String.format
,因为它可以更好地了解结果字符串(就像您说的那样) )。
此外,使用String.format
可以让你使用格式的东西,这意味着你可以用它来填充字符串,格式化数字,日期等,如果使用简单的连接,这会使代码更糟。 / p>
编辑 for Chuu :
使用JAD,您可以看到以下代码:
public class Test {
public static void main(String[] args) {
String str = "a" + "b" + "c";
String str2 = "foo" + str + "bar" + str;
System.out.println(str2);
}
}
反编译时看起来像:
public class Test {
public static void main(String[] args) {
String str = "abc";
String str2 = new StringBuilder("foo").append(str).append("bar").append(str).toString();
System.out.println(str2);
}
}
使用javap
实用程序也可以找到证明,该实用程序将显示.class
文件下的Java字节码:
public static void main(java.lang.String[] args);
0 ldc <String "abc"> [16]
2 astore_1 [str]
3 new java.lang.StringBuilder [18]
6 dup
7 ldc <String "foo"> [20]
9 invokespecial java.lang.StringBuilder(java.lang.String) [22]
12 aload_1 [str]
13 invokevirtual java.lang.StringBuilder.append(java.lang.String) : java.lang.StringBuilder [25]
16 ldc <String "bar"> [29]
18 invokevirtual java.lang.StringBuilder.append(java.lang.String) : java.lang.StringBuilder [25]
21 aload_1 [str]
22 invokevirtual java.lang.StringBuilder.append(java.lang.String) : java.lang.StringBuilder [25]
25 invokevirtual java.lang.StringBuilder.toString() : java.lang.String [31]
28 astore_2 [str2]
29 getstatic java.lang.System.out : java.io.PrintStream [35]
32 aload_2 [str2]
33 invokevirtual java.io.PrintStream.println(java.lang.String) : void [41]
36 return
答案 1 :(得分:6)
什么应该用于基本的字符串连接操作?
您提供的示例服务器用途不同。 +
被重载到concat String
,但String.format
用于格式化字符串,如name指定的那样。
将字符串连接在一起并不是它的主要工作。
因此,如果要求只是连接使用+
或concat方法。
这些链接很有用:
Should I use Java's String.format() if performance is important?
Is it better practice to use String.format over string Concatenation in Java?
答案 2 :(得分:3)
试试这个
long t0 = System.currentTimeMillis();
String userName = "test";
for (int i = 0; i < 1000000; i++) {
String randomString = "hello " + userName + " how are you?";
// String randomString = String.format("hello %s how are you ?",userName);
}
System.out.println(System.currentTimeMillis() - t0);
你会惊讶地发现,连接速度比String.format快10倍。但是格式可以用数字,日期等做很多非常有用的事情。有关详细信息,请参阅String.format实际使用的java.util.Formatter API。
答案 3 :(得分:3)
我的两分钱:始终使用String.format()
在这种情况下,国际化比风格或表现更为重要。出于这个原因,我总是使用String.format()
英文文本:"Hello " + userName + " how are you?"
翻译成绝地:userName + "you are how? Hello!"
如果字符串连接在一起,那么对于翻译者来说,改变单词顺序即使不是不可能也是困难的。这个问题变得越来越严重,因为字符串中有更多的部分和更多的占位符。
答案 4 :(得分:1)
就我个人而言,我更喜欢使用格式化,因为它看起来更好,我无法想象它会严重影响性能。
答案 5 :(得分:1)
大多数推荐使用StringBuffer的人都过去。 目前的最佳做法是使用StringBuilder。但这可能会改变,那么为什么不让编译器为你做呢? 当你只使用&#34; +&#34;编译器将选择besst当前实现,它甚至可以组合静态字符串(&#34; foo&#34; +&#34; bar&#34;将成为单个&#34; foobar&#34;)。
我将显式分配StringBuilder的onle位置在循环中(在循环之前创建它并在其中使用)。
如果您对发生的情况有疑问,请检查生成的字节码。
那么何时使用格式?当实际的格式化很复杂时,我会使用格式。但是你现在正在谈论简单的连接。
答案 6 :(得分:1)
我认为String.Format效率更高,因为它有以下优点,
感谢。
答案 7 :(得分:1)
在我看来,请使用+ operator
。
如果性能是一个问题,你应该使用StringBuilder
,正如Alex在上面的评论中指出的那样,Java编译器将转换:
String str2 = "a" + str1;
至:String str2 = new StringBuilder("a").append(str1)).toString();
除此之外,您还可以使用+ operator
来避免运行时异常。相反,您将获得在编译时可以捕获的语法错误。例如:
String var = "huge success.";
System.out.print( "I'm making a note here: " + var );
//System.out.print( "Printing: " + ); Syntax error!
System.out.print( String.format( "I'm making a note here: '%s'", var ) );
System.out.print( String.format( "I'm making a note here: '%s'" ) ); // runtime exception!
System.out.print( String.format( "I'm making a note here: '%d'", var ) ); // runtime exception!
可读性取决于个人偏好。但是我会说String.format
语法基本上来自C ++,从那时起创建的大多数语言都因为可读性而接受了+ operator
。
答案 8 :(得分:0)
我对String.format
的主要关注是它是一个特定于语言环境的操作,如果您的代码在不同的语言环境中运行,您最终可能会得到不可预测的结果。
我希望有一个非语言环境替代它,因为它的紧凑语法非常好。