在线上高并发场景里摸爬滚打多年后你会发现PHP最容易被忽略但又最致命的一环往往不是业务代码写得好不好而是底层内存分配策略到底合不合理。今天聊的主角是PHP内核里的两员大将emalloc和pemalloc。这两个函数是Zend Memory ManagerZendMM对外提供的主要接口负责管理PHP进程内所有动态内存的申请与释放。如果你写过PHP扩展、或者遇到过内存泄漏、内存暴涨、把PHP常驻内存跑崩过那这篇文章就是给你准备的。我会从底层设计思路讲起再到实际使用中的选择标准最后把排查内存问题的实战经验一并倒出来。1. 为什么PHP需要一套独立的内存分配策略1.1 从系统malloc说起几乎所有C程序都在直接调用系统提供的malloc/free来管理堆内存这套接口成熟、高效而且经过几十年的优化普通场景下完全够用。但PHP是个例外它运行的方式和普通的C程序差别很大。普通C程序往往是单次执行要么是命令行工具跑几秒就退出要么是daemon进程里的某个模块在稳定状态下反复执行同一逻辑。PHP则不同一个PHP-FPM worker进程会在一秒内处理几十个甚至上百个请求每个请求都会申请大量小内存比如字符串、数组、对象结构体等。请求结束之后这些内存又必须尽快释放干净为下一个请求腾出完全隔离的干净环境。问题在于如果每次都直接调用系统malloc/free会有两个痛点。第一系统malloc为了平衡性能与碎片化通常有比较复杂的数据结构和分配算法高频次小内存分配的开销会非常可观。第二也是更要命的malloc并不理解PHP的请求生命周期它只负责给一块内存然后等着free来回收但PHP要求的是“请求结束后该请求申请的所有内存一个不剩地全部清空”。如果靠开发者在代码里手动释放每一个指针那PHP扩展开发将成为一场噩梦因为任何一个忘记释放的情况都会让内存无限增长。1.2 ZendMM的诞生目标正是为了应对这种高频、短生命周期、大量小内存分配的需求Zend引擎实现了自己的内存管理层也就是ZendMM。它相当于在PHP和系统malloc之间加了一个定制化的中转站。我个人的理解是ZendMM更像是一个私有化的内存池。这个池子会一次性向系统malloc申请比较大的内存块比如2MB然后再按照PHP自己的规则切割成一个个小内存槽位供脚本里的变量、数组元素等对象使用。当一次请求结束时ZendMM并不需要逐一判断每个指针是否还在使用它只需要做一次集体回收直接重置当前请求分配用的整个内存段丢回池子里复用。这样做的结果就是分配内存的开销被大量摊薄释放内存也从O(n)级别摊成了O(1)级别的重置动作。这个设计非常聪明它把“内存管理策略”从“精确追踪每个块”转变成了“批量管理整个池”。对应到我们的主角emalloc正是在这个池子上实现的标准分配函数pemalloc则是嵌入了“是否跨请求存活”判断的更智能版本。理解了这层背景后面所有细节就都能串起来了。2. emalloc和pemalloc核心差异与设计原理2.1 emalloc请求生命周期内的临时内存emalloc是PHP扩展开发中最常用的内存分配函数可以把它理解为PHP版的malloc。它的原型很简单void *emalloc(size_t size);调用这个函数会在ZendMM当前请求对应的内存池中分配一块size字节的内存。关键点是这块内存的生命周期默认绑定在当前请求上请求一结束ZendMM会直接释放或重置整个请求内存池你分配的这块内存也跟着“灰飞烟灭”不需要也不能手动free。实际写扩展时你几乎不需要担心这个内存什么时候释放因为你没法主动释放。ZendMM的机制就是这样它在每个请求结束时自动清理所有通过emalloc申请的内存。这种策略导致一个很有意思的习惯PHP扩展开发者在分配内存时胆子都很大因为系统帮你兜底回收不过这也带来了一个副作用就是一旦内存被错误地存到全局变量里跨请求保留麻烦就来了。这种内存不会在请求结束时被释放因为它挂在全局状态上但ZendMM并不认识它长期下来必然导致泄漏。2.2 pemalloc跨请求的持久内存pemalloc的全称是persistent emalloc它比emalloc多了一个参数void *pemalloc(size_t size, int persistent);第二个参数persistent是一个布尔开关。当它为0时pemalloc的行为和emalloc完全一致使用请求内存池请求结束自动释放。当它为1时pemalloc会绕过请求内存池直接调用系统malloc分配内存并且这块内存可以跨请求存活直到你在合适的时候用pefree手动释放。这里有个非常巧妙的抽象你在写扩展时可以用同一个函数名通过persistent参数来决定内存的生命周期。如果你是给某个数据结构分配内存而这个数据结构可能需要在多个请求之间共享比如缓存、连接池那persistent 1就特别合适。如果你只是处理临时数据那persistent 0又让你无需操心释放。但注意pemalloc设计得“聪明”的前提是你必须告诉ZendMM是否持久。如果选错了后果很隐蔽。最常见的就是一个临时对象的内存被标记成persistent 1然后每个请求都分配一次又没在合适的地方释放轻则几百个请求后worker内存飙到几百MB重则直接OOM崩溃。2.3 两者的实现细节对比从源码实现来看emalloc和pemalloc在ZendMM内部走的是完全不同的两条路径。我们要想真正理解差异就得深入看一层。当persistent为0时pemalloc内部直接调用emalloc逻辑。emalloc会从当前请求的堆heap上分配内存这个heap是ZendMM为每个线程维护的一个对象池。分配成功后ZendMM会在这个堆的内存块链表里登记一条记录方便请求结束时的统一清理。由于ZendMM使用了自己的一套内存槽位复用机制相同大小的内存分配会非常快基本上是常数时间操作。当persistent为1时pemalloc直接调用系统malloc。系统malloc返回的是一个独立的、不挂在ZendMM heap上的内存块。也就是说ZendMM对这块内存没有控制权它不会在请求结束或者线程结束时自动清理。你需要手工用pefree释放或者注册一个在进程退出前执行的清理函数。还有一个容易忽略的细节emalloc分配的内存内存对齐是由ZendMM的堆配置决定的ZendMM默认会做CPU cache line对齐一般是64字节以优化缓存命中率。系统malloc虽然也做对齐但它的对齐规则和ZendMM内部选择的chunk大小可能并不一致这也会导致在高频分配场景下性能差异。我们可以用一张表快速对比两者的差异对比项emallocpemalloc(persistent1)底层实现ZendMM内存池系统malloc生命周期当前请求结束时自动释放跨请求存活需手动pefree分配速度极快常数级复用槽位受系统影响有锁和系统调用开销适用场景请求内临时数据、变量缓存、连接池、跨请求共享数据释放方式请求结束统一回收手动pefree或注册清理钩子内存碎片控制ZendMM内部通过块内存复用控制依赖系统malloc碎片策略3. 实操中如何选择与验证内存分配策略3.1 在扩展开发中使用emalloc/pemalloc写PHP扩展的时候很多人上来就无脑用emalloc这是基于安全习惯的默认操作。但实际编码中我们经常需要做选择。我总结了一套可以“抄作业”的判断流程如果你的内存在当前请求内创建、使用、结束不需要跨请求保存毫不犹豫选emalloc。如果内存需要跨请求保存并且保存时间是确定的比如某个全局配置结构体在PHP_MINIT阶段创建在进程整个生命周期内使用那就用pemalloc(ptr, 1)并在PHP_MSHUTDOWN阶段调用pefree。如果内存是全局的但大小会随请求变化、内容又依赖每次请求的状态那就不要用pemalloc持久化而是考虑用php的全局变量结合请求周期内存池每次请求重新初始化避免内存被不干净地复用。给你一个典型的扩展伪代码片段这样看更直观PHP_MINIT_FUNCTION(myext) { // 全局缓存跨请求存活 myext_global_cache pemalloc(sizeof(cache_entry_t), 1); myext_global_cache-data NULL; return SUCCESS; } PHP_MSHUTDOWN_FUNCTION(myext) { // 进程结束时释放 if (myext_global_cache) { pefree(myext_global_cache, 1); } return SUCCESS; } PHP_FUNCTION(myext_do_something) { // 临时缓冲区请求结束时自动释放 char *tmp emalloc(4096); snprintf(tmp, 4096, hello %ld, Z_LVAL_P(z_arg)); RETURN_STRING(tmp); // 注意tmp不用手动释放emalloc会在请求结束时被ZendMM回收 // 而且RETURN_STRING会拷贝一份所以tmp丢了也不泄漏 }有人会问RETURN_STRING拷贝了一份那emalloc的tmp是不是有点浪费这确实是个坑。PHP的核心API会自动管理返回的zval内存如果你自己emalloc一个字符串然后用RETURN_STRING等于多复制了一次。正确做法是用RETURN_STRINGL拷贝生成新的持久内存然后自己再用efree释放临时块。很多人写扩展时内存翻倍增长就是因为这类不必要的emalloc没释放。3.2 通过配置和工具观察内存行为如果你不写扩展只是在用PHP开发Web或CLI应用那你怎么感受到emalloc和pemalloc的存在呢最直接的入口是memory_limit配置项。当PHP进程运行到某个请求时ZendMM会统计当前请求已分配的内存总量一旦超过memory_limit就会抛出Allowed memory size of xxx bytes exhausted致命错误。注意这个统计的实际上是ZendMM通过emalloc分配的请求内存总量不包含pemalloc持久内存。所以如果某个扩展大量用pemalloc分配了跨请求内存你在memory_limit里是看不到的看到的只是系统进程RSS不断上涨。想要观察底层内存分配行为我用的最多的工具是valgrind的massif和dhclient抱歉是heaptrack分析。对PHP扩展开发来说跑脚本时用valgrind做泄漏检测是非常有效的USE_ZEND_ALLOC0 valgrind --leak-checkfull php -c /path/php.ini -r echo test\n;这里有个关键技巧USE_ZEND_ALLOC0环境变量会让PHP在启动时直接禁用ZendMM所有emalloc调用会退化成系统malloc。这样才能让valgrind精确跟踪到每一块内存的分配与释放。如果不用这个变量ZendMM会把大量内存池整体视为隐藏的valgrind根本看不出哪些是真正的泄漏。3.3 内存池的参数与优化ZendMM并不是一个黑盒它有几个关键参数可以被外部调整典型的如error_reporting里的E_ERROR级别还有一个非常隐蔽但实用的配置项zend_mm_heap的大小策略。从PHP源码的zend_alloc.c里可以看到ZendMM为每个线程维护一个heap这个heap会使用ZEND_MM_CHUNK_SIZE默认2MB作为一块连续内存的申请单位再通过ZEND_MM_MAX_SCRATCH等参数控制内存碎片和缓存槽位数。这些数值无法通过php.ini修改但我们可以在编译PHP时通过宏调整。不过说实话默认值已经经过大量真实负载的调优普通项目完全不需要动。比较有意义的是pcre.backtrack_limit这类扩展级配置它和内存分配关系密切。PCRE库在做正则匹配时本身会申请大量临时内存如果它在匹配过程中走到了请求内存池的边缘ZendMM的分配算法会因为块耗尽而触发额外向系统malloc请求新块导致性能下降。实测中把backtrack_limit调高到1000000以上对于复杂正则的内存分配性能有可感知的提升。再就是opcache的interned_string_buffer配置。它实际上是一个独立的共享内存缓冲区不是ZendMM管理的字符串池但对PHP内存压力影响很大。当你把interned_string_buffer调大很多重复字符串会被去重并常驻在共享内存中减少了每个请求通过emalloc重复分配相同字符串的负担这是我在高并发业务里用得最多的“无痛优化”手段。4. 常见问题排查与避坑经验4.1 内存泄漏与越界诊断在PHP场景下内存泄漏通常不是你想象的那种“忘记free”导致的因为ZendMM会自动回收请求结束时的内存。真正的泄漏基本都发生在以下三种模式里第一种全局变量持有emalloc指针。比如你在扩展里用ZEND_TSRM的全局宏把一个emalloc分配的内存块存到全局结构体中然后在每个请求里反复覆盖这个指针却不释放旧指针。由于指针不在请求内存池的“追踪范围”之外ZendMM觉得它还在当前请求内请求结束时它会被尝试清理但因为全局变量还在指向它逻辑上就造成了悬空引用再往后分配就会用到一块已释放的内存导致崩溃或者神秘报错。这种问题极难排查。第二种pemalloc的持久内存没有配套释放。比如在扩展里使用了pemalloc(1)但只在MINIT阶段分配忘了在MSHUTDOWN阶段释放。FPM worker常驻内存只涨不降最后稳定在几GB。这种泄漏非常好定位直接看RSS随时间线爬升即可。第三种C扩展中越界写。ZendMM分配的内存块会记录实际大小如果你写越界比如emalloc(10)却写入了memcpy(buf, data, 20)那么紧接着的另外一块内存的数据就被覆盖掉最典型的表现是数组元素的值随机变化。你可以开启USE_ZEND_ALLOC0配合valgrind跑一遍越界问题会被valgrind在free时检测出来。我提供一套排查泄漏的流程用ps aux观察PHP-FPM各worker的RSS内存如果某个worker的RSS持续上涨就可能需要检查该worker处理的请求是否有横跨的全局缓存。启用PHP-FPM的pm.max_requests500每个worker处理500次请求后自动重启能暂时缓解泄漏但治标不治本。用pm.status以?full模式检查脚本状态配合memory_get_usage(true)监测当前请求峰值内存。在本地用USE_ZEND_ALLOC0 valgrind --leak-checkfull运行同样业务脚本对比系统级泄漏。4.2 pemalloc持久连接带来的坑很多面向数据库的PHP扩展都会用pemalloc来保存持久化连接。比如mysqli的mysqli::pconnect()底层在创建新的数据库连接时就会把连接对象放入一个持久内存池里。这种设计本身是好的能省去每次请求重建连接的开销。但持久连接和pemalloc结合时有一个非常经典的坑在连接的生命周期里它会持有若干通过emalloc分配的临时资源例如预处理语句对象、字符缓冲等。请求结束时emalloc分配的资源被ZendMM自动释放但持久连接对象还活在下一次请求里这就导致连接对象的内部状态变成了“引用已释放内存”的野指针。下次请求再使用这个持久连接最常见的结果就是segfault或者“MySQL server has gone away”。解决办法有两个方向。第一个是确保扩展内部的所有连接关联资源都使用pemalloc持久分配而不是emalloc这需要扩展作者严格遵守规范。第二个是从业务侧规避避免使用过长的持久连接生命周期定期清理连接池或者在FPM配置里设置pm.max_requests较小值来强制复用新worker。我工作的一个项目里把pm.max_requests从默认的无穷大改成了300耗时2分钟解决了线上偶发呆锁崩溃的问题这正是pemalloc持久状态和请求期资源生命周期冲突导致的。4.3 常见错误速查表我在踩坑无数后整理了一张速查表方便大家快速定位问题。问题现象可能的根因处理建议请求内内存涨到memory_limit后立即崩溃扩展中使用emalloc分配了大块临时内存且没有及时efree导致请求峰值超限检查扩展里循环内的emalloc及时efree提升memory_limit临时止损worker RSS持续上升不随请求回落扩展使用了pemalloc持久内存且不释放或FPM未开启max_requests开启max_requests用valgrind检测持久泄漏点valgrind报“still reachable”ZendMM内存池本身保留未释放的chunk不用太担心属于正常的内存池设计启用USE_ZEND_ALLOC0后性能骤降绕过了ZendMM所有分配走系统malloc开销增加仅用于内存调试不要在生产环境开启使用持久连接后连接状态错乱扩展内部把持久连接关联资源误用emalloc升级扩展版本或避免pconnect方式用短连接内存碎片化严重导致大块分配失败频繁emalloc/efree不同大小的内存块尽量避免请求内创建大量大小不一致的临时对象开启ZendMM块复用特性4.4 分享一个我自己写过的ZendMM监控工具说完了理论每个人都会都喜欢实操硬货。如果你整天被PHP内存问题折磨有个很原始的土办法就是用PHP扩展监控当前请求内存使用。先在你的扩展里注册一个预执行或请求结束时段的钩子在这个钩子里读取zend_memory_usage(true)PHP_FUNCTION(show_memory_stats) { zend_ulong real_size zend_memory_usage(1); zend_ulong internal_size zend_memory_usage(0); php_printf(real: %lu, internal: %lu, real_size, internal_size); }注意zend_memory_usage(1)返回的是ZendMM通过系统malloc申请的总内存大小包括了内存池扩大的部分比memory_get_usage(true)更精确。这个数值如果在单请求内经多次数组操作后始终超过你预期那你八成是生成了大量中间数组可以用zend_memory_peak_usage查看峰值。对于纯PHP应用不需要写扩展直接调用内置函数就能两者对比$start memory_get_usage(true); // 业务逻辑... $peak memory_get_peak_usage(true); $delta memory_get_usage(true) - $start;但记住内置函数的统计粒度是请求内存池无法暴露pemalloc持久部分。如果想要完整进程级内存视图还是得用/proc/pid/status里的VmRSSVmSwap来做粗粒度监控。从个人经历来看真正吃透emalloc和pemalloc的价值不在于你能背出源码里的结构体而在于你面对“内存只涨不清”这类问题时能快速思考这是不是emalloc被错误挂到全局了这是不是pemalloc忘了释放了这套思维模型让我少熬了无数个定位崩溃的深夜。这个内容如果对你的项目也有帮助接下来你可以尝试用systemtap或bpftrace去跟踪PHP用户态内存分配调用看看emalloc和pemalloc在真实负载下的分配频次比值那会是一个非常有说服力的性能分水岭。