为什么 String.valueOf 将 Integer 转换为 String 比 String Concatenation 快？答案

【问题标题】：Why is String.valueOf faster than String Concatenation for converting an Integer to a String?为什么 String.valueOf 将 Integer 转换为 String 比 String Concatenation 快？
【发布时间】：2021-04-18 21:49:22
【问题描述】：

这是问题"Why is String concatenation faster than String.valueOf for converting an Integer to a String?"的反面。它不是重复的。相反，它源于this answer，基准断言t.setText(String.valueOf(number)) 比t.setText(""+number) 快，而ChristianB 的问题是为什么。

【问题讨论】：

问题是“两个相似的基准测试如何为在两个不同平台上运行的两个不同 VM 显示相反的结果？”
@thatotherguy 这是因为我们的基准测试是不同的，也可能与 setText 与另一个问题中的普通转换有关。但如果有其他原因，当然，请告诉我们！
甚至可以打赌，它有时更快，有时更慢，具体取决于您使用的 JDK 版本。但在这种情况下，它只是使用 String.valueOf() 或静态 Integer.toString()。

标签： java string benchmarking string-concatenation settext

【解决方案1】：

字符串添加会导致编译器创建一个StringBuilder 实例，然后对每个添加的元素进行追加调用，然后调用StringBuilder.toString() 以创建结果串联的String 实例。

因此，""+number 创建一个StringBuilder，使用与String.valueOf 相同的转换附加一个数字，然后使用StringBuilder.toString 从StringBuilder 创建一个String 实例。

String.valueOf(number) 避免使用 StringBuilder，只使用来自 String.valueOf 的值。

当编译器可以避免所有这些时，答案可能不一样，如果它可以识别最终的字符串结果，因为附加的元素都是常量。在这种情况下，编译器只是将最终的字符串放入编译后的代码中。

【讨论】：

我认为 Java 9+ 不是这样，我错了吗？
会有什么不同？
我读过this，但我从来没有深入研究过它，所以我宁愿不做任何大胆的主张。
看来现在有机会引入新的连接算法，但该更改并未指定是否在 Java 版本中实现了新方法，或者它是否只是动态链接到相同的 StringBuilder 方法
据我所知，在大多数情况下，动态实现继续使用 StringBuilder 方法，所以这个答案仍然基本准确（它不再是编译器生成的代码）stackoverflow.com/questions/50084240/…