我最近被问及java 8 Optional的性能。经过一番搜索后，我发现了this question和几篇博文，但答案相互矛盾。所以我使用JMH对它进行基准测试，我不明白我的发现。
以下是我的基准代码的要点（GitHub上提供了full code）：
@State(Scope.Benchmark)
public class OptionalBenchmark {
private Room room;
@Param({ "empty", "small", "large", "full" })
private String filling;
@Setup
public void setUp () {
switch (filling) {
case "empty":
room = null;
break;
case "small":
room = new Room(new Flat(new Floor(null)));
break;
case "large":
room = new Room(new Flat(new Floor(new Building(new Block(new District(null))))));
break;
case "full":
room = new Room(new Flat(new Floor(new Building(new Block(new District(new City(new Country("France"))))))));
break;
default:
throw new IllegalStateException("Unsupported filling.");
}
}
@Benchmark
public String nullChecks () {
if (room == null) {
return null;
}
Flat flat = room.getFlat();
if (flat == null) {
return null;
}
Floor floor = flat.getFloor();
if (floor == null) {
return null;
}
Building building = floor.getBuilding();
if (building == null) {
return null;
}
Block block = building.getBlock();
if (block == null) {
return null;
}
District district = block.getDistrict();
if (district == null) {
return null;
}
City city = district.getCity();
if (city == null) {
return null;
}
Country country = city.getCountry();
if (country == null) {
return null;
}
return country.getName();
}
@Benchmark
public String optionalsWithMethodRefs () {
return Optional.ofNullable (room)
.map (Room::getFlat)
.map (Flat::getFloor)
.map (Floor::getBuilding)
.map (Building::getBlock)
.map (Block::getDistrict)
.map (District::getCity)
.map (City::getCountry)
.map (Country::getName)
.orElse (null);
}
@Benchmark
public String optionalsWithLambdas () {
return Optional.ofNullable (room)
.map (room -> room.getFlat ())
.map (flat -> flat.getFloor ())
.map (floor -> floor.getBuilding ())
.map (building -> building.getBlock ())
.map (block -> block.getDistrict ())
.map (district -> district.getCity ())
.map (city -> city.getCountry ())
.map (country -> country.getName ())
.orElse (null);
}
}
我得到的结果是：
Benchmark (filling) Mode Cnt Score Error Units
OptionalBenchmark.nullChecks empty thrpt 200 468835378.093 ± 895576.864 ops/s
OptionalBenchmark.nullChecks small thrpt 200 306602013.907 ± 136966.520 ops/s
OptionalBenchmark.nullChecks large thrpt 200 259996142.619 ± 307584.215 ops/s
OptionalBenchmark.nullChecks full thrpt 200 275954974.981 ± 4154597.959 ops/s
OptionalBenchmark.optionalsWithLambdas empty thrpt 200 460491457.335 ± 322920.650 ops/s
OptionalBenchmark.optionalsWithLambdas small thrpt 200 98604468.453 ± 68320.074 ops/s
OptionalBenchmark.optionalsWithLambdas large thrpt 200 67648427.470 ± 206810.285 ops/s
OptionalBenchmark.optionalsWithLambdas full thrpt 200 167124820.392 ± 1229924.561 ops/s
OptionalBenchmark.optionalsWithMethodRefs empty thrpt 200 460690135.554 ± 273853.568 ops/s
OptionalBenchmark.optionalsWithMethodRefs small thrpt 200 98639064.680 ± 56848.805 ops/s
OptionalBenchmark.optionalsWithMethodRefs large thrpt 200 68138436.113 ± 158409.539 ops/s
OptionalBenchmark.optionalsWithMethodRefs full thrpt 200 169603006.971 ± 52646.423 ops/s
首先，当给出空引用时，Optional和null检查的行为几乎相同。我想这是因为Optional.empty ()只有一个实例，所以对它的任何.map ()方法调用都会返回它自己。
但是，当给定对象为非null并且包含一系列非空属性时，必须在每次调用.map ()时实例化一个新的Optional。因此，与空检查相比，性能下降得更快。说得通。期待我的full填充，其中表现突然增加。那么这里的魔力是什么？我在基准测试中做错了吗？
我第一次运行的参数是JMH的默认参数：每个基准测试在10个不同的分支中运行，20个预热迭代，每个1秒，然后20个测量迭代，每个1秒。我相信这些价值是理智的，因为我相信我使用的库。然而，由于我被告知我没有足够的热身，所以这是更长时间测试的结果（200次预热迭代和10次分析中每一次的200次测量迭代）：
# JMH version: 1.19
# VM version: JDK 1.8.0_152, VM 25.152-b16
# VM invoker: /Library/Java/JavaVirtualMachines/jdk1.8.0_152.jdk/Contents/Home/jre/bin/java
# VM options: <none>
# Warmup: 200 iterations, 1 s each
# Measurement: 200 iterations, 1 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Run complete. Total time: 17:49:25
Benchmark (filling) Mode Cnt Score Error Units
OptionalBenchmark.nullChecks empty thrpt 2000 471803721.972 ± 116120.114 ops/s
OptionalBenchmark.nullChecks small thrpt 2000 289181482.246 ± 3967502.916 ops/s
OptionalBenchmark.nullChecks large thrpt 2000 260222478.406 ± 105074.121 ops/s
OptionalBenchmark.nullChecks full thrpt 2000 282487728.710 ± 71214.637 ops/s
OptionalBenchmark.optionalsWithLambdas empty thrpt 2000 460931830.242 ± 335263.946 ops/s
OptionalBenchmark.optionalsWithLambdas small thrpt 2000 98688943.879 ± 20485.863 ops/s
OptionalBenchmark.optionalsWithLambdas large thrpt 2000 67262330.106 ± 50465.262 ops/s
OptionalBenchmark.optionalsWithLambdas full thrpt 2000 168070919.770 ± 352435.666 ops/s
OptionalBenchmark.optionalsWithMethodRefs empty thrpt 2000 460998599.579 ± 85063.337 ops/s
OptionalBenchmark.optionalsWithMethodRefs small thrpt 2000 98707338.408 ± 17231.648 ops/s
OptionalBenchmark.optionalsWithMethodRefs large thrpt 2000 68052673.021 ± 55285.427 ops/s
OptionalBenchmark.optionalsWithMethodRefs full thrpt 2000 169259067.479 ± 174402.212 ops/s
如您所见，我们的数字几乎相同。
答案 0 :(得分：8)
即使像JMH这样强大的工具也无法从所有基准测试陷阱中拯救出来。 我发现这个基准有两个不同的问题。
HotSpot JIT编译器根据运行时配置文件推测性地优化代码。在给定的“完整”方案中Optional永远不会看到null值。这就是为什么Optional.ofNullable方法（也由Optional.map调用）恰好针对构造新的非空Optional的非空路径进行优化的原因。在这种情况下，JIT能够消除所有短期分配并执行所有map操作而无需中间对象。
public static <T> Optional<T> ofNullable(T value) {
return value == null ? empty() : of(value);
}
在“小”和“大”场景中，映射序列最终以Optional.empty()结束。也就是说，ofNullable方法的两个分支都被编译，JIT不再能够消除中间Optional对象的分配 - 数据流图对于Escape Analysis来说似乎太复杂了。
通过使用-prof gc运行JMH来检查它，并且您将看到“small”每次迭代分配48个字节（3个Optionals），“large”分配96个字节（6个Optionals），并且“full”分配什么都没有。
Benchmark (filling) Mode Cnt Score Error Units
OptionalBenchmark.optionalsWithMethodRefs:·gc.alloc.rate.norm empty avgt 5 ≈ 10⁻⁶ B/op
OptionalBenchmark.optionalsWithMethodRefs:·gc.alloc.rate.norm small avgt 5 48,000 ± 0,001 B/op
OptionalBenchmark.optionalsWithMethodRefs:·gc.alloc.rate.norm large avgt 5 96,000 ± 0,001 B/op
OptionalBenchmark.optionalsWithMethodRefs:·gc.alloc.rate.norm full avgt 5 ≈ 10⁻⁵ B/op
如果您将new Country("France")替换为new Country(null)，则优化也会中断，而“完整”方案预计会慢于“小”和“大”。
或者，添加到setUp的以下虚拟循环也可以防止过度优化ofNullable，使基准测试结果更加真实。
for (int i = 0; i < 1000; i++) {
Optional.ofNullable(null);
}
令人惊讶的是，nullChecks基准测试在“完整”方案中也显得更快。这里的原因是类初始化障碍。请注意，只有“完整”大小写才会初始化所有相关类。在“小”和“大”情况下nullChecks方法引用了一些尚未初始化的类。这可以防止有效地编译nullChecks。
如果您明确初始化setUp中的所有类，例如通过创建一个虚拟对象，nullChecks的“空”，“小”和“大”场景将变得更快。
Room dummy = new Room(new Flat(new Floor(new Building(new Block(new District(new City(new Country("France"))))))))