Java PropertyChangeSupport 新旧值相等时为什么可能不触发通知

如果 setter 已经执行，监听器却没有收到 PropertyChangeEvent，先不要急着怀疑线程或监听器注册。PropertyChangeSupport 的对象重载有一个容易忽略的短路规则：当旧值和新值都不为 null，并且二者按 equals 判断相等时，不会派发事件。

官方文档：https://docs.oracle.com/en/java/javase/25/docs/api/java.desktop/java/beans/PropertyChangeSupport.html

这意味着“setter 被调用”和“属性变更通知被发送”不是同一件事。本文用一个最小 Bean 场景拆开这条路径，并说明什么时候应该保留默认语义，什么时候要把业务变化单独建模。

先看 setter 里真正发生了什么

常见写法是先保存旧值，再给字段赋值，最后调用 firePropertyChange。这一套顺序仍然正确，但最后一步是否通知监听器由 PropertyChangeSupport 决定。

public final class Profile {
    private final PropertyChangeSupport changes = new PropertyChangeSupport(this);
    private String displayName;

    public void addPropertyChangeListener(PropertyChangeListener listener) {
        // 对外暴露统一入口，监听器只关心属性事件，不接触内部字段。
        changes.addPropertyChangeListener(listener);
    }

    public void setDisplayName(String newName) {
        String oldName = displayName;
        displayName = newName;

        // 这里传入的是 Object 重载；相等且非 null 时，支持类会停止派发。
        changes.firePropertyChange("displayName", oldName, newName);
    }
}

因此，下面两行虽然都会执行赋值，但第二次可能没有回调：

profile.setDisplayName("Lin");
profile.setDisplayName(new String("Lin")); // 内容相等，默认不会再次通知

第二个字符串不是同一个引用，但 String.equals 返回 true。对绑定属性来说，这通常是有意的去重：监听器只需要处理“可观察值真的变了”的情况。

对象重载比较的是值，不是引用地址

对 firePropertyChange(String, Object, Object) 而言，关键不是 oldValue == newValue，而是对象是否按 equals 相等。自定义值对象如果把两个实例视为相等，通知也会被抑制。

record Theme(String name, int fontSize) {}

Theme oldTheme = new Theme("dark", 14);
Theme newTheme = new Theme("dark", 14);

// record 自动按组件比较 equals；两个对象内容相同，因此不会派发事件。
changes.firePropertyChange("theme", oldTheme, newTheme);

这也是排查“明明 new 了一个对象却没通知”时最重要的判断点：新对象不代表新值。首先查对象的 equals 实现，再确认监听器是否真正需要“重新计算”这个动作。

null、基本类型和 indexed 属性有什么不同

对象重载的规则可以压缩成一张表：

整型和布尔型有专门的重载，比较的是基本值是否相等，不会因为装箱对象的引用差异而改变结果。indexed 重载同样遵循“相等且非 null 时不派发”的原则，只是额外携带一个数组或列表下标。

为什么业务上会觉得“应该通知”

常见冲突来自把两种语义混在了同一个属性里：

• 值变化语义：只关心显示内容或配置值变化，重复赋相同值不需要刷新。
• 动作发生语义：每次保存、重新加载、重新计算都需要触发一次，即使结果对象相等。

PropertyChangeSupport 默认服务第一种语义。若业务需要第二种语义，强行修改 equals 往往会让集合、缓存和比较逻辑一起变得不可靠，更稳妥的是把动作建模成独立事件，或增加真正变化的版本字段。

public void reloadTheme() {
    Theme oldTheme = theme;
    Theme loaded = loadTheme();
    theme = loaded;

    // 业务需要每次 reload 都可观察，因此把 reloadCount 作为变化信号。
    long oldCount = reloadCount;
    reloadCount++;
    changes.firePropertyChange("theme", oldTheme, loaded);
    changes.firePropertyChange("reloadCount", oldCount, reloadCount);
}

如果你只想通知一次“reload 已完成”，也可以定义明确的领域事件，而不是借用属性变化事件表达动作。这样监听器能区分“值变了”和“动作完成了”。

用最小测试确认问题在哪一层

排查时建议同时记录 setter 调用次数和监听器回调次数，再覆盖四组输入。下面的监听器只打印事件字段，注释说明了测试意图。

AtomicInteger callbacks = new AtomicInteger();
profile.addPropertyChangeListener(event -> {
    // 用计数器确认是否真的进入监听器，而不是只看字段值。
    callbacks.incrementAndGet();
    System.out.println(event.getPropertyName() + ": "
            + event.getOldValue() + " -> " + event.getNewValue());
});

profile.setDisplayName("Lin");       // null -> value，应收到通知
profile.setDisplayName(new String("Lin")); // equals 相等，不应重复通知
profile.setDisplayName("Lina");      // 内容不同，应收到通知
profile.setDisplayName(null);         // value -> null，应收到通知

若结果和预期不符，再按顺序检查：属性名是否完全一致、监听器是否注册在同一个 Bean 实例上、是否误用了只监听指定属性的重载，以及自定义值对象的 equals 是否把业务上不同的状态判成相等。

最后的判断清单

这类问题可以用三句话快速归因：

1. setter 执行只说明字段写入，不保证事件派发。
2. 对象重载遇到两个非 null 且 equals 相等的值会短路；基本类型重载按基本值比较。
3. 如果需要“每次动作都通知”，请增加动作或版本信号，不要破坏值对象的相等契约。

相关问题：自定义对象的 equals 应该包含哪些字段？如何区分全局监听器和属性级监听器？如果监听器回调里再次修改属性，应该怎样避免循环通知？