将 null 检查替换为可选

Question

I would like to know since i'm fan of java 14 if replacing null checks with Optional.ofNullable is safe for this language. I know a simple null check doesn't cost any memory while new creating new objects like optional cost but i guess it has zero performance impact or memory impact. Can someone enlight me?

The code for my game was like:

if (item!= null)
{
   if (item.getCrystal() == Crystal.A)
   {
     player.getInventory().addItem(inventoryItem);
   }
}

to something which i enjoy and i find cool

Optional.ofNullable(item).filter(i -> i.getCrystal() == Crystal.A).ifPresent(k -> player.getInventory.addItem(i));

Can someone enlight me that i'm ok with it? Maybe is cool but cost a lot? I don't know. Thanks a lot.

Answer 1

In simple cases like this, the just in time compiler can likely elide the object allocation, or at least allocate it on the stack, so the overhead is negligible.

Here's a small benchmark:

public abstract class Benchmark {

    final String name;

    public Benchmark(String name) {
        this.name = name;
    }

    @Override
    public String toString() {
        return name + "\t" + time() + " ns / iteration";
    }

    private BigDecimal time() {
        try {
            // automatically detect a reasonable iteration count (and trigger just in time compilation of the code under test)
            int iterations;
            long duration = 0;
            for (iterations = 1; iterations < 1_000_000_000 && duration < 1_000_000_000; iterations *= 2) {
                long start = System.nanoTime();
                run(iterations);
                duration = System.nanoTime() - start;
                cleanup();
            }
            return new BigDecimal((duration) * 1000 / iterations).movePointLeft(3);
        } catch (Throwable e) {
            throw new RuntimeException(e);
        }
    }

    /**
     * Executes the code under test.
     * @param iterations
     *            number of iterations to perform
     * @return any value that requires the entire code to be executed (to
     *         prevent dead code elimination by the just in time compiler)
     * @throws Throwable
     *             if the test could not complete successfully
     */
    protected abstract Object run(int iterations) throws Throwable;
    
    /**
     * Cleans up after a run, setting the stage for the next.
     */
    protected void cleanup() {
        // do nothing
    }

    public static void main(String[] args) throws Exception {
        Integer[] a = {null, -1, null, 1}; // mix nulls and real values
        
        System.out.println(new Benchmark("Optional") {
            @Override
            protected Object run(int iterations) throws Throwable {
                int[] sum = {0};
                for (int i = 0; i < iterations; i++) {
                    Optional.ofNullable(a[i & 3]).filter(k -> k > 0).ifPresent(k -> sum[0] += k);
                }
                return sum[0]; 
            }
        });
        System.out.println(new Benchmark("if != null") {
            @Override
            protected Object run(int iterations) throws Throwable {
                int[] sum = {0};
                for (int i = 0; i < iterations; i++) {
                    var k = a[i & 3];
                    if (k != null && k % 2 != 0) {
                        sum[0] += k; 
                    }
                }
                return sum[0]; 
            }
        });
    }
}

This shows that the overhead of using an Optional is about 1 ns, ie a modern CPU can construct and evaluate about 1 billion Optional objects per second. In all but the most extreme and contrived of workloads, the use of Optional will not affect performance enough for humans to notice.

The decision to use Optional should therefore not be guided by performance considerations, but by which version allows yourself to express yourself more clearly and simply.

In this case, I'd argue that the if statement is actually more readable. Sure, you've squashed everything onto a single line, but you could do the same with an if statement:

if (item != null && item.getCrystal() == Crystal.A) player.getInventory().addItem(inventoryItem);

If you do that, you'll notice that the if statement is actually shorter and more to the point than your version:

Optional.ofNullable(item).filter(i -> i.getCrystal() == Crystal.A).ifPresent(k -> player.getInventory.addItem(i));

Of course, in real code you'll probably want to keep your lines reasonably short, so the comparison is

if (item != null && item.getCrystal() == Crystal.A) {
    player.getInventory().addItem(inventoryItem);
}

vs

Optional.ofNullable(item).filter(i -> i.getCrystal() == Crystal.A)
    .ifPresent(k -> player.getInventory.addItem(i));

Again, I find the first version more readable, because it contains fewer words.