Swoole Server内存不释放是因底层C内存池常驻，非PHP未回收；默认预分配连接、协程栈、缓冲区等池，worker_num越大初始RSS越高，且gc_collect_cycles()无法回收C层内存。
为什么 swoole_server 启动后内存不释放？
不是 PHP 没回收，是 Swoole 内存池在后台常驻。默认情况下，swoole_server 会为连接、协程栈、缓冲区等预分配多块内存池，进程退出前不会归还给系统——哪怕你没显式创建池，底层也早建好了。
-
swoole_server的worker_num越大，底层预分配的连接池（如reactor和worker共享的buffer_pool）总量越高，初始 RSS 就越高 - 协程内频繁
new Swoole\Coroutine\Http\Client或co::sleep()不会触发内存池释放，因为底层复用的是池中 chunk，不是 PHP 堆内存 - 用
memory_get_usage(true)看不到这部分内存，它属于 C 层 malloc 分配，得看ps aux --sort=-rss或/proc/PID/status的VmRSS
swow_memory_pool 不存在，别被名字骗了
Swoole 官方没有叫 swow_memory_pool 的配置或类——这是常见误搜关键词。实际相关配置分散在几个地方，且多数不可直接关闭：
-
buffer_output_size和buffer_input_size控制每个 TCP 连接的读写缓冲池大小，默认 2MB/连接，调太小会导致ERRNO 10053（连接被强制切断） -
socket_buffer_size是全局 socket 缓冲上限，影响所有连接共用的底层 ring buffer，设太高可能吃光 ulimit -l（锁定内存限制） -
coroutine.stack_size默认 256KB，每个协程都从内存池切一块，不是按需增长；设成 128KB 可降内存，但递归深了会coroutine stack overflow
怎么安全缩小默认内存池？
不能靠“禁用”，只能靠“约束”。关键是在启动前压低各池的上限值，并确保业务不踩边界：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 把
worker_num从 32 降到 8，连接池总容量直接砍掉 75%，尤其适合 HTTP API 类服务（并发靠协程，不靠 worker 数） -
set(['buffer_input_size' => 64 * 1024, 'buffer_output_size' => 64 * 1024])适合纯 JSON 小包场景；但 WebSocket 或上传接口必须保留至少 1MB，否则收包失败静默丢弃 - 启用
enable_reuse_port => true后，每个 worker 独占 accept 队列，反而能减少 reactor 线程争抢，间接降低 buffer_pool 压力
为什么 gc_collect_cycles() 对 Swoole 内存无效？
PHP 的 GC 只管 Zend VM 堆上的 zval，而 Swoole 内存池是通过 malloc / mmap 在 C 层独立申请的，GC 根本看不见这些地址。你看到内存不降，大概率是：
- 连接没主动
close()，底层 buffer 还挂在连接结构体里，池子不敢回收 - 协程里用了
Swoole\Coroutine\Channel且未消费完数据，channel 底层 slab 内存不会释放 - 启用了
opcache.enable_cli=1，OPcache 字节码缓存本身也占几 MB，和 Swoole 池叠加后更难分辨
真正有效的观测方式：用 swoole_server->stats() 查 connection_count 和 tasking_num，再对比 cat /proc/PID/status | grep VmRSS —— 如果连接数归零但 VmRSS 不动，那就是池子尺寸定死了，不是泄露。
