使用StringBuilder有哪些缺点？

Question

我知道在处理频繁修改字符串值的代码时，使用StringBuilder比普通字符串更高效。虽然字符串看起来像值类型，但它们实际上是引用类型，这使得它们是不可变的，所以每次我们改变它时，需要在内存中创建一个新的引用。

我的问题是，为什么.NET不默认使用StringBuilder呢？肯定有一些缺点，否则就没有必要只使用String了。有人能告诉我它们是什么吗？

我唯一能想到的是，可能StringBuilder是一个更重的对象，并且需要更长的时间来实例化，所以如果你不会太多地改变字符串，那么这将覆盖使用StringBuilder的好处。

- Diskdrive

Answer 1

为了以线程安全的方式操作字符串，它们被设置为不可变。因为StringBuilder是可变的，所以它不是线程安全的。此外，您可以通过复制对字符串的引用而不是创建一个全新的对象来创建“副本”字符串。可变对象可以通过任何它们的引用进行更改，这是危险的。

- Vincent Ramdhanie

---

@Diego Sevilla OP想知道为什么要使用不可变的String而不是可变的StringBuilder。线程安全是其中一个原因。 - Vincent Ramdhanie

看起来还不错。线程安全是需要注意的问题。默认情况下使用 StringBuilder 可以将其从“选择加入”可变性转换为“选择退出”可变性。 - user166390

@Diego：如果你传递的是一个字符串构建器而不是字符串，那么这就适用。 - Merlyn Morgan-Graham

我的意思是，在这种情况下，设计选择并不是由线程安全驱动的，而是出于效率考虑，这是肯定的。线程安全可能是不可变字符串的副作用，但（在我看来）不是String不可变的主要设计决策。 - Diego Sevilla

@Merlyn: 但是你为什么会考虑传递StringBuilder呢？注意它的名字！:) 它只是用来构建字符串的... - Diego Sevilla

@Diego：出于同样的原因，您可能会在多线程应用程序中传递字符串并在其上构建。也许您有一些文本数据，它们不需要按顺序，但生成成本很高。在这种情况下，您基本上将StringBuilder用作“优化”的List<string>或string。但正如Vincent所说，这行不通 :) - Merlyn Morgan-Graham

Answer 2

也许只是一个不太好的模式（需要创建另一个对象，然后使用toString()方法来实际获取String）。还要注意的是，由于字符串的+运算符是特殊的，编译器可以在内部优化字符串复制，因此在.NET中可能没有实际的开销。

- Diego Sevilla

---

因此，对于简单的字符串操作，使用StringBuilder可能会使用更多的RAM和CPU时间。MS文档中关于StringBuilder的说明指出了何时应该使用String https://learn.microsoft.com/en-us/dotnet/api/system.text.stringbuilder。+1 - Roland