StringBuffer 已经过时了吗？
Josh Bloch 在《Effective Java》一书中说
StringBuffer 已基本过时，应由 非同步实现“StringBuilder”
。
但根据我的经验，我仍然看到 StringBuffer 类的广泛使用。为什么 StringBuffer 类现在已过时？除了由于非同步而提高的性能之外，为什么 StringBuilder 应该优于 StringBuffer？
In the book "Effective Java", Josh Bloch says that
StringBuffer is largely obsolete and should be replaced by the
non-synchronized implementation 'StringBuilder'
.
But in my experience, I've still seen widespread use of the StringBuffer class. Why is the StringBuffer class now obsolete and why should StringBuilder be preferred over StringBuffer except for the increased performance due to non-synchronization?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
它已经过时了，Java 1.5 上的新代码通常应该使用
StringBuilder- 您真正需要在线程安全中构建字符串的情况很少那么为什么要支付同步成本呢？我怀疑您看到的使用
StringBuffer的代码大多属于以下几类：StringBuilder的人编写StringBuilder的工具It's obsolete in that new code on Java 1.5 should generally use
StringBuilder- it's very rare that you really need to build strings in a thread-safe manner, so why pay the synchronization cost?I suspect code that you see using
StringBuffermostly falls into buckets of:StringBuilderStringBuilder不是每个人都像你一样广泛阅读:-)
我只是半开玩笑。人们一直在复制代码和模式。许多人并不关注 API 的变化。
为什么 StringBuffer 已经过时了？因为在绝大多数情况下，不需要其同步行为。我想不起来什么时候我需要过它。尽管事实上同步现在已不再像以前那样是性能问题，但在不必要的情况下支付该税是没有意义的。
Not everyone reads as widely as you :-)
I'm only half-joking. People copy code and patterns all the time. Many people don't stay in touch with API changes.
Why is StringBuffer obsolete? Because in the vast majority of cases, its synchronised behaviour isn't required. I can't think of a time I've ever needed it. Despite the fact that synchronisation is not now the performance issue it once was, it makes little sense to pay that tax in scenarios where it's unnecessary.
因为它的操作是同步的，这会增加开销并且很少有用。
您仍然看到
StringBuffer被广泛使用的原因只是惯性：仍然有无数的代码示例教程从未更新为使用StringBuilder，而且人们仍然学习过时的做法（不仅仅是这个）来自这些来源。即使是懂得更多的人也常常会回到旧习惯。Because its operations are synchronized, which adds overhead and is rarely useful.
The reason why you still see
StringBufferused widely is simply inertia: There are still countless code examples tutorials out there that were never updated to useStringBuilder, and people still learn outdated practices (not just this one) from such sources. And even people who know better often fall back to old habits.我认为过时是一种夸大其辞的说法。
StringBuffer 是同步的。 StringBuilder 不是。
在许多（也许是大多数）情况下，您不会关心用于构建字符串的线程安全性。在这些情况下您应该使用 StringBuilder。然而，在某些情况下，您可能非常希望确保对象上的操作是线程安全的。 StringBuffer 在这些情况下仍然有用。
I think obsolete is an overstatement.
StringBuffer is synchronized. StringBuilder is not.
In many (maybe most) cases, you won't care about the thread safety of something used to build strings. You should use StringBuilder in these cases. In some cases, however, you may very well want to make sure actions on the object is thread safe. StringBuffer is still useful in those cases.
在大多数情况下，不仅不需要同步，而且如果您仍然使用它，它实际上会给代码的读者提供错误的信息：即，可能会导致读者认为需要同步，而实际上不需要同步。
使用
StringBuilder相反，会宣传您不期望跨线程访问的事实。事实上，无论如何，跨线程发送数据几乎总是应该通过明确定义的通信通道来完成，而不仅仅是通过访问同步字符串缓冲区来完成。因此，在某种程度上，我建议始终使用不同的解决方案，即使
StringBuffer乍一看似乎合适。Not only is synchronisation not required in most cases, it actually gives readers of your code wrong information if you nevertheless use it: namely, the reader could be led to believe that synchronisation is required where it actually isn’t.
Using a
StringBuilderinstead advertises the fact that you don’t expect cross-thread access.In fact, sending data across threads should almost always be done through well-defined channels of communication anyway, not simply by accessing a synchronised string buffer. So in a way I would recommend always using a different solution, even when a
StringBufferseems appropriate at first glance.