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的使用”) 的解析已达到预期的效果。
翻译自: https://www.javacodegeeks.com/2017/04/implications-presence-stringbuffer.html
stringbuffer