我正在编写一个微基准来比较使用 + 运算符vs StringBuilder 的字符串连接。为此,我基于OpenJDK example that uses the batchSize parameter:
创建了一个JMH基准测试类@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@Measurement(batchSize = 10000, iterations = 10)
@Warmup(batchSize = 10000, iterations = 10)
@Fork(1)
public class StringConcatenationBenchmark {
private String string;
private StringBuilder stringBuilder;
@Setup(Level.Iteration)
public void setup() {
string = "";
stringBuilder = new StringBuilder();
}
@Benchmark
public void stringConcatenation() {
string += "some more data";
}
@Benchmark
public void stringBuilderConcatenation() {
stringBuilder.append("some more data");
}
}
当我运行基准测试时,stringBuilderConcatenation
方法会出现以下错误:
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3332)
at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:137)
at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:121)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:421)
at java.lang.StringBuilder.append(StringBuilder.java:136)
at link.pellegrino.string_concatenation.StringConcatenationBenchmark.stringBuilderConcatenation(StringConcatenationBenchmark.java:29)
at link.pellegrino.string_concatenation.generated.StringConcatenationBenchmark_stringBuilderConcatenation.stringBuilderConcatenation_avgt_jmhStub(StringConcatenationBenchmark_stringBuilderConcatenation.java:165)
at link.pellegrino.string_concatenation.generated.StringConcatenationBenchmark_stringBuilderConcatenation.stringBuilderConcatenation_AverageTime(StringConcatenationBenchmark_stringBuilderConcatenation.java:130)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:430)
at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:412)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
我认为必须增加默认的JVM堆大小,所以我尝试使用-Xmx10G
值和JMH提供的-jvmArgs
选项允许最多10GB。不幸的是,我仍然得到错误。
因此,我尝试将batchSize
参数的值减少为 1 ,但我仍然得到 OutOfMemoryError 。
我找到的唯一解决方法是将基准模式设置为Mode.SingleShotTime
。由于此模式似乎将批处理视为单次拍摄(即使 s / op 显示在“单位”列中),似乎我得到了我想要的指标:执行集合的平均时间批处理操作。但是,我仍然不明白为什么它不能使用Mode.AverageTime
。
请注意,无论使用何种基准模式,方法stringConcatenation
的基准都可以正常工作。该问题仅发生在使用StringBuilder的stringBuilderConcatenation
方法。
任何有助于理解为什么上一个示例不能使用设置为Mode.AverageTime
的基准测试模式的帮助是值得欢迎的。
我使用的JMH版本是 1.10.4 。
答案 0 :(得分:3)
你是对的Mode.SingleShotTime
是你需要的:它衡量单批的时间。使用Mode.AverageTime
时,迭代仍然有效,直到迭代时间结束(默认为1秒)。它测量每个执行单个批次的时间(只计算在执行时间内完全完成的批次),因此最终结果不同,但执行时间相同。
另一个问题是@Setup(Level.Iteration)
强制设置在每次迭代之前执行,而不是在每次批处理之前执行。因此,您的字符串实际上不受批量大小的限制。字符串版本不会导致OutOfMemoryError
只是因为它比StringBuilder
慢得多,所以在1秒内它能够构建更短的字符串。
修复基准测试的不太好的方法(仍使用平均时间模式和batchSize参数)是手动重置字符串/ stringBuilder:
@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@Measurement(batchSize = 10000, iterations = 10)
@Warmup(batchSize = 10000, iterations = 10)
@Fork(1)
public class StringConcatenationBenchmark {
private static final String S = "some more data";
private static final int maxLen = S.length()*10000;
private String string;
private StringBuilder stringBuilder;
@Setup(Level.Iteration)
public void setup() {
string = "";
stringBuilder = new StringBuilder();
}
@Benchmark
public void stringConcatenation() {
if(string.length() >= maxLen) string = "";
string += S;
}
@Benchmark
public void stringBuilderConcatenation() {
if(stringBuilder.length() >= maxLen) stringBuilder = new StringBuilder();
stringBuilder.append(S);
}
}
这是我的盒子上的结果(i5 3340,4Gb RAM,64bit Win7,JDK 1.8.0_45):
Benchmark Mode Cnt Score Error Units
stringBuilderConcatenation avgt 10 145.997 ± 2.301 us/op
stringConcatenation avgt 10 324878.341 ± 39824.738 us/op
所以你可以看到只有大约3个批次适合stringConcatenation
(1e6/324878
),而stringBuilderConcatenation
可以执行数千个批次,导致大量字符串导致{{1 }}
我不知道为什么添加更多内存对你不起作用,对我来说OutOfMemoryError
足以运行原始基准测试的stringBuilder测试。可能你的盒子更快,所以生成的字符串甚至更长。请注意,对于非常大的字符串,即使您有足够的内存,也可以达到数组大小限制(20亿个元素)。添加内存后检查异常堆栈跟踪:它是否相同?如果达到数组大小限制,它仍然是-Xmx4G
,但堆栈跟踪会有所不同。无论如何,即使有足够的内存,您的基准测试结果也会不正确(OutOfMemoryError
和String
)。