StringBuffer 已过时？

Posted 2023-02-25

【中文标题】StringBuffer 已过时？

【英文标题】：StringBuffer is obsolete?

【发布时间】：2011-10-10 03:23:09

【问题描述】：

Josh Bloch 在《Effective Java》一书中说

StringBuffer 在很大程度上已经过时，应该由 非同步实现'StringBuilder'

。

但根据我的经验，我仍然看到 StringBuffer 类的广泛使用。为什么 StringBuffer 类现在已经过时了，为什么 StringBuilder 比 StringBuffer 更受欢迎，除了由于不同步而提高了性能？

【问题讨论】：

您会看到 StringBuffer 被如此广泛地使用，原因与您仍然看到 Vector 类如此广泛使用的原因相同，即 1. 人们阅读 Java 1.5 之前的书籍。 2. 网上还是有很多使用StringBuffer的例子。 3. 仍然有人编程/教授 Java 但不了解 StringBuilder。

【参考方案1】：

Java 1.5 上的新代码 已过时，通常应该使用StringBuilder - 非常您真的需要以线程安全的方式构建字符串，那为什么要支付同步费用呢？

我怀疑您使用StringBuffer 看到的代码大多属于：

在 Java 1.5 之前编写 为保持与旧版 JDK 的兼容性而编写 写的人不知道StringBuilder 由不了解StringBuilder的工具自动生成

【讨论】：

我浏览了StringBuffer和StringBuilder的代码。它们完全相同，只是 StringBuffer 的所有方法都附加了 synchronized 关键字。

@Varun：我一点也不惊讶。

我怀疑很多知道 StringBuilder 的人纯粹出于习惯而继续使用 StringBuffer。我知道我必须与之抗争……

【参考方案2】：

不是每个人都像你一样广泛阅读:-)

我只是半开玩笑。人们一直在复制代码和模式。许多人不会与 API 更改保持联系。

为什么 StringBuffer 过时了？因为在绝大多数情况下，它的同步行为不是必需的。我想不出我曾经需要它的时间。尽管同步现在不再是曾经的性能问题，但在不必要的情况下支付该税是没有意义的。

【参考方案3】：

为什么 StringBuffer 类现在已经过时了？

因为它的操作是同步的，这增加了开销并且很少有用。

您仍然看到StringBuffer 被广泛使用的原因只是惯性：仍然有无数的代码示例教程从未更新为使用StringBuilder，人们仍然从那里学习过时的做法（不仅仅是这个）这样的来源。即使是更了解的人也经常会回到旧习惯。

【参考方案4】：

我认为过时是夸大其词。

StringBuffer 已同步。 StringBuilder 不是。

在许多（可能是大多数）情况下，您不会关心用于构建字符串的线程安全性。在这些情况下，您应该使用 StringBuilder。然而，在某些 情况下，您可能非常希望确保对象上的操作是线程安全的。 StringBuffer 在这些情况下仍然有用。

【讨论】：

如果您关心结果字符串中数据的顺序，我不确定我能否找到一个让多个线程构建一个字符串的充分理由。

@Hardwareguy：我想是某种记录器，因为您可以通过附加整条消息来工作。不过会很乱，而且代码味道很差。

【参考方案5】：

不仅在大多数情况下不需要同步，而且如果您仍然使用它，它实际上会给阅读您的代码的读者提供错误的信息：也就是说，可能会导致读者相信在实际上不需要同步的情况下需要同步。

使用StringBuilder 来宣传您不期望跨线程访问这一事实。

事实上，跨线程发送数据几乎总是应该通过定义良好的通信通道来完成，而不是简单地通过访问同步的字符串缓冲区。所以在某种程度上我会建议总是使用不同的解决方案，即使StringBuffer 乍一看似乎合适。