字符串连接将花费更多。 在Java中，您可以根据需要使用StringBuffer或StringBuilder。 如果您想要一个同步的、线程安全的实现，请使用StringBuffer。这将比字符串连接更快。

如果你不需要同步的或者线程安全的实现，选择StringBuilder。 这将比String连接更快，也比StringBuffer更快，因为它们没有同步开销。

我已经看到，在StringBuilder的实例上使用EnsureCapacity(int capacity)方法调用，然后再将它用于任何字符串存储，可以显著提高性能。我通常在实例化后的代码行中调用它。它的效果和你这样实例化StringBuilder是一样的:

var sb = new StringBuilder(int capacity);

该调用会提前分配所需的内存，从而在多个Append()操作期间减少内存分配。您必须对需要多少内存做出有根据的猜测，但对于大多数应用程序来说，这应该不会太难。我通常会在内存过多的情况下犯错(我们说的是1k左右)。

这个基准测试表明，当组合3个或更少字符串时，常规连接更快。

http://www.chinhdo.com/20070224/stringbuilder-is-not-always-faster/

StringBuilder可以在内存使用方面做出非常显著的改进，特别是在将500个字符串加在一起的情况下。

考虑下面的例子:

string buffer = "The numbers are: ";
for( int i = 0; i < 5; i++)
{
    buffer += i.ToString();
}
return buffer;

内存中发生了什么?创建以下字符串:

1 - "The numbers are: "
2 - "0"
3 - "The numbers are: 0"
4 - "1"
5 - "The numbers are: 01"
6 - "2"
7 - "The numbers are: 012"
8 - "3"
9 - "The numbers are: 0123"
10 - "4"
11 - "The numbers are: 01234"
12 - "5"
13 - "The numbers are: 012345"

通过将这5个数字加到字符串的末尾，我们创建了13个字符串对象!其中12个是无用的!哇!

StringBuilder fixes this problem. It is not a "mutable string" as we often hear (all strings in .NET are immutable). It works by keeping an internal buffer, an array of char. Calling Append() or AppendLine() adds the string to the empty space at the end of the char array; if the array is too small, it creates a new, larger array, and copies the buffer there. So in the example above, StringBuilder might only need a single array to contain all 5 additions to the string-- depending on the size of its buffer. You can tell StringBuilder how big its buffer should be in the constructor.

是的，性能差异是显著的。请参阅KB文章“如何在Visual c#中提高字符串连接性能”。

我总是试着先编写清晰的代码，然后再优化性能。这比反过来做要容易得多!但是，看到了两者在我的应用程序中的巨大性能差异后，我现在更仔细地考虑了一下。

幸运的是，在代码上运行性能分析相对简单，可以看到您在哪些地方花费了时间，然后在需要的地方修改它以使用StringBuilder。

以“微优化剧场的悲剧”为例。

在. net中，StringBuilder仍然比追加字符串快。我很确定在Java中，它们只是在附加字符串时在底层创建了一个StringBuffer，所以没有真正的区别。我不确定为什么他们还没有在。net中这样做。