“StringBuffer 是同步的（或线程安全的）而 StringBuilder 不是”，为什么这会使 StringBuffer 方法变慢？答案

【问题标题】："StringBuffer is synchronized (or thread-safe) and StringBuilder is not", why does this make StringBuffer methods slower?“StringBuffer 是同步的（或线程安全的）而 StringBuilder 不是”，为什么这会使 StringBuffer 方法变慢？
【发布时间】：2011-09-11 17:54:05
【问题描述】：

读完这篇文章 - What does 'synchronized' mean? 我仍然无法理解为什么 StringBuffer 在线程安全环境中会比 StringBuilder 慢。 StringBuffer 需要做哪些额外的耗时工作才能使其变慢？

【问题讨论】：

您自己回答问题。 StringBuffer 是同步的，因此它必须做更多的工作，而另一个必须做的工作。在这种情况下，更糟糕的是 99% 的时间都不需要。
... 和他链接到的线程几乎解释了为什么同步比没有同步的代码要贵一点。
由于上一个问题的重点不是同步方法的额外工作，我不得不假设可能比答案中提到的更多（以证明非常激烈的“不要除非您需要我遇到的 Synchronization 语句，否则请使用 StringBuffer）。下面选择的答案提供了我需要的信息。我认为这个问题是有道理的。
可能会很有趣：How do I prove programmatically that StringBuilder is not threadsafe?

标签： java synchronization thread-safety stringbuilder stringbuffer

【解决方案1】：

即使是非竞争锁，获取和释放也会有一些小的开销，并且lock elision 将无法在 StringBuffer 中工作，即使大多数实例不使用跨线程，因为实例可能是这样。

请参阅http://book.javanb.com/java-threads-3rd/jthreads3-CHP-5-SECT-1.html，了解 VM 在获取和释放锁时必须执行的操作。

【讨论】：

【解决方案2】：

确保一切同步运行。或者，更重要的是，不同步。同步方法调用意味着该方法的两个不同调用（如果它不是静态的，则在该对象上）必须轮流进入该方法。在线程 A（已经在方法中）完成之前，线程 B 无法进入方法 synchMeth。

检查同步块是否已被锁定，以及由谁锁定，需要额外的时间。

【讨论】：

【解决方案3】：

从JavaDoc阅读这篇文章

StringBuilder 类提供 API 与 StringBuffer 兼容，但与不保证同步。这类被设计用作插入式在某些地方替换 StringBuffer 使用字符串缓冲区的位置通过单个线程（通常是案子）。在可能的情况下，它是建议将此类用于对 StringBuffer 的偏好，因为它会在大多数实现下更快。

你必须在StringBuffer vs. StringBuilder performance comparison阅读这篇文章

从 JDK 5 开始，这个类有补充了等价物专为单个使用而设计的类线程，{StringBuilder}。这 StringBuilder 类一般应该优先使用这个，因为它支持所有相同的操作但它更快，因为它不执行同步。

其他有用的链接：Difference between StringBuffer and StringBuilder class.

【讨论】：