PHP 核心中的‘不可变数组’（Immutable Arrays）：分析其在 Opcache 中的物理分布 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

好，各位来宾，把手机调至静音。今天咱们不聊怎么写 CRUD，咱们聊聊 PHP 引擎肚子里那点“肮脏”却又极其精妙的秘密。

我是你们的领路人。今天我们要探讨的主题，听起来有点像量子物理，其实就在你 $arr['key'] = 'value'; 这一行代码的背后。我们要讲的是——PHP 核心中的“不可变数组”及其在 Opcache 中的物理分布。

听起来很高大上，对吧？别慌。咱们把它拆碎了，就像拆开一台老旧的电视机，看看里面到底跑着什么电线。

第一部分：PHP 的“伪”不可变

首先，咱们得有个共识：PHP 是个动态语言，它是个疯子。如果你写：

$myArray = [1, 2, 3];
$myArray[] = 4; // 加个元素

这很正常，对吧？这个数组是“可变”的。它在内存里建了个家，你今天搬家（加元素），明天换个家具（改元素），后天把房子卖了（unset）。

但是，PHP 里有一种数组，它不仅不想搬家，它还想把自己刻在石头上。那就是常量数组。

// 定义一个常量数组
define('MY_CONSTANTS', [
    'env' => 'production',
    'version' => '1.0.0',
    'features' => ['fast', 'reliable']
]);

在这个例子里，MY_CONSTANTS 是个“不可变数组”。注意，我用的词是“不可变”。在 PHP 代码层面，你不能修改它。你如果敢写 MY_CONSTANTS['env'] = 'dev';，PHP 就会给你一个大耳刮子，告诉你这事儿没门。

为什么它是不可变的？

因为在代码编译的时候，PHP 引擎就知道这玩意儿一旦生成就不能再变。这就像是在 const（常量）这个盒子外面，焊上了一道厚厚的防盗门。

但是，各位，这仅仅是“代码层面”的不可变。在物理世界里，在内存地址上，这东西到底长啥样？它是怎么被 Opcache（操作码缓存）给“封印”住的？

这就涉及到咱们今天的重头戏了。

第二部分：揭开 `zend_array` 的面纱

要讲 Opcache 的分布，咱们得先看 PHP 核心的底层结构。这里有个核心角色，叫 zend_array。在 C 语言的世界里，它长得像个哈希表。

typedef struct _zend_array {
    uint32_t nNumUsed;       // 当前用了多少个槽位
    uint32_t nNumNextFreeSlot; // 下一个空闲槽位
    uint32_t nTableSize;     // 哈希表总大小
    uint32_t nTableMask;     // 哈希掩码（取余用）
    HashTable *pListHead;    // 数据链表头
    HashTable *pListTail;    // 数据链表尾
    Bucket *arData;          // 真正的数据桶！关键点在这里
    uint32_t nFlags;         // 标志位
} zend_array;

看到 arData 了吗？这就是数组在内存里的肉身。它是一个连续的内存块，里面塞满了 Bucket（桶）。每个桶里存着键、值，还有个指针指向下一个桶。

当你声明一个普通变量 $arr = [] 时，PHP 会在请求堆栈里临时申请一块内存。这个内存是临时的，请求结束了，这个内存要么被释放，要么被池子回收。

但是，当我们用 define 定义常量数组时，PHP 做了一件不一样的事。

它把这个 zend_array 的结构体，以及它里面的 arData，直接扔到了常量池里。

第三部分：Opcache 的“预加载”与“封印”

Opcache 是干嘛的？它是 PHP 的编译器加速器。它的工作流程通常是：源码 -> 词法分析 -> 语法分析 -> 编译成字节码 -> 执行。

对于普通代码，Opcache 只是缓存了“怎么执行”的指令（字节码）。但是对于 define 定义的常量数组，Opcache 干了一件更狠的事儿：它在启动阶段就把数据解析并固化了。

想象一下，你在写代码时：

编译时：Opcache 看到 define，它不直接生成运行时才执行的代码。它直接去内存里申请一块共享区域。
运行时：当请求进来，PHP 首先做的事情，不是去读文件，而是去 Opcache 的常量段里找这块内存，然后把指针指过去。

所以，这个“不可变数组”的物理分布，其实分布在两个地方：静态内存和共享内存。

物理分布一：常量结构体 (`zend_constant`)

在 PHP 的 C 源码里，常量是这样存的：

typedef struct _zend_constant {
    zval value;       // 值，这里存放的就是我们的数组
    int flags;        // 常量标志
    char *name;       // 常量名
    uint32_t name_len; // 名字长度
    void *module;     // 所属模块
} zend_constant;

注意 zval value。这不仅仅是个指针，它包含了 IS_ARRAY 标志和一个指向 zend_array 的指针。

关键点来了： 在 Opcache 机制下，这个 value 里的数组指针，指向的是 Opcache 在启动时申请的一块只读内存。

第四部分：二进制格式与内存布局（硬核部分）

现在咱们来点硬核的。Opcache 缓存文件（.opcode_cache 文件）本质上是一个二进制文件。当我们用 opcache_compile_file 打开一个 PHP 文件时，它解析出来的不仅仅是字节码，还包括了静态数据的序列化版本。

让我们来看看一个 MY_CONSTANTS 数组在 Opcache 的内存段里到底长什么样。

假设你的数组是：

define('CONFIG', [
    'db_host' => 'localhost',
    'db_port' => 3306
]);

在 Opcache 的共享内存中，它可能被布局成这样（为了理解，做简化示意）：

元数据头：记录这是哪个文件，哪个行号生成的。
常量表索引：一个数组，记录 CONFIG 这个名字对应内存地址 0x7f8a3b000100。
实际数据区：
- Header：nTableSize = 8, nNumUsed = 2。
- arData：连续的内存块。
  - 桶 0: Hash=0x6b6579 (key), Value=0x7f8a3b000200 (pointer to string “localhost”)
  - 桶 1: Hash=0x706f7274 (key), Value=0x7f8a3b000210 (pointer to integer 3306)

为什么要这样分布？

这涉及到一个概念：数据局部性。

如果你在同一个 PHP 进程里多次访问 CONFIG['db_host']，CPU 就会从缓存里把这个 zend_array 的内存页（Page）直接加载到 L1 Cache。因为它是连续存储的，所以读起来飞快。

如果它不是不可变的，每次请求都去堆里 new 一个数组，那内存碎片会像沙丁鱼罐头一样炸开，而且每次读内存都需要重新从硬盘的 swap 分区或者内存页换入换出，速度慢得像蜗牛。

第五部分：不可变的代价——GC（垃圾回收）的缺席

咱们再来看看“不可变”带来的另一个物理层面的特性：GC（垃圾回收）的缺席。

PHP 的动态数组有引用计数。当你 unset 一个变量，或者变量超出作用域，refcount 减 1。减到 0，触发 GC 销毁数组。

但是，define 定义的常量数组，它的 refcount 在 Opcache 中是被处理成“静态引用”的。

它的生命周期与 PHP 进程绑定，而不是与 HTTP 请求绑定。

这意味着什么？
意味着内存占用是累加的，永不释放。

如果你在一个 define 里定义了 1GB 的超大数组，哪怕所有用户都退出了，这个 1GB 的内存依然死死地钉在 Opcache 的共享内存段里，直到你重启 PHP-FPM 进程或者手动清除 Opcache 缓存。

这是优点也是缺点：

优点：对于频繁查询的配置，比如数据库连接字符串、API 密钥，你不需要每次请求都去读配置文件解析，直接在内存里拿指针对象就行，极快。
缺点：配置文件稍微动一下，整个 Opcache 内存池就得重建。这也就是为什么修改 define 后，你经常需要 opcache_reset() 才能生效。

第六部分：实战对比——动态数组 vs 不可变数组

为了让大家更直观地感受“物理分布”的区别，咱们写个代码跑一下（伪代码演示）。

场景 A：普通数组（可变）

function getConfig() {
    return ['debug' => true]; // 每次调用都 new 一个新对象
}

// 主循环
for ($i = 0; $i < 1000; $i++) {
    $c = getConfig();
    if ($c['debug']) {
        // do something
    }
}

物理过程：

程序进入 getConfig。
堆内存申请：PHP 向操作系统申请一小块内存（比如 64 字节）。
赋值：把这块内存的地址给 $c。
销毁：函数结束，$c 释放，这块内存可能被 PHP 分配器回收，下次可能被另一个请求复用。
性能：每一次循环都有一次系统调用或内存池的分配开销。虽然小，但累积起来就是 CPU 时间的浪费。

场景 B：常量数组（不可变）

// 文件顶部
define('DEBUG_CONFIG', ['debug' => true]);

// 主循环
for ($i = 0; $i < 1000; $i++) {
    // 直接读取全局常量指针
    if (DEBUG_CONFIG['debug']) {
        // do something
    }
}

物理过程：

PHP 进程启动，Opcache 解析文件，在共享内存的固定偏移量处生成 DEBUG_CONFIG 的 zend_array 结构。
循环 1000 次：每次循环都只是把同一个内存地址加载到 CPU 寄存器里。
性能：没有内存分配，没有对象创建，纯粹的内存寻址。这比场景 A 快了至少 10 倍，甚至几十倍，取决于循环体的大小。

第七部分：Opcache 中的数据完整性保护

既然不可变数组在共享内存里，那它会不会被“写坏”？

比如，两个 PHP-FPM 进程同时运行，一个进程想通过某种“黑魔法”去修改 CONFIG 数组，另一个进程会不会崩溃？

这就涉及到了操作系统的内存保护机制。

在 Linux 下，Opcache 申请的共享内存段通常是 PROT_READ | PROT_WRITE（可读可写）。但是，PHP 的核心层在访问这些常量数组时，是带着权限锁的。

或者更准确地说，在编译阶段，Opcache 就已经把常量数组处理成了“只读”的内存属性（虽然 Linux 层面可能允许写，但 PHP 层面的逻辑禁止了写入操作）。

如果你尝试修改它，PHP 会抛出 Cannot modify header information - headers already sent 或者更底层的 Segfault（取决于版本和配置），因为这破坏了数据的契约。

第八部分：深入剖析 `zend_string` 与 `zend_value`

既然提到了数组，咱们得顺带聊聊数组里存的东西。zend_value 是一个联合体，它既可以存整型，也可以存字符串。

当数组里存的是字符串（比如 MY_CONSTANTS['key']），在 Opcache 中，这些字符串同样被优化了。

它们不会像普通变量那样被放在当前的栈帧里。它们会被存储在字符串表中。

物理分布图解：

Opcache 共享内存段
|
+-- [段头：版本信息、启动时间]
+-- [常量表：数组指针数组]
|    +-- 指针 0 -> CONFIG (zend_array)
|    +-- 指针 1 -> API_URL
+-- [数据段：实际数据]
|    +-- [CONFIG 的 arData]
|         +-- Bucket[0]: Key="key", Value="value"
|         +-- Bucket[1]: Key="host", Value="127.0.0.1"
+-- [字符串表：去重存储的字符串]
|    +-- "key" -> 0x1a2b3c
|    +-- "value" -> 0x4d5e6f
|    +-- "127.0.0.1" -> 0x7a8b9c
+-- [类常量表：...]

你看，这就是为什么 PHP 处理大量字符串数组时效率奇高。因为“key”和“value”在内存里只有一份，所有数组都指着它们。这就是内存复用的极致体现，也就是所谓的“不可变”带来的红利。

第九部分：从“不可变”到“变异”——Opcache 的冷笑话

虽然我们一直在讲“不可变”，但 PHP 的世界充满了惊喜。

PHP 的 const 关键字，如果在 PHP 5.3 之前，它只能定义标量常量（整数、字符串、布尔值）。那时候你根本不能用 const [1,2,3]。

为什么？因为那时候 Opcache 的实现逻辑里，数组太复杂了，无法在编译期完全静态化。

后来 PHP 5.6 支持了 const 数组，PHP 7 引入了 readonly 类属性（虽然 readonly 数组本身还是可变的，但属性本身不可变，有点绕，咱们不展开了）。

现在的 Opcache 非常智能。当你定义一个常量数组时，它会检查你的代码。如果发现这个数组只在定义时被赋值一次，并且之后从未被修改，Opcache 会尝试把这个结构体标记为 Immutable。

一旦标记为 Immutable，PHP 引擎在访问这个数组时，会跳过 zend_array 的 ht_update() 等复杂函数，直接走只读路径。

第十部分：性能调优与内存泄漏的噩梦

最后，咱们聊聊实战中的坑。

如果你在 define 里定义了一个超大数组，比如 100 万个元素的缓存数组：

define('BIG_CACHE', array_fill(0, 1000000, 'data'));

这在 Opcache 里会瞬间占用几 MB 甚至几十 MB 的共享内存。

如果你的 PHP-FPM 进程数设置得很高（比如 200 个），这意味着你的 Opcache 共享内存池瞬间就要膨胀 20GB。如果你的物理内存不够，或者 opcache.memory_consumption 设置得不够大，PHP 就会崩溃，报错 SIGKILL。

这时候，你千万不能以为是你代码写得烂，而是因为你的“不可变数组”吃内存太凶了。

优化建议：

不要把巨大的数据集放在 define 里。define 是为了存配置、配置、还是配置。
如果你要缓存大量数据，用 Redis 或者 Memcached。把物理内存还给 Opcache，让 Opcache 去存字节码。

结束语

好了，各位。

咱们今天从 PHP 的语法糖 define 出发，一路杀到了 C 语言的 zend_array 结构体，最后甚至碰到了操作系统的内存分配和 Opcache 的二进制格式。

你看，这个所谓的“不可变数组”，它不是魔法，它是计算物理学的胜利。它牺牲了灵活性，换取了速度和内存的稳定分布。

在 Opcache 的物理世界里，它们是那些最忠诚的士兵，静静地躺在共享内存的角落里，等待着每一次请求的检阅。它们不搬家，不换家具，也不抱怨。它们只是在那儿，快得飞起。

下次当你写 define 的时候，记得尊重这块内存。别瞎改，别乱动，因为它一旦出事，影响的不是你一个请求，而是整个服务器的进程池。

好了，下课！记得把你们的代码写整洁点，别让 Opcache 的内存溢出了！

第一部分：PHP 的“伪”不可变

第二部分：揭开 zend_array 的面纱