池化PropertyChangedEventArgs对象是否有收益？技术咨询

一、池化的收益是否存在？ #

答案是分场景判断：

• 高频率属性变更场景（比如实时数据更新、大量列表项属性频繁变化的WPF/MAUI界面）：PropertyChangedEventArgs作为轻量对象，频繁创建会产生大量Gen 0垃圾，GC需要频繁执行小回收，此时池化能显著降低GC压力、提升应用响应性，收益非常明显。
• 低频率变更场景（比如用户手动修改表单字段）：单次创建EventArgs的开销远低于ConcurrentDictionary的查找/插入开销，池化的收益可以忽略，甚至可能因为字典操作增加额外CPU负载，得不偿失。

你示例中用ConcurrentDictionary做池是合理的，它能安全处理多线程下的并发访问（比如后台线程更新属性、UI线程监听变更）。

二、String.GetHashCode()的性能问题优化 #

你提到的String.GetHashCode()重复计算确实是ConcurrentDictionary.GetOrAdd()的潜在开销，可通过以下方式优化：

1. 利用字符串驻留（String Intern） #

.NET的字符串驻留池会确保相同内容的字符串共享同一个实例，且**.NET Core 2.1+中，String实例会缓存自身的哈希值**——第一次调用GetHashCode()后，后续调用直接返回缓存值，无需重复计算。

修改代码，在传入属性名时进行驻留：

protected void OnPropertyChanged([CallerMemberName] string? propertyName = null)
{
    if (propertyName == null) return;
    var internedName = string.Intern(propertyName);
    var arg = _pool.GetOrAdd(internedName, name => new PropertyChangedEventArgs(name));
    PropertyChanged?.Invoke(this, arg);
}

这样相同属性名的字符串会被驻留为同一个实例，哈希值仅在第一次计算时产生开销，后续所有调用都复用缓存值。

2. 指定高效的字符串比较器 #

ConcurrentDictionary默认使用EqualityComparer<string>.Default，该比较器受当前文化影响，哈希计算相对较慢。改用StringComparer.Ordinal（基于字节的无文化依赖比较），能大幅提升哈希计算和相等性检查的速度：

private readonly static ConcurrentDictionary<string, PropertyChangedEventArgs> _pool 
    = new(StringComparer.Ordinal);

3. 预创建属性对应的EventArgs（适合属性固定的类） #

如果你的ObservableObject子类属性数量固定且可预知，可以在类初始化时通过反射预创建所有属性的EventArgs，彻底避免运行时的字典查找开销：

public class MyViewModel : ObservableObject
{
    private static readonly Dictionary<string, PropertyChangedEventArgs> _preCreatedArgs;

    static MyViewModel()
    {
        _preCreatedArgs = typeof(MyViewModel)
            .GetProperties(BindingFlags.Public | BindingFlags.Instance)
            .ToDictionary(p => p.Name, p => new PropertyChangedEventArgs(p.Name));
    }

    protected override void OnPropertyChanged([CallerMemberName] string? propertyName = null)
    {
        if (propertyName != null && _preCreatedArgs.TryGetValue(propertyName, out var arg))
        {
            PropertyChanged?.Invoke(this, arg);
        }
    }
}

这种方式完全消除了运行时的哈希计算和字典并发操作，但仅适合属性固定的场景，反射的初始化开销一次性支付，后续无额外成本。

三、总结 #

• 池化PropertyChangedEventArgs在高频变更场景下收益显著，低频场景可考虑放弃以减少额外开销；
• 针对哈希计算的问题，优先使用字符串驻留+Ordinal比较器的组合，这是通用且高效的优化方案；
• 若属性固定，预创建EventArgs是性能最优的选择。

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