StringBuffer已经过时了吗?

在“有效的Java”一书中,Josh Bloch说

StringBuffer很大程度上已经过时了,应该由非同步实现“StringBuilder”

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

由于Java 1.5上的新代码通常应该使用StringBuilder ,这已经过时了,你真的需要以线程安全的方式构buildstring的情况非常罕见,那么为什么要支付同步成本呢?

我怀疑你看到的使用StringBuffer代码大多数都属于:

  • 在Java 1.5之前编写
  • 书面保持与旧JDK的兼容性
  • 由不懂StringBuilder人撰写
  • 由不知道StringBuilder工具自动生成

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

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

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

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

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

您仍然看到StringBuffer被广泛使用的原因仅仅是惯性:仍然有无数的代码示例教程在那里从来没有更新使用StringBuilder ,人们仍然从这些来源学习过时的做法(不只是这一个)。 即使是那些更了解情况的人也往往会回到过去的习惯。

我认为过时是夸张的。

StringBuffer是同步的。 StringBuilder不是。

在许多情况下(也许大多数情况下),你不会关心用于构buildstring的东西的线程安全性。 在这些情况下你应该使用StringBuilder。 但是,在某些情况下,您可能希望确保对象上的操作是线程安全的。 在这些情况下,StringBuffer仍然有用。

在大多数情况下,不仅同步不是必需的,而且如果你使用它的话,它实际上给你的代码的读者提供了错误的信息:也就是说,读者可以被引导认为在实际上不需要同步的情况下。

而是使用StringBuilder来宣传您不希望跨线程访问的事实。

实际上,通过线程发送数据几乎总是要通过定义好的通信通道完成,而不是简单地通过访问同步的string缓冲区。 所以在某种程度上,我会build议总是使用不同的解决scheme,即使在第一眼看来StringBuffer似乎是合适的。