如果后者只是对前者的包装，为什么indexOf比contains快得多？
以下是Java API中的代码：
public boolean contains(CharSequence s) {
return indexOf(s.toString()) > -1;
}
indexOf比contains更快，我只是想知道为什么。contains 方法的实现方式如下：
public boolean contains(CharSequence s) {
return indexOf(s.toString()) > -1;
}
CharSequence s不是一个java.lang.String，那么调用s.toString()将导致分配和初始化一个新的字符串实例，因此可能会更慢。如果s是一个字符串，则不应该有任何可测量的差异。contains内部调用indexOf，这意味着indexOf最终将被编译为本地代码。因此，当他测试indexOf（请注意他在测试contains之后进行测试）时，indexOf可能已经被编译为本地代码。这就是时间差异的原因。尝试反转那些测试的顺序-先测试indexOf，然后测试contains，我敢打赌你会看到完全相反的结果。
Benchmark Mode Cnt Score Error Units
StringSearchBenchmark.testContains thrpt 500 22,071 ± 0,269 ops/us
StringSearchBenchmark.testIndexOf thrpt 500 22,654 ± 0,233 ops/us
正如您所看到的，差异微不足道，可能是由于额外的方法调用（indexOf() + toString()）和系统负载造成的。
源代码：
@Fork(1)
@State(Scope.Benchmark)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@Measurement(iterations = 500, time = 50, timeUnit = TimeUnit.MILLISECONDS)
@Warmup(iterations = 10)
@BenchmarkMode(Mode.Throughput)
public class StringSearchBenchmark {
private static final String STATE = "absdefghijklmnopqrstuvwxyzabsdefghijklmnopqrstuvwxyzabsdefghijklmnopqrstuvwxyzabsdefghijklmnopqrstuvwxyz";
private static final String SEARCH_TERM = "abcd";
@Benchmark
public void testContains(Blackhole sink) {
sink.consume(STATE.contains(SEARCH_TERM));
}
@Benchmark
public void testIndexOf(Blackhole sink) {
sink.consume(STATE.indexOf(SEARCH_TERM));
}
}
正如其他人所说，这个基准测试非常有缺陷 - Java 代码的性能测试并不像那样工作。您必须预热它，以确保所有类都已加载和解析，所有对象都已加载到内存中，并且已完成通过 HotSpot 编译为本地代码等任何编译操作。只在 main 方法中运行一次代码的天真基准测试不会真正起作用。更好的选择是使用类似 JMH 的东西。给定以下测试：
package com.stackoverflow.example;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@Measurement(time = 250, timeUnit = TimeUnit.MILLISECONDS)
public class MyBenchmark {
private static final String[] names = new String[]{"jack", "jackson", "jason", "jadifu"};
public static void main(String[] args) throws RunnerException {
Options opt = new OptionsBuilder()
.include(MyBenchmark.class.getSimpleName())
.forks(1)
.build();
new Runner(opt).run();
}
@Benchmark
public void contains() {
names[0].contains("ja");
}
@Benchmark
public void containsExplicit() {
names[0].indexOf("ja".toString());
}
@Benchmark
public void indexOf() {
names[0].indexOf("ja");
}
@Benchmark
public void matches() {
names[0].matches(".*ja.*");
}
}
Benchmark Mode Cnt Score Error Units
MyBenchmark.contains thrpt 20 219.770 ± 2.032 ops/us
MyBenchmark.containsExplicit thrpt 20 1820.024 ± 20.583 ops/us
MyBenchmark.indexOf thrpt 20 1828.234 ± 18.744 ops/us
MyBenchmark.matches thrpt 20 3.933 ± 0.052 ops/us
现在，这非常有趣，因为它仍然表明contains比indexOf慢得多。但是，如果我稍微改变一下测试，如下所示：
@Benchmark
public void contains() {
assert names[0].contains("ja");
}
@Benchmark
public void containsExplicit() {
assert names[0].indexOf("ja".toString()) == 0;
}
@Benchmark
public void indexOf() {
assert names[0].indexOf("ja") == 0;
}
@Benchmark
public void matches() {
assert names[0].matches(".*ja.*");
}
Benchmark Mode Cnt Score Error Units
MyBenchmark.contains thrpt 20 220.480 ± 1.266 ops/us
MyBenchmark.containsExplicit thrpt 20 219.962 ± 2.329 ops/us
MyBenchmark.indexOf thrpt 20 219.706 ± 2.401 ops/us
MyBenchmark.matches thrpt 20 3.766 ± 0.026 ops/us
for循环并重新测试。此外，“second”对于这样的测试来说时间范围太大了 - 切换到微秒或毫秒。此外，JVM可能会忽略第二个片段中的断言，并因此优化整个循环，这就是第一个片段中发生的事情。 - Svetlin Zarev-ea参数来运行，但是除此之外，assert似乎可以强制HotSpot不要优化整个调用。 - ipsiindexOf是Hotspot JVM内在方法的示例。这意味着java.lang.String中的Java代码根本不用于此方法。有此方法的特殊本机版本。您可以在此处找到此类方法的列表：do_intrinsic(_indexOf
contains()方法看起来比实际上慢。 - Kayaman