getter 上的 @NotNull 注释是否对性能有重大影响？

Question

随机示例：在我的一个程序的源代码中，我有这个方法：

    public @NotNull Currency[] getCurrencies() {
        return this.currencies.values().toArray(new Currency[0]);
    }

在编译之后，我的 IDE (Intellij) 将其转换为以下内容：

    @NotNull
    public Currency[] getCurrencies() {
        Currency[] var10000 = (Currency[])this.currencies.values().toArray(new Currency[0]);
        if (var10000 == null) {
            $$$reportNull$$$0(4);
        }

        return var10000;
    }

this.currencies引用private final ConcurrentHashMap<String, Currency> currencies = new ConcurrentHashMap(); - 这意味着只有通过反射或宇宙射线导致位翻转，方法getCurrencies()才能返回null 。

• 我是否应该 - 在没有机会返回null的情况下 - 放弃使用@NotNull注释？
• 注释是否会对性能产生重大影响，或者注释的好处是否超过了性能影响？

谢谢

/编辑：我正在使用注释 package org.jetbrains.annotations

Answer 1

对你的吸气剂进行null检查有点奇怪。 在您调用 getter 时，您的 object 已经在 state 中，它不应该在其中。您可能希望在 setter 或构造函数的参数上使用@NotNull 。

您可以做的是为您的getCurrencies编写一个 JavaDoc。

/**
/* @return An array of currencies. Never null.
*/
public Currency[] getCurrencies() {}

但是记录一个方法不返回null是非常罕见的。 不返回null应该是黄金标准，如果一个方法可以返回null它应该被记录，而不是相反。 此外，我不希望返回一组数据（数组、列表等）的 getter 返回null 。 而是返回一个空的 object。

Answer 2

@NotNull不是编译器的注释。 编译器可能会使用这个注解并做一些额外的检查。 但是@NotNull是供人类阅读编译器检查的代码的注释。 在 Java 的许多问题中，迄今为止最大的问题是未经检查的null值随处可见。 在其他静态类型语言中，程序中任何地方的任何变量都可能根本不存在，并且违反了类型检查器可以提供的所有保证。

Kotlin 具有适当的可空类型。 Scala 的最新版本具有（选择加入）可为空的类型。 甚至 C# 的新版本也具有可为空的类型。 在 Java 中，@ @NotNull应该被视为函数合约的一部分，几乎是其类型的一部分。 你不是说“嘿，编译器，检查这是否是null ”。 你说“我保证这个 function 永远不会返回null ”并且编译器正在检查它，就像声明返回类型String保证你返回一个String一样。 删除@NotNull注释，因为您确定它是正确的，这无异于将所有返回类型更改为Object ，因为您知道函数返回的类型。 如果你认为

String getName(String prefix) { ... }

看起来比

Object getName(Object prefix) { ... }

那么你应该认为

@NotNull String getName(@NotNull String prefix) { ... }

看起来更好。 是更有力的保证。

Answer 3

根据需要使用@Nullable和@NotNull ； 这些注释仅用于改进 Kotlin 互操作性，但在 Java 中没有实际用途（至少我不知道）。 编译后它们什么都没有留下，因此相信这会影响性能是值得怀疑的。 当问这些基本的事情，但又关心性能时，这可能会建议重新考虑优先级。 Function > 性能；