能否缓存getClass.hashCode()？JVM下相关技术疑问咨询

我在一个抽象类中实现了如下hashCode方法：

@MappedSuperclass
abstract class Some {

    @Override
    public boolean equals(final Object obj) {
        // ...
    }

    @Override
    public int hashCode() {
        return getClass().hashCode(); // TODO: cache, maybe?
    }
}

我有以下技术疑问：

1. 是否可以缓存getClass().hashCode()的返回值？
2. 在JVM运行期间，该值是否存在变更的可能性？
3. 这种做法是否属于过早优化？

问题1：是否可以缓存getClass().hashCode()的返回值？ #

完全可以缓存。你可以在抽象类中定义一个私有final的int字段，在构造方法中初始化时赋值为getClass().hashCode()，后续hashCode方法直接返回该字段值即可。示例代码如下：

@MappedSuperclass
abstract class Some {
    private final int classHashCode;

    protected Some() {
        this.classHashCode = getClass().hashCode();
    }

    @Override
    public boolean equals(final Object obj) {
        // ...
    }

    @Override
    public int hashCode() {
        return classHashCode;
    }
}

每个子类实例调用getClass()会拿到自身的Class对象，因此缓存的是对应子类的hashCode值，逻辑上完全成立。

问题2：在JVM运行期间，该值是否存在变更的可能性？ #

不可能变更。根据Java规范，Class对象在JVM的单次运行过程中是单例存在的，其hashCode值在初始化完成后就固定不变。除非使用自定义类加载器进行非常规的类重载操作，但正常业务场景下无需考虑这种极端情况。

问题3：这种做法是否属于过早优化？ #

取决于实际使用场景：

• 如果该类的实例会被高频调用hashCode方法（比如大量存入HashMap、HashSet等集合），缓存操作能减少少量方法调用开销——虽然getClass()和Class.hashCode()本身开销极低，但高频场景下仍能积少成多。
• 如果实例数量少、hashCode调用不频繁，这种优化就属于过早优化，保持原代码的简洁性反而更有价值。

内容的提问来源于stack exchange，提问作者Jin Kwon