多线程数据清洗中直接修改全局类属性会导致竞态条件，因其“读—改—写”非原子操作且缺乏同步保护；应采用原子类型、加锁或线程局部存储等线程安全方案。
因为在数据清洗的条件块中直接修改全局类属性，本质上仍是“读—改—写”三步非原子操作，而多线程环境下缺乏同步保护时，多个线程可能交错执行，导致中间状态被覆盖或丢失。
条件判断不等于线程安全
比如代码中写 if is_valid(row): stats.total_count += 1，看似只有满足校验才累加，但 stats.total_count += 1 实际分解为：从内存读取当前值 → CPU 加 1 → 写回内存。条件判断（is_valid）和属性修改（+=）之间没有原子绑定，线程 A 读完旧值后被挂起，线程 B 同样通过校验并完成整个加法，等 A 恢复后仍用旧值计算并写回，结果就丢失了一次更新。
全局类属性本质是共享变量
类属性（如 MyCleaner.error_count）在多线程中默认被所有实例共享，它不是线程局部存储。只要多个清洗线程共用同一个类或未做隔离，对该属性的任何写操作都面临竞态风险。即使每个线程处理不同数据分片，只要最终汇总逻辑依赖该全局属性，冲突就可能发生。
数据清洗场景加剧并发窗口
- 清洗常使用多线程/多进程加速（如 Python 的 concurrent.futures 或 Spark 分区任务）
- 条件块高频出现（空值判断、格式校验、业务规则过滤），导致大量线程反复进入同一修改路径
- 日志计数、错误统计、去重缓存等常用全局属性，恰恰是典型竞态目标
正确做法不是避免条件，而是保护修改
关键不在“是否在 if 里改”，而在“怎么改”。推荐方式包括：
- 用线程安全的原子类型，如 threading.AtomicInteger（Java）或 queue.Queue 做计数中转（Python）
- 对共享属性加锁，例如用 threading.Lock() 包裹修改段
- 改用线程局部存储（threading.local()），各线程维护独立副本，最后再合并
- 在分布式清洗中（如 Spark），优先使用 accumulator（累加器）而非手动更新全局变量
