PHP Session 锁为什么会阻塞并发请求，怎样缩短持锁时间

同一个用户同时发起两个 PHP 请求时，如果它们携带同一个 Session ID，第二个请求变慢往往不是 PHP-FPM 线程不够，而是第一个请求还握着 Session 锁。默认文件会话在 session_start() 后读取并锁定会话文件，直到脚本结束或显式关闭。缩短持锁时间的核心是：只读就读完即关，有写入就先提交再做慢业务。

官方地址：https://www.php.net/manual/en/

PHP Session 锁为什么会把并发请求排成队

文件 Session 的锁以会话为粒度，而不是以某个数组字段为粒度。请求 A 调用 session_start() 后，即使后面只是等待远程接口，使用同一 Session ID 的请求 B 也可能卡在自己的 session_start()。所以浏览器里“一个页面多个 AJAX 一起发出”，服务端却呈现串行等待。

先看时间关系，而不要只盯着业务日志：A 的开始时间到释放时间是持锁区间；B 的开始时间到真正进入控制器之间是锁等待区间。两者都慢时，先缩短 A 的持锁区间。

只读请求用 read_and_close 立即放锁

如果页面只读取用户语言、登录标记或展示偏好，不要让 PHP 把锁保持到脚本结束。session_start() 接收 read_and_close 后，会话读完就关闭；后续可以读取已经载入的 $_SESSION，但不能再依赖它写回数据。

 true,
]);

// 这里可以渲染页面或执行查询，不再占用该用户的 Session 锁。
$locale = $_SESSION['locale'] ?? 'zh-CN';
echo htmlspecialchars($locale, ENT_QUOTES, 'UTF-8');

这个选项不是“并发读写都安全”的开关。如果后面给 $_SESSION 赋值，值不会按预期持久化；需要修改时应使用普通启动、完成写入，再显式关闭。

写入会话后立刻结束持锁区间

登录成功、刷新 CSRF 标记或记录一次性提示时，真正需要锁的通常只有几行。把远程 API、复杂查询、文件处理放到关闭之后。session_write_close() 会写回当前会话并结束会话处理；它不是数据库事务提交，不能代替业务数据的一致性控制。

若业务确实要在慢操作后再次修改会话，可以在确认数据后重新开启一个很短的窗口。但第二次读取可能已经落后于其他请求，适合写入“结果通知”这类可覆盖字段，不适合直接覆盖购物车、额度等关键集合。

用这张表判断应该怎么改

生产排查时给 session_start 前后各记一个时间点，再记录 session_write_close 的时间点，便能把等待、持锁和业务耗时分开。不要为了消除等待而关闭锁后继续修改同一份数组，也不要把 Session 锁误当成库存扣减锁。

常见问题

调用 read_and_close 后还能写 $_SESSION 吗？

不应这样设计。它面向只读请求，后续赋值不会形成可靠的持久化写回；需要写入就改用普通 session_start()，写完尽早关闭。

换成 Redis Session 就没有锁了吗？

不一定。锁语义取决于保存处理器及其配置，换存储后仍要确认并发读写语义，不能仅凭“Redis 更快”判断没有阻塞。

session_write_close 会保护数据库更新吗？

不会。它只结束 PHP 会话处理；数据库更新应使用事务、唯一约束或版本控制来解决并发覆盖。