这是一个创建于 1669 天前的主题，其中的信息可能已经有所发展或是发生改变。
前提
目前公司内用的 cli 常驻进程队列只能通过 kill 掉重启,避免 define 常量对多次请求之间的影响?(像 fpm 的 worker 一样)
[公司队列里我的任务调用很多其他组提供的方法都直接用了 define 常量,所以需要在任务开启时先 define,但是不 kill 掉进程 就会影响到下一次请求的常量]
个人分析
1.fpm 的 master 去 fork 的 worker 子进程每次处理完请求不会 kill 掉,结束时只调用 register_shutdown_function 注册的 gc_collect_cycles()去执行回收机制,但是我记得 gc 也只回收 zval 容器,不回收常量. 又因为看到 fpm 也会有内存泄露的可能,所以通过 max_request 配置去优化
=> 所以猜测出子进程的旧内存块不会清理,而是重新申请一块新内存块
2.又查到申请内存跟 emalloc，erealloc 之类的有关 ( https://www.kancloud.cn/kancloud/php-internals/42797)
3.那么怎么才能让 cli 跟 fpm 那样,再不 kill 掉进程的同事能重新分配内存块呢?在下小菜鸡一个,请求各位大神,百度谷歌都不太好找
 | 1 FrankAdler 2021 年 9 月 29 日 常量就是用来放置不会变的数据，怎么会多个请求之间影响，建议你别用 define 了 |
 | 2 datoubb OP @FrankAdler 就是单独一个请求里是不会变 ，但是一个队列 worker 执行执行多条请求的时候就会导致 define 重复定义的问题 define 这个是我调用别人的方法里面他直接用到的，历史原因不好改 |
 | 3 ihipop 2021 年 9 月 30 日 via Android fpm 的跨请求内存泄漏大部分是 C 部分引起的 其它问题你看下 fpm 的生命周期再问 要么你描述有问题，要么你公司实现有问题 |
Select Language