PHP 的 Session 机制是 Web 开发中最常用的状态保持方案，但大多数开发者只停留在 session_start() 和 $_SESSION 的调用层面。当并发请求、自定义存储或分布式部署出现问题时，对底层机制的理解就显得尤为关键。本文将从内核源码出发，深入剖析 Session 的存储结构、序列化策略以及并发锁的实现原理。
一、Session 的生命周期与存储抽象
PHP Session 的起点是 session_start()。当该函数被调用时，PHP 内核会依次执行以下操作：
- 读取
php.ini中的session.save_handler配置，确定存储后端 - 通过
PS_OPEN_FUNC打开存储介质 - 通过
PS_READ_FUNC读取当前 Session ID 对应的数据 - 反序列化数据并填充
$_SESSION超全局数组 - 注册关闭函数，在请求结束时通过
PS_WRITE_FUNC写回数据
PHP 内核通过 php_session_handle 结构体管理存储后端，核心定义在 ext/session/php_session.h 中：
typedef struct _php_ps_globals {
char *save_path;
char *session_name;
char *session_id;
int session_id_length;
mod_user_struct *mod_user;
int (*s_read)(char *key, char **val, int *vallen);
int (*s_write)(char *key, char *val, int vallen);
int (*s_destroy)(char *key);
int (*s_gc)(int maxlifetime);
// ...
} php_ps_globals;
每个存储后端（files、redis、memcached 等）本质上就是实现了这组函数指针。内置的 files 处理器将每个 Session 保存为 sess_<session_id> 文件，默认路径由 session.save_path 指定。
二、序列化机制：三种引擎的差异
Session 数据的序列化由 session.serialize_handler 控制，PHP 支持三种引擎：
1. php（默认引擎）
格式为 key|serialized_value，其中 serialized_value 使用 PHP 标准序列化格式。例如：
username|s:5:"admin";role|s:4:"user";
该引擎的优点是结构清晰、易于解析，但缺点是无法处理包含 | 字符的键名，且对二进制数据不友好。
2. php_binary
使用二进制格式存储键名长度和键名，后跟序列化值。格式为：
<键名长度(2字节)><键名><序列化值>
由于键名长度以二进制表示，该引擎可以安全处理任意字符的键名，但可读性差，调试困难。
3. php_serialize
PHP 5.5.4 引入，直接使用 serialize($_SESSION) 对整个数组进行序列化：
a:2:{s:8:"username";s:5:"admin";s:4:"role";s:4:"user";}
这是最安全的引擎，不存在键名冲突问题，也是推荐的自定义存储场景下的选择。
内核中序列化的核心实现在 ext/session/session.c 的 php_session_serialize() 函数中。值得注意的是，反序列化时如果 Session 数据被篡改，php 引擎可能触发对象注入漏洞（__wakeup / __destruct 魔术方法），而 php_serialize 引擎由于使用标准 unserialize()，配合 allowed_classes 参数可以更好地控制风险。
三、并发锁：文件锁的实现与局限
Session 并发问题的根源在于：同一个 Session ID 的多个请求同时读写同一个存储文件，可能导致数据覆盖。PHP 的 files 处理器默认使用 flock 排他锁 来解决这个问题。
具体流程如下：
PS_OPEN_FUNC打开文件时，以O_RDWR | O_CREAT模式打开PS_READ_FUNC读取前调用flock(fd, LOCK_EX)获取排他锁- 请求处理期间锁一直持有
PS_WRITE_FUNC写入完成后调用flock(fd, LOCK_UN)释放锁
这意味着：同一个 Session ID 的请求是串行执行的。如果某个请求处理时间过长（如调用外部 API），其他请求会被阻塞在 session_start() 处，直到锁释放。
这个机制带来两个典型问题：
问题一：Ajax 并发请求被串行化。 页面同时发起多个 Ajax 请求，如果都携带同一个 Session ID，它们会排队执行，严重影响性能。
问题二：session_write_close() 的必要性。 在长时间处理逻辑之前调用 session_write_close() 可以提前释放锁，让其他请求得以继续。这是优化 Session 并发性能最直接的手段。
对于 Redis 等存储后端，锁的实现方式不同。Redis 本身是单线程模型，但 PHP 的 Redis Session 处理器默认 不加锁，需要开发者通过 session.lazy_write 或自定义处理器来实现乐观锁或分布式锁。
四、Session ID 的生成与安全
Session ID 的默认生成算法基于 php_session_create_id()，使用哈希函数（默认 SHA-1 或 SHA-256，取决于 session.hash_function）对随机源进行哈希。随机源来自：
php_combined_lcg()：基于线性同余生成器- 系统熵源：
/dev/urandom或CryptGenRandom
在 PHP 7.1 之后，session.sid_length 和 session.sid_bits_per_character 成为可配置项，默认生成 26 字符、128 位熵的 ID，暴力破解难度极高。
但需要注意：如果 session.save_path 目录权限配置不当（如 777），攻击者可能通过文件系统直接读取 Session 文件，绕过 ID 猜测。因此生产环境应确保 Session 目录权限为 700 或 750。
五、自定义存储后端的实现要点
当使用 Redis、Memcached 或数据库作为 Session 存储时，需要实现 SessionHandlerInterface：
class RedisSessionHandler implements SessionHandlerInterface
{
public function open($savePath, $sessionName): bool { /* ... */ }
public function close(): bool { /* ... */ }
public function read($id): string { /* ... */ }
public function write($id, $data): bool { /* ... */ }
public function destroy($id): bool { /* ... */ }
public function gc($maxlifetime): int|false { /* ... */ }
}
关键注意事项：
- read 必须返回字符串，即使数据不存在也要返回空字符串，否则会触发警告
- write 的返回值决定 Session 是否写入成功，必须严格返回 bool
- gc 的调用频率由
session.gc_probability和session.gc_divisor控制，默认 1/100 的概率触发 - 并发控制需要自行实现，通常使用 Redis 的
SETNX实现分布式锁，或使用WATCH/MULTI实现乐观锁
六、总结
PHP Session 的底层机制可以概括为三个核心维度：
- 存储抽象：通过函数指针表实现可插拔的存储后端，
files是默认实现 - 序列化：三种引擎各有取舍，
php_serialize在安全性和通用性上最优 - 并发锁：
files处理器使用 flock 排他锁保证一致性，但会串行化同 Session 请求；自定义存储需自行处理并发
理解这些机制后，在面对 Session 阻塞、数据丢失或分布式一致性问题时，就能从内核层面定位根因，而不是停留在“重启 PHP-FPM”的层面。对于高并发场景，推荐使用 Redis 作为 Session 存储，配合 session_write_close() 及时释放锁，并在必要时实现细粒度的分布式锁策略。
未经允许不得转载：任鹏个人博客 » PHP 会话管理内核原理：session 存储、序列化与并发锁的底层机制
