当多个php请求并发读写同一文件（如number.txt）时，若无同步机制，将因“读-改-写”非原子性导致中间值被覆盖，最终结果不可预测——典型竞态条件，轻则数据丢失，重则业务逻辑崩溃。
当多个php请求并发读写同一文件（如number.txt）时，若无同步机制，将因“读-改-写”非原子性导致中间值被覆盖，最终结果不可预测——典型竞态条件，轻则数据丢失，重则业务逻辑崩溃。
你提出的场景——两个用户几乎同时执行 get_file → 修改 → save_file 流程——正是竞态条件（Race Condition）的经典体现。答案很明确：最终文件中保存的极大概率是“8”，而非预期的“15”。
为什么结果是“8”？——底层执行时序拆解
PHP脚本默认以独立进程/线程运行（取决于Web服务器配置，如Apache的prefork或FPM的多进程模型），彼此不共享内存。但它们共享同一份磁盘文件。关键问题在于：$num = get_file('number.txt') 和 save_file($num, 'number.txt') 是两个分离的I/O操作，中间存在时间窗口：
// 用户1执行：
$num = (int)file_get_contents('number.txt'); // 读出 0
// ← 此刻用户2也执行到这里，同样读出 0
$num += 7; // 用户1算得 7
$num += 8; // 用户2算得 8（基于旧值0）
file_put_contents('number.txt', (string)$num); // 用户1写入 "7"
file_put_contents('number.txt', (string)$num); // 用户2写入 "8" —— 覆盖前值
这正是典型的 Read-Modify-Write 竞态：两次“读取→计算→写入”流程交错执行，导致一次增量永久丢失。其本质不是PHP本身的问题，而是缺乏对共享资源（文件）的并发访问控制。
✅ 正确解决方案：从文件锁到事务化设计
方案1：使用 flock() 实现文件级互斥（推荐轻量场景）
$fp = fopen('number.txt', 'c+'); // 以读写方式打开，必要时创建
if (flock($fp, LOCK_EX)) { // 获取独占锁（阻塞等待）
$num = (int)stream_get_contents($fp, -1, 0);
rewind($fp);
ftruncate($fp, 0);
$num += (int)$_POST['add'];
fwrite($fp, (string)$num);
fflush($fp);
flock($fp, LOCK_UN); // 释放锁
} else {
throw new RuntimeException('无法获取文件锁');
}
fclose($fp);
⚠️ 注意：flock() 依赖底层文件系统支持，在NFS等网络文件系统中可能失效；且需确保所有访问该文件的代码均统一加锁。
方案2：迁移到数据库 + 事务（生产环境首选）
文件不适合高并发计数。应使用支持ACID的数据库（如MySQL InnoDB）：
try {
$pdo->beginTransaction();
// 使用 SELECT ... FOR UPDATE 实现行级锁
$stmt = $pdo->prepare("SELECT value FROM counters WHERE name = 'global_num' FOR UPDATE");
$stmt->execute(['name' => 'global_num']);
$row = $stmt->fetch(PDO::FETCH_ASSOC);
$newVal = ($row['value'] ?? 0) + (int)$_POST['add'];
$update = $pdo->prepare("UPDATE counters SET value = ? WHERE name = ?");
$update->execute([$newVal, 'global_num']);
$pdo->commit();
echo "更新成功：{$newVal}";
} catch (Exception $e) {
$pdo->rollback();
throw $e;
}
✅ 优势：原子性由数据库引擎保障；支持隔离级别控制；天然可扩展、可监控、可回滚。
方案3：引入Redis原子操作（高性能计数场景）
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
// INCRBY 原子递增，完全规避竞态
$newVal = $redis->incrBy('counter:global_num', (int)$_POST['add']);
echo "当前值：{$newVal}";
✅ Redis的INCRBY是单命令原子执行，毫秒级响应，适合高频计数、限流、库存扣减等场景。
❌ 不推荐的“伪解决方案”
- 仅用file_put_contents(..., FILE_APPEND)：无法解决读取旧值再计算的问题；
- 前端防重复提交：仅缓解用户体验，后端仍可能并发；
- sleep()或随机延迟：治标不治本，概率性失败仍存在。
总结：竞态条件的本质与应对原则
| 维度 | 关键认知 |
|---|---|
| 根源 | 共享资源 + 非原子操作 + 缺乏同步机制 → 结果依赖执行时序 |
| 识别信号 | 数据“莫名丢失”、数值小于理论和、日志中出现重复处理记录 |
| 设计准则 | “宁锁勿猜”：凡涉及共享状态读-改-写，必须显式同步；优先选用原子原语（DB事务、Redis命令、CAS等）而非自实现锁 |
| 技术选型建议 | 文件 → 仅用于低频配置；计数/状态 → 数据库或Redis；缓存 → 使用apcu或memcached并配合版本号 |
真正的线程安全（或更准确地说——请求安全）不在于语言特性，而在于开发者是否主动为共享状态建立确定性的访问秩序。在2026年的现代Web架构中，放弃裸文件操作、拥抱原子化存储服务，已是保障数据一致性的基本工程素养。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
