ObservableCollection多线程异常：目标数组长度不足问题排查

核心误解：ObservableCollection并非线程安全 #

你使用的BindingOperations.EnableCollectionSynchronization仅负责协调WPF绑定系统访问集合时的线程安全，避免UI线程与后台线程触发绑定更新时的冲突，但它不会自动为你所有的集合修改操作加锁。ObservableCollection本身的内部结构（如底层存储数组）没有做线程安全设计，并发修改和读取依然会引发状态不一致问题。

崩溃原因 #

你遇到的ArgumentException（目标数组长度不足），本质是并发场景下的集合状态冲突：

• 后台线程正在修改_measures（添加/删除元素），导致集合实际长度动态变化；
• 同时WPF的DataGrid绑定系统正尝试复制集合内容到临时数组用于UI渲染，此时复制操作初始获取的集合长度，和实际复制时的集合长度不匹配，最终抛出该异常。
• 堆栈仅显示Main()是因为异常在WPF内部绑定执行逻辑中抛出，只有顶层入口属于你的代码。

修复方案 #

所有对_measures的修改操作（包括Add、Remove、Clear、Insert等），必须手动通过_measuresLock加锁，确保修改与读取操作互斥：

// 后台线程中修改集合的示例
lock(_measuresLock)
{
    _measures.Add(new MsgMeasure());
    // 批量操作也应放在锁内，减少锁持有时间
    // foreach(var item in prebuiltItems) _measures.Add(item);
}

如果是高频批量更新场景，建议：

1. 先在锁外构建好待添加的元素集合；
2. 再进入锁内一次性完成添加操作，缩短锁的持有时间，降低对实时处理性能的影响。

额外注意 #

• 不要依赖EnableCollectionSynchronization自动处理所有并发问题，它只覆盖WPF绑定系统的访问逻辑，不处理你自己的后台修改操作；
• 避免在UI线程执行耗时的集合修改（会导致界面卡顿），后台线程加锁修改是更适配实时场景的方案。

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