PHP session并发请求覆盖数据的锁定处理方案

同一用户连续发起两个 PHP 请求时，如果两个脚本都调用了 session_start()，第二个请求变慢并不一定是数据库慢。对默认文件型 Session 来说，打开会话后会先占住共享 Session 数据，直到脚本结束或显式关闭；第一个请求若还在等待远程接口、渲染页面，第二个请求就会排队。

处理这类问题的关键不是盲目换 Session 存储，而是先缩短锁定区间：只读请求读完立即关闭，需要写入的请求只在更新 $_SESSION 时持有锁，慢业务放到关闭之后。这样能解决“无关请求互相阻塞”，但不能自动解决两个请求同时修改同一个键的业务冲突。

一、先还原“请求互相卡住”的现场

先记录请求进入、调用 session_start()、完成 Session 读取以及释放 Session 的时间。若第二个请求在 Session 初始化之后长时间没有进入控制器主体，而第一个请求此时正在执行远程调用或大查询，优先怀疑 Session 锁等待。

典型故障链是：请求 A 读取会话后执行慢业务，请求 B 携带同一个 Session ID 到达；B 不是立即读取一份副本，而是等待 A 结束或释放会话。于是页面上的并行 AJAX 在服务端被串成一列，用户看到的是接口随机变慢，甚至误以为 PHP-FPM 或数据库连接池耗尽。

这里要注意“覆盖数据”的另一层含义：Session 锁可以保护一次读写过程不被同时改写，但如果两个请求先后读取旧值、释放锁、再基于旧值重新写回，业务层仍可能发生后写覆盖。锁解决的是存储访问的临界区，不等于自动提供业务版本控制。

二、触发条件与根因：打开会话太早，关闭会话太晚

最容易出现问题的代码通常把 session_start() 放在公共引导文件里，然后在整个请求生命周期内保持开启。登录态、语言偏好或用户编号可能只需要读取一次，但后面的 HTTP 调用、文件处理和模板渲染都在锁内完成。

 true]);
$userId = (int) ($_SESSION['user_id'] ?? 0);

// 慢业务不再持有 Session 锁，可继续做远程请求或查询。
$profile = loadProfileFromService($userId);
renderProfile($profile);

read_and_close 只适用于确定不会修改 Session 的路径。如果后续要刷新令牌、写入闪存消息或更新购物车，就不能把它当成“默认开启项”，否则后续对 $_SESSION 的修改不会按预期写回。

三、把读取和写入拆成两个边界

需要写入时，可以先完成读取和校验，再把真正的修改压缩到短区间内。修改完成后显式调用 session_write_close()，再执行不依赖 Session 写入的慢操作。示例中的订单号、状态和权限检查只是说明边界，实际业务应在关闭前完成所有需要原子判断的 Session 操作。

如果响应逻辑仍需要更新 Session，就不要在关闭后直接改数组。应把更新重新设计为关闭前完成，或在明确保存处理器和并发语义后重新开启会话；重复启动前先确认当前状态，避免把修复变成新的告警。

四、修复后的验证与并发覆盖边界

回归时不要只看单请求耗时。用同一个登录会话并行发起两个“一个慢、一个快”的请求，分别记录 Session 获取前后的时间。预期是：快请求不再因为慢请求的远程调用而持续等待；需要写入的请求仍按短临界区串行完成。

日志中建议至少保留请求标识、Session ID 的不可逆摘要、Session 打开时间、关闭时间和业务耗时，不要记录明文 Session ID。观察“等待时间”和“业务执行时间”是否分离，才能判断优化是否真的缩短了锁，而不是把等待转移到了别的资源。

五、常见误区与防复发清单

• 不要把 session_write_close() 当成并发写入合并器；它只负责写回当前 Session 并结束会话。
• 不要在只读路径关闭后继续刷新登录时间、CSRF 值或提示消息；这些修改需要重新安排到写入边界。
• 不要把所有请求都改成无锁读取；会话数据存在并发修改时，必须保留一致性策略。
• 不要用单次成功压测证明问题已消失；至少覆盖慢请求、异常退出和两个请求同时改同一键的场景。

相关问题

关闭 Session 后还能直接修改 $_SESSION 吗？

可以修改进程内数组，但关闭后这些修改不会自动写回当前会话。需要保存时，应在明确的重新开启与并发策略下写入，或把状态放到更适合原子更新的存储中。

read_and_close 和 session_write_close() 怎么选？

前者适合从一开始就确定只读的请求，后者适合已经开启会话并完成必要修改的请求。两者共同目标都是缩短 Session 占用时间，但不能替代业务层的数据冲突设计。