StringBuffer的存在的含义

当我处理旧代码并跨StringBuffer实例运行时，通常将它们替换为StringBuilder实例。尽管可以从此更改中获得性能优势，但我经常在我知道对性能影响不大的地方对其进行更改。我认为，除了可能带来性能收益外，还应出于各种原因进行更改。几乎没有理由不选择StringBuilder不是StringBuffer （API期望是最常见的例外），并且代码中存在StringBuffer误导读者，并为Java新手提供了一个不好的例子。

Andy Hunt和David Thomas 在《实用编程器：从旅居者到大师》一书中讨论了 “修复代码中的小问题“破窗”的重要性”。杰夫·阿特伍德（Jeff Atwood）在“破窗理论”一文中谈到了这个主题，最近在“ 软件腐烂，熵和破窗理论 ”一文中对此进行了介绍，并且不要留下破窗。 StringBuffer的存在暗含代码中的陈旧性。实际上，使用StringBuffer可能不是一个“破损的窗口”，但它是一个真正古老的，泄漏的单窗格窗口，应将其替换为现代的，节能的双窗格窗口。

我发现了Peter Lawrey在最近的博客文章StringBuffer中，摆脱遗留代码有多么困难，这是对代码中仍然存在的StringBuffer其他含义的有趣理解。 Lawrey引用了StringBuffer类Javadoc文档的最后一段，“从JDK 5版本开始，该类已经添加了一个等效类，供单线程StringBuilder使用。通常应优先使用StringBuilder类，因为它支持所有相同的操作，但它更快，因为它不执行同步。” Lawrey然后使用简单的Java方法和jmap证明了StringBuffer实例仍在JDK附带的类和库中使用，甚至直到Java 8为止。

Lawrey指出，在引入“直接替换” StringBuilder十多年之后， StringBuffer在频繁使用的Java代码中的存在证明了“清理遗留代码”有多么困难。 Lawrey的完整结论指出：“在启动时使用StringBuffer并没有多大区别，但是考虑到它具有众所周知的替代性下降，并且仍在使用，即使在十多年后的新功能中也显示出它有多难清理遗留代码或改变思路，使人们使用最佳实践库。”

我决定在用Java 8 Update 121进行编译时以及在使用最新版本的OpenJDK 9进行编译时尝试使用Lawrey最简单的示例之一。我（略）将Lawrey的示例调整为下面所示的简单“ Main”类清单。

Main.java

import java.io.IOException;/*** (Slightly) adapted class from blog post* "StringBuffer, and how hard it is to get rid of legacy code" at* https://vanilla-java.github.io/2017/04/13/String-Buffer-and-how-hard-it-is-to-get-rid-of-legacy-code.html*/
public class Main
{/*** Main function that instantiates this Java "application" and does nothing* else until "ENTER" is pressed.*/public static void main(final String[] args) throws IOException{System.out.println("Waiting [press ENTER to exit] ..");System.in.read();}
}

以下屏幕快照显示了使用jcmd及其-all选项（检查中包括无法访问的对象）的输出，以显示在简单Java应用程序中编译并针对三种不同版本的Java（ Java）运行StringBuffer和StringBuilder的实例数8更新102 ， Java 8更新121和OpenJDK 9.0 ea + 164 ）。 jcmd的执行是在PowerShell中执行的，因此Select-String的用法与Linux中的grep相似。

尽管使用Java 8版本编译和执行的类的版本具有StringBuffer实例，但是使用Java 9编译并针对Java 9执行的版本仅具有StringBuilder实例。看起来JDK-8041679 （“在核心库类中用StringBuilder替换StringBuffer使用”）和JDK-8043342 （“在密码子中用StringBuilder替换StringBuffer使用”）的解析已达到预期的效果。