条件块中修改全局变量仍存在竞态条件，因“读—改—写”非原子且无同步保护，多线程可能交错执行导致更新丢失；分支逻辑本身不提供线程互斥能力。
因为在条件块中修改全局变量，本质上仍是“读—改—写”三步非原子操作，而多线程环境下没有同步保护时，多个线程可能交错执行这三步，导致中间状态被覆盖或丢失。
条件块里的修改并不特殊，只是普通非原子操作
比如 if (flag) { counter++ }，看似有逻辑判断，但 counter++ 本身仍分解为：从内存/寄存器读取当前值 → 在 CPU 中加 1 → 写回内存。条件判断（flag）和修改（counter++）之间没有原子性绑定，线程可能在读完 flag 后被切走，另一线程也通过了同一条件，接着两者都对 counter 执行相同读—改—写流程，最终只生效一次。
条件判断和变量修改之间存在时间窗口
即使条件本身是线程安全的（如用 volatile 读 flag），只要修改目标变量（如 counter）未受保护，就存在竞态窗口。典型场景：
- 线程 A 判断
flag == true成立，准备执行counter++ - 线程 A 执行到“读
counter”后被调度暂停 - 线程 B 也判断
flag == true，完整执行counter++（写回 1） - 线程 A 恢复，用旧值（0）加 1，写回 1 —— 覆盖了线程 B 的结果
分支逻辑不等于同步保障
流程控制（if、else if、switch）只决定执行路径，不提供任何线程互斥能力。它既不能阻止其他线程进入同一代码块，也不能保证对共享变量的操作不可打断。是否并发冲突，取决于“有没有对被修改的变量加锁或使用原子操作”，而不是“代码写在哪个块里”。
常见误判：以为加了条件就安全了
开发者容易误以为“只有满足条件才改，所以不会乱”，但问题不在“谁该改”，而在“改的过程能否被干扰”。例如：
- 两个线程同时看到
status == READY - 都进入
if块，都执行processCount++ - 若未加锁，
processCount最终只 +1 而非 +2
这种丢失更新，正是竞态条件的典型表现。
