我从来不认为这个问题是个问题, 直到昨天.
昨天晚上的时候, 我提交了一个rfc, 关于引入finally到php, 实现这个功能的出发点很简单, 因为我看见不少人的需求, 另外还有就是stas说, 一直只看到讨论, 没看到有人实现. 于是我就给实现了.
发到邮件组以后, 一个开发组的同学nikita popov(nikic), 表示强烈反对这个rfc, 当然最初的论点他说了很多, 最后我们在线讨论的时候, 他表达了一个他的观点:
“php在请求结束后会释放所有的资源, 所以我们没有必要调用fclose,或者mysql_close来释放资源, php会替我们做”
并且他表示, 他从来都不会调用fclose, 认为fclose的存在只是为了继承c函数族.
我很惊讶, 我也不知道还有多少人是和他一样的想法, 所以我决定写这篇文章.
在php5.2以前, php使用引用计数(reference count)来做资源管理, 当一个zval的引用计数为0的时候, 它就会被释放. 虽然存在循环引用(cycle reference), 但这样的设计对于开发web脚本来说, 没什么问题, 因为web脚本的特点和它追求的目标就是执行时间短, 不会长期运行. 对于循环引用造成的资源泄露, 会在请求结束时释放掉. 也就是说, 请求结束时释放资源, 是一种部补救措施(backup).
然而, 随着php被越来越多的人使用, 就有很多人在一些后台脚本使用php, 这些脚本的特点是长期运行, 如果存在循环引用, 导致引用计数无法及时释放不用的资源, 则这个脚本最终会内存耗尽退出.
所以在php5.3以后, 我们引入了gc, 也就是说, 我们引入gc是为了解决用户无法解决的问题.
这个是历史, 我简单介绍下, 现在让我们回头来看开头的问题, 是不是因为php会在请求结束后释放所有的资源, 于是我们就可以不用手动释放呢?
看一个例子:
mysql最大连接数(mysql.max_connections)
资源-1 -> 资源+1 -> 资源-1 (峰值是1)
而如果你是等到php请求结束再释放:
资源+1 -> 资源 + 1 …. -> 资源 -1 -> 资源 – 1 (峰值是2)
也就说, 一个良好的编写的脚本可能要比一个瞎写的脚本, 要省很多峰值内存..
考虑一个极端情况, 对一个很繁忙的服务器来说, 比如有10个php进程, 每个php进程最大1g内存, 而服务器只有8g内存.
结论 (conclusion)
结论很明显, 我开头也说过了, 我从来不认为这个是个问题.
这里说一句, 如果你买了一本php的书, 它告诉你: “不用在php主动释放资源, 因为php会帮你释放”的话, 我建议你, 烧了它.