欢迎来到内存管理的“鬼屋”：PHP 源码里的字符串驻留
各位看官，各位开发界的“内存大拿”，大家下午好！
今天我们不聊高并发，不聊分布式，也不聊怎么把PHP写进C内核里。咱们今天要聊一个稍微有点“硬核”，但绝对能让你在深夜被监控报警惊醒时，拍着大腿说“我懂了”的话题——PHP 源码中的字符串驻留。
想象一下，你是个保洁员。你每天的工作就是清理垃圾。但是呢，你的老板——也就是你的代码，每天都会扔一堆“垃圾”过来。你说这是“垃圾”，老板说：“这叫内存”。
你说：“老板，你明明知道明天还会再扔同样的‘垃圾’，为什么你不直接捡起来重复用呢？”
老板说：“因为我是高级语言，我是 PHP，我比你聪明，我有……字符串驻留！”
听起来很高大上，对吧？今天，我就带大家把 PHP 的裤衩扒了，看看它到底是怎么在内存里玩“不重复造轮子”这一套魔术的。
第一部分：内存里的“克隆人危机”
在深入源码之前，咱们得先看看，如果我们不搞字符串驻留，PHP 的世界会变成什么样。
想象一下，你是一个 PHP 脚本。你手里有 100 万个变量，每个变量里都存了一句一模一样的话：“Hello, World!”。
如果不驻留：
// 场景：你在处理一百万个日志记录
for ($i = 0; $i < 1000000; $i++) {
$log_message = "User logged in"; // 每次循环都分配内存
// ... 处理逻辑
}在普通的字符串管理下，PHP 会像个挥霍无度的富豪，每次循环都从堆上申请一块新的内存来存 "User logged in"。最终，你的内存池里堆满了这 100 万个一模一样的字符串副本。
这就像什么？这就像你在公司里，每个人都发了一本同样的《员工手册》。每一本手册都占用了一本《员工手册》的物理空间。
如果你处理的是海量文本，比如爬虫抓取了一百万个 URL，全是 http://google.com，那你瞬间就会耗尽内存，触发 OOM（Out Of Memory），然后被老板开除。
这时候，“字符串驻留”就出场了。
第二部分：什么是“字符串驻留”？
字符串驻留，简单说，就是“去重”。
它的核心思想是：只要内容相同的字符串，在内存中就只存在一份。
就像咱们去图书馆借书。你想看《哈利波特》，图书馆里只有一本。你拿走了，旁边的人（另一个变量）也想看《哈利波特》，图书馆工作人员直接说：“你拿的那本就是，别再找我要新的了，那本已经在你手里了。”
在 PHP 的世界里，这就是 interned strings。
第三部分：源码深扒——Zval 的“伪装术”
好了，咱们不整虚的。直接看 PHP 的内核。PHP 的核心是 Zend 引擎。
所有的值在 PHP 内核里都住在一个叫 zval 的结构体里。这个 zval 是个四舍五入的“变色龙”，它不仅能存整数，还能存浮点数、数组、对象，当然，还能存字符串。
看看 zend/zend_types.h 里的定义（这是老版本或者简化版的视角，足以说明问题）：
typedef struct _zval_struct {
zval_value value;
uint32_t type_info;
} zval;
typedef union _zval_value {
struct {
// 这里的 d 是 zend_string 的指针
zend_string *str;
} s;
// 其他类型...
} zval_value;注意看那个 type_info。这里就是 PHP 的“魔法箱”。
在 PHP 内核中，字符串不仅仅是 char*，它被包装成了一个 zend_string 结构体。这个结构体通常包含：
len: 长度。h: 哈希值（用于快速查找）。val: 字符串的实际内容（char数组）。gc: 引用计数信息。
最关键的是：这个 zend_string 结构体里，藏着一个秘密。
在 PHP 的源码里，有一个宏，叫做 ZSTR_IS_INTERNED。这个宏会检查 zend_string 结构体的某个字段（通常是 len 或者通过特定的位掩码判断）。
如果这个宏返回 TRUE，说明这个字符串是驻留的。
这意味着，那个 zend_string 结构体本身并不在堆上分配，或者它的 val 指针指向的是一段特殊的、只读的内存区域。所有引用这个字符串的变量，其实都指向同一个内存地址。
第四部分：谁是“内政部”？
PHP 的内核维护着一个全局的哈希表，名字很朴实，叫 interned_strings。它的作用就是充当“内存公寓管理员”。
当你第一次创建一个字符串 "hello" 时，内核会查一下这个 interned_strings 表：
- “嘿，这里存过 ‘hello’ 吗？”
- 没存？好，你去那个专门的只读内存区占个座（或者从空闲列表里拿一块），把
'hello'写进去，并记录下来。
当你下次再创建一个 "hello" 时：
- “嘿，这里存过 ‘hello’ 吗？”
- 存过！恭喜你，你不需要分配内存了，你只需要拿个钥匙（指针），指向那个现成的地方。
这就解释了为什么 PHP 的保留字（if, else, class）不需要重复定义。它们在 PHP 解析器启动的那一瞬间，就已经被“注册”到了这个 interned_strings 表里。
第五部分：代码演示——怎么证明它在驻留？
光说不练假把式。咱们来写一段 PHP 代码，用源码的视角去解读它。
注意：PHP 8.x 的实现更复杂，引入了 zend_string 结构体的现代化改造，但驻留的概念没变。咱们用 PHP 7 的逻辑来举例，因为它最经典，也最容易看懂。
假设我们在 PHP 内核里写一个辅助函数（或者用 PHP 的 debug_zval_dump 来观察）：
<?php
// 1. 首先看看那些“铁定驻留”的东西
$const = __FILE__; // 这是一个字符串常量
$keyword = "class"; // 这是一个关键字
$magic = "__LINE__"; // 这是一个魔术常量
echo "--- 常量/关键字区域 ---n";
debug_zval_dump($const); // 你会发现 refcount=1
debug_zval_dump($keyword);
debug_zval_dump($magic);
// 2. 现在看看我们自己创建的“动态”字符串
$a = "dynamic string";
$b = "dynamic string";
echo "n--- 动态字符串区域 ---n";
debug_zval_dump($a);
debug_zval_dump($b);源码层面的解读：
当你执行 $a = "dynamic string" 时，PHP 引擎做的事情是：
- 检查
interned_strings表。 - 发现没有
"dynamic string"这个条目。 - 调用
emalloc（内存分配器）在堆上开辟一块新空间，写入数据。 - 创建一个
zend_string对象，把指针填进zval里。
当你执行 $b = "dynamic string" 时，PHP 引擎做的事情是：
- 检查
interned_strings表。 - 奇迹发生了！ 发现已经有
"dynamic string"了。 - 不再分配内存！
- 直接返回那个已存在的
zend_string指针。
这就是为什么 $a === $b 是 true，而且它们指向同一个内存地址（在内存视图里）。对于内核来说，这简直是极度的性能优化。
第六部分：PHP 为什么不“全员驻留”？
你可能要问了：“既然驻留这么好，为什么不把所有用户输入的字符串都驻留？这样内存不就省下来了吗？”
这是个好问题！答案很残酷：因为在 PHP 里，字符串是可变的。
在 C 语言里，char* 通常是不可变的，或者需要你手动加锁。但在 PHP 里，字符串是对象，你可以这样玩：
$str = "hello";
$str[0] = "H"; // 把 'h' 改成 'H'如果 PHP 把 "hello" 驻留了，那么所有引用它的变量（比如 $a, $b，甚至可能是某个全局变量）都会瞬间变成 "Hello"。这叫副作用，是编程大忌！
想象一下，你和朋友约好晚上吃火锅。你给朋友发微信说“我们吃海底捞”。为了响应“提倡节约资源”的号召，朋友把“海底捞”这三个字驻留了，并替换了全世界的同类词汇。
结果晚上你去了肯德基，朋友去了麦当劳。你们两个见面了，朋友说：“哎呀，你怎么不去海底捞？我都去海底捞了啊！”
你说：“我饿啊！”
PHP 必须保证每个变量拥有独立的内存空间，直到它被销毁。如果全盘驻留，GC（垃圾回收）机制会变得极其复杂，并且容易出现难以追踪的 Bug。
妥协的方案：
PHP 选择了“关键数据驻留，用户数据不驻留”。
所有的关键字、常量、保留字、以及编译器生成的临时字符串，都被妥善地关进了 interned_strings 这个“VIP 专区”。
第七部分：深入源码——zend_string 的实现细节
咱们再往深里挖一点。看看 zend_string 结构体在 PHP 8 中的样子。
在 PHP 8.0+ 中，为了优化，zend_string 被设计得更加紧凑。
struct _zend_string {
zend_ulong h; /* hash value */
size_t len; /* string length */
char val[1]; /* the string data */
};注意看 val[1]。这叫Flexible Array Member（柔性数组成员）。
以前，zend_string 可能是这么定义的：
struct _zend_string {
zend_ulong h;
size_t len;
char *val;
};为什么改成 val[1]？
因为驻留！
当字符串被驻留时，val 不需要指向堆上的内存（因为内容在只读段或者特殊的 interned 池里，通常是固定长度的，或者通过特定的 len 值标记）。
PHP 8 使用了一种聪明的技巧：如果 len 是一个特定的负数（或者被 IS_INTERNED 标志位占用），那么 val 就直接指向结构体内部的存储空间。
这意味着，对于驻留字符串，emalloc 分配的内存大小仅仅是 sizeof(zend_string) 本身，不需要额外分配 strlen + 1 的空间！
这简直是内存界的“豆腐块收纳法”！
// 伪代码演示
if (ZSTR_IS_INTERNED(str)) {
// 直接从结构体里读数据，不需要额外的 malloc
char *content = ZSTR_VAL(str);
size_t length = ZSTR_LEN(str);
} else {
// 动态分配
char *content = emalloc(ZSTR_LEN(str) + 1);
}第八部分：性能的战场——为什么它快？
有人会问，不就是省内存吗？至于写这么多源码吗？
别天真了，在内核里，省内存就是省 CPU。
-
哈希计算是昂贵的：
当 PHP 在哈希表（比如关联数组）里查找键值时，它需要计算字符串的哈希值。计算哈希值需要遍历字符串的每一个字节。
如果是驻留字符串：- PHP 源码里通常会把字符串的
h字段（哈希值）直接存在zend_string结构体里。 - 查找时，直接读
h字段，0 次遍历，0 次循环。
如果是动态字符串：
- PHP 必须先
strlen计算长度。 - 然后遍历整个字符串计算
djb2或fnv哈希算法。 - 对于超长的 URL 或者日志，这可是 CPU 的浪费。
- PHP 源码里通常会把字符串的
-
比较操作：
strcmp需要对比每一个字符。如果两个字符串都驻留，而且zend_string的比较逻辑里优化了，直接比较内存地址（指针），那就是if (ptr1 == ptr2)，这比逐个字符比对快了一万倍。 -
缓存局部性：
当字符串被频繁访问时，驻留的字符串更紧凑地排列在内存中，CPU 的缓存命中率更高。
第九部分：实战技巧——如何利用字符串驻留？
既然知道了这个原理，我们在写代码的时候能不能“诱导” PHP 进行驻留呢？
很遗憾，对于用户定义的变量，PHP 不会听你的。但是，对于类名、函数名、常量名，PHP 内核是有优化的。
技巧一：使用静态数组或者单例模式
不要每次都 new 一个包含相同文本的对象。把那个文本作为类名或者配置文件名存起来。
技巧二：了解内存监控
debug_zval_dump 和 xdebug 的内存分析功能，能帮你看到哪些变量在疯狂占用堆内存。如果你发现有很多重复的小字符串，这可能是优化的方向（虽然 PHP 内核在用户态很难直接干预，但这能让你意识到性能瓶颈）。
技巧三：在 PHP 扩展开发中
这是你的主场！如果你在写 PHP 扩展，想获取一个字符串的哈希值：
- 错误做法：
zend_hash_find(interned_strings, key, key_len, &entry);（这需要你先算好哈希，再查表，虽然快，但你还要先算哈希）。 - 正确做法： 如果你已经有一个
zend_string*，直接用ZSTR_H(str)获取内置的哈希值。如果这个字符串被驻留了，你甚至不需要计算它；如果没驻留，它也有值。
第十部分：总结——不是所有“重复”都是垃圾
各位同学，咱们今天聊了一路。
PHP 的字符串驻留，本质上是一种“惰性”和“共享”的哲学。
它告诉我们，不要盲目地重复造轮子。在内存管理这个残酷的游戏里，最聪明的策略不是“尽力把东西写进内存”，而是“让内存里的东西只存在一份”。
虽然 PHP 的实现方式（不完全驻留用户字符串）有它的妥协，但它在内核层面做的极致优化（IS_INTERNED 标志、Flexible Array Member、内置哈希缓存），确实保证了它在处理海量文本时的生命力。
下次当你看到 var_dump($a) 显示 string(13) "foo" 的时候，别忘了，在 PHP 内核深处，可能有一个 interned_strings 哈希表正在微笑着看着你。如果那个微笑变成了“这是老熟人”，恭喜你，省了一笔内存钱。
好了，今天的源码解剖课就到这里。希望你们在写代码的时候，心里能装着那个 zend_string，省着点用你们的内存。下课！