java - 较短的等于方法与较长的等于方法相同吗？

Question

这两个 equals 方法的行为是否相同？:

(“版本1”是eclipse ide生成的，“版本2”是我自己制作的。)

版本 1:

public boolean equals(Object obj) {
        if (this == obj)
            return true;
        if (obj == null)
            return false;
        if (!(obj instanceof CoreSale))
            return false;
        User other = (User) obj;
        return Objects.equals(id, other.id);
    }

版本 2(较短):

public boolean equals(Object obj) {
        // always return false, if not instance of User
        if (obj instanceof CoreSale){
        User other = (User) obj;
        return Objects.equals(id, other.id);
        }
        return false;

    }

obj instanceof CoreSale 是否隐式检查 this == obj 或者我是否也必须在版本 2 中声明它？

Answer 1

除了模糊的边缘情况¹之外，这两段代码应该给出相同的答案。

它们之间的实质性区别是:

1. this == obj 测试。
2. 显式obj == null测试。
3. 最终if测试

以相反的顺序处理它们。

我不希望您将其写为 obj instanceof Type 还是 !(obj instanceof type)。事实上，我希望 JIT 编译器能够根据分支通常采用的“方向”进行优化，并为这两种情况生成等效的代码。

instanceof 运算符隐式测试 null，因此不需要显式 obj == null 测试。但是，我希望 JIT 编译器能够识别这一点，并且不会生成 native 代码来检查 null 两次。

this == obj 测试正在为一种被认为是经常发生的情况实现显式“短路”。

• 边缘情况意味着，如果源代码/字节代码中尚未包含等效的短路逻辑，JIT 编译器将无法插入它。

• 目前尚不清楚短路是否会提高性能。这取决于这些对象之一与其自身进行比较的实际频率……以及这样做的成本。

简而言之，只有 this == other 测试可能会产生任何影响(在 JIT 编译之后)，并且它可能对性能有利，也可能没有。

但是......如果性能确实很重要，请对其进行基准测试......使用实际数据进行基准测试。

<小时/>

^{1 - 出现边缘情况是因为当 this.id 时 Objects.equals(id, other.id) 可能会抛出异常或给出错误的答案> 和 other.id 是同一个对象。这又取决于 id 实际运行时类型的 Object::equals(Object) 的实际实现。}