最近有人问我这个问题–在Java中使用+运算符连接字符串是否对性能不利?
这让我开始思考Java中连接字符串的不同方法,以及它们如何相互对抗。 这些是我要研究的方法:
- 使用+运算符
- 使用
StringBuilder
- 使用
StringBuffer
- 使用
String.concat()
- 使用
String.join
(String.join
新增功能)
我也尝试了String.format()
但是那太慢了,以至于我暂时不在本文中介绍。
在继续之前,我们应该分离两个用例:
- 将两个字符串作为单个调用连接在一起,例如在日志消息中。 因为这只是一个电话,您可能会认为性能几乎不是问题,但结果仍然很有趣,并且可以阐明该主题。
- 在一个循环中连接两个字符串。 性能尤其是一个问题,尤其是在循环较大的情况下。
我最初的想法和问题如下:
- +运算符是用StringBuilder实现的,因此至少在连接两个String的情况下,它应产生与StringBuilder类似的结果。 幕后到底发生了什么?
- 在所有类都是出于连接字符串并取代StringBuffer的目的而设计的之后,StringBuilder应该是最有效的方法。 但是,与String.concat()相比,创建StringBuilder的开销是多少?
- StringBuffer是用于连接字符串的原始类–不幸的是,其方法是同步的。 确实不需要同步,并且随后将其替换为未同步的StringBuilder。 问题是,JIT是否优化了同步?
- String.concat()应该适用于2个字符串,但是在循环中是否可以正常工作?
- String.join()具有比StringBuilder更多的功能,如果我们指示它使用空的定界符来联接String,它将如何影响性能?
我要解决的第一个问题是+运算符的工作方式。 我一直都知道它在幕后使用了StringBuilder,但是要证明这一点,我们需要检查字节码。
如今 ,查看字节码最简单的方法是使用JITWatch ,这是一个非常出色的工具,旨在了解JIT如何编译您的代码。 它有一个很棒的视图,您可以在其中与字节码(如果要进入该级别,还可以是机器码)并排查看源代码。
这是一个非常简单的方法plus2()的字节码,我们可以看到确实在第6行上创建了一个StringBuilder并附加了变量a(第14行)和b(第18行)。
我认为将其与StringBuffer的手工使用进行比较会很有趣,因此我创建了另一个方法build2(),结果如下。
此处生成的字节码不如plus()方法那么紧凑。 StringBuilder存储在变量高速缓存中(第13行),而不是仅留在堆栈上。 我不知道为什么会这样,但是JIT可能能够做到这一点,我们将不得不看看时机如何。
无论如何,如果用plus运算符和StringBuilder将2个字符串连接起来的结果显着不同,那将是非常令人惊讶的。
我写了一个小型的JMH测试来确定不同方法的执行方式。 让我们首先看一下两个Strings测试。 参见下面的代码:
package org.sample;import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;import java.util.UUID;
import java.util.concurrent.TimeUnit;@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(1)
@State(Scope.Thread)
public class LoopStringsBenchmark {private String[] strings;@Setuppublic void setupTest(){strings = new String[100];for(int i = 0; i<100; i++) {strings[i] = UUID.randomUUID().toString().substring(0, 10);}}@Benchmarkpublic void testPlus(Blackhole bh) {String combined = "";for(String s : strings) {combined = combined + s;}bh.consume(combined);}@Benchmarkpublic void testStringBuilder(Blackhole bh) {StringBuilder sb = new StringBuilder();for(String s : strings) {sb.append(s);}bh.consume(sb.toString());}@Benchmarkpublic void testStringBuffer(Blackhole bh) {StringBuffer sb = new StringBuffer();for(String s : strings) {sb.append(s);}bh.consume(sb.toString());}@Benchmarkpublic void testStringJoiner(Blackhole bh) {bh.consume(String.join("", strings));}@Benchmarkpublic void testStringConcat(Blackhole bh) {String combined = "";for(String s : strings) {combined.concat(s);}bh.consume(combined);}
}
结果看起来像这样:
显而易见的赢家是String.concat()。 毫不奇怪,因为它不必为每次调用创建StringBuilder / StringBuffer而付出性能损失。 虽然确实需要每次都创建一个新的String(这将在以后变得很重要),但是对于连接两个Sting的非常简单的情况,它更快。
另一点是,尽管产生了额外的字节码,但正如我们预期的那样,plus和StringBuilder是等效的。 StringBuffer仅比StringBuilder慢一点,这很有趣,这表明JIT必须在做一些魔术来优化同步。
下一个测试将创建一个由100个字符串组成的数组,每个字符串包含10个字符。 基准比较了将100个字符串连接在一起的不同方法所花费的时间。 参见下面的代码:
这次的结果看起来完全不同:
在这里,加号方法确实遭受了损失。 每次循环时创建StringBuilder的开销都非常大。 您可以在字节码中清楚地看到这一点:
您可以看到每次执行循环时都会创建一个新的StringBuilder(第30行)。 可以争论的是,JIT应该发现这一点并能够对其进行优化,但是事实并非如此,并且使用+变得非常慢。
同样,StringBuilder和StringBuffer的性能完全相同,但是这次它们都比String.concat()快。 String.concat()为在循环的每次迭代中创建新的String付出的代价最终会增加,并且StringBuilder变得更有效率。
给定可以添加到此方法的所有其他功能,String.join()效果很好,但是,正如预期的那样,对于纯串联而言,它不是最佳选择。
摘要
如果要在单行代码中连接字符串,我将使用+运算符,因为它最易读,并且性能对于单次调用实际上并不重要。 还要提防String.concat(),因为您几乎肯定会需要执行空检查 ,而其他方法则不需要这样做。
在循环中串联字符串时,应使用StringBuilder。 您可以使用StringBuffer,但我不一定在所有情况下都信任JIT来像基准测试中那样高效地优化同步。
我的所有结果都是使用JMH取得的,并且都带有通常的健康警告 。
翻译自: https://www.javacodegeeks.com/2015/02/optimum-method-concatenate-strings-java.html