再一次, 不要使用(include/require)_once

作者: Laruence( ) 本文地址: http://www.laruence.com/2012/09/12/2765.html 转载请注明出处 最近关于apc.include_once_override的去留, 我们做了几次讨论, 这个APC的配置项一直一来就没有被很好的实现过. 在这里, 我想和大家在此分享下, 这个问题的原因,

  • 作者: Laruence( )
  • 本文地址: http://www.laruence.com/2012/09/12/2765.html
  • 转载请注明出处

最近关于apc.include_once_override的去留, 我们做了几次讨论, 这个APC的配置项一直一来就没有被很好的实现过.

在这里, 我想和大家在此分享下, 这个问题的原因, 以及对我们的一些启示.

关于使用include还是include_once(以下,都包含require_once), 这个讨论很长了, 结论也一直有, 就是尽量使用include, 而不是include_once, 以前最多的理由的是, include_once需要查询一遍已加载的文件列表, 确认是否存在, 然后再加载.

诚然, 这个理由是对的, 不过, 我今天要说的, 是另外一个的原因.

我们知道, PHP去判断一个文件是否被加载, 是需要得到这个文件的opened_path的, 意思是说, 比如:

<?phpset_include_path("/tmp/:/tmp2/");include_once("2.php");?>

当PHP看到include_once “2.php”的时候, 他并不知道这个文件的实际路径是什么, 也就无法从已加载的文件列表去判断是否已经加载, 所以在include_once的实现中, 会首先尝试解析这个文件的真实路径(对于普通文件这个解析仅仅类似是检查getcwd和文件路径, 所以如果是相对路径, 一般是不会成功), 如果解析成功, 则查找EG(include_files), 如果存在则说明包含过了, 返回, 否则open这个文件, 从而得到这个文件的opened_path. 比如上面的例子, 这个文件存在于 “/tmp2/2.php”.

然后, 得到了这个opened_path以后, PHP去已加载的文件列表去查找, 是否已经包含, 如果没有包含, 那么就直接compile, 不再需要open file了.

1. 尝试解析文件的绝对路径, 如果能解析成功, 则检查EG(included_files), 存在则返回, 不存在继续2. 打开文件, 得到文件的打开路径(opened path)3. 拿opened path去EG(included_files)查找, 是否存在, 如果存在则返回, 不存在继续4. 编译文件(compile_file)

这个在大多数情况下, 不是问题, 然而问题出在当你使用APC的时候…

在使用APC的时候, APC劫持了compile_file这个编译文件的指针, 从而直接从cache中得到编译结果, 避免了对实际文件的open, 避免了对open的system call.

然而, 当你在代码中使用include_once的时候, 在compile_file之前, PHP已经尝试去open file了, 然后才进入被APC劫持的compile file中, 这样一来, 就会产生一次额外的open操作. 而APC正是为了解决这个问题, 引入了include_once_override, 在include_once_override开启的情况下, APC会劫持PHP的ZEND_INCLUDE_OR_EVAL opcode handler, 通过stat来确定文件的绝对路径, 然后如果发现没有被加载, 就改写opcode为include, 做一个tricky解决方案.

但是, 很可惜, 如我所说, APC的include_once_override实现的一直不好, 会有一些未定义的问题, 比如:

<?phpset_include_path("/tmp");function a($arg = array()) {    include_once("b.php");}a();a();?>

然后, 我们的b.php放置在”/tmp/b.php”, 内容如下:

<?php  class B {}?>

那么在打开apc.include_once_override的情况下, 连续访问就会得到如下错误:

Fatal error - include() : Cannot redeclare class b

(后记 2012-09-15 02:07:20: 这个APC的bug我已经修复: #63070)

排除这些技术因素, 我也一直认为, 我们应该使用include, 而不是include_once, 因为我们完全能做到自己规划, 一个文件只被加载一次. 还可以借助自动加载, 来做到这一点.

你使用include_once, 只能证明, 你对自己的代码没信心.

所以, 建议大家, 不要再使用include_once


Comments

  • 2012/09/12, haoboys writes: 一直不适用include/require_once 看来是明智的
  • 2012/09/12, 花生 writes: 看完了,也懂了很多,还是看鸟哥的博客学习的快
  • 2012/09/12, shaukei writes: 鸟哥,受教了!
  • 2012/09/12, shiran writes: include_once 使用绝对路径,是不是就可以避免举例中那个问题了?
  • 2012/09/12, test writes: 这只能说明应该更新 require_once 的机制或者APC。
  • 2012/09/12, Jason Gian writes: 受教了,鸟哥
  • 2012/09/12, maker writes: 学习了,这么靠前.
  • 2012/09/12, pysche writes: 这个对于自己有能力管控的代码是完全没问题的,可是像某些项目,个人觉得就很难。比如Wordpress的插件之类的,各个插件由不同的人开发,水平也不尽相同
  • 2012/09/12, heyli writes: 然而问题出在当你使用APC的时候也就是说我的程序没有使用 apc include_once就没问题?
  • 2012/09/12, zzjin writes: 鸟哥...第三行的第二个include拼错了....额
  • 2012/09/12, 雪候鸟 writes: @zzjin 哈哈, 已经更正, 我是别字大王....:)
  • 2012/09/12, tiger writes: 同意修改once的机制或apc的对once的机制.
  • 2012/09/12, 江湖大虾仁 writes: 我依然不是非常理解为什么不用。最好的情况当然是通过合理的架构来避免重复加载,如果只是靠自己维护一个数组来判断是否加载过的话一个没有include_once快吧。我觉得 pysche 说得对,有的时候自己没法掌控整个项目的时候只能用include_once这么写。
  • 2012/09/12, Danger writes: 学习了,很好。
  • 2012/09/12, Luke writes: 留名。。。受教了。。路过。。。
  • 2012/09/12, 再一次, 不要使用(include/require)_once – 非凡往事 writes: [...] 原文:http://www.laruence.com/2012/09/12/2765.html [...]
  • 2012/09/12, fc_lamp writes: good~~mark了鸟哥转载署名了。
  • 2012/09/12, littlemiaor writes: 哈哈 一直不用 once
  • 2012/09/12, wizardmin writes: 先mark下,找个机会测试下同意 @江湖大虾仁,很多项目是多人负责,而像yii框架的import(也是数组判断)好像很慢,特别是在循环使用某个类,每次都要遍历下import数组,一般都是用include/require_once解决
  • 2012/09/12, 叶随风 writes: 我觉得大部分使用这个include_once就是懒,懒得去判断。其实,如果一个项目是一个人开发,一个人维护,那么确实可以完全避免使用这个,如果要是一个团多多个人交叉开发,或者一段时间之后,换其他人维护,尤其是维护者的水平高低不同的时候,这个include_once的优势就出现了,毕竟很多较大的、文件较多大一套程序,很多文件都是包来包去的,想知道一个文件是否被包过,其实是很繁琐甚至是很痛苦的。有了这个语句,可就轻松多了。因人而异,因地制宜,根据情况酌情选择吧。
  • 2012/09/12, Alvind writes: 这个有点因噎废食了
  • 2012/09/12, icecream writes: 这会造成性能的下降吗?还是无法说服我不用的原因。
  • 2012/09/12, hutushen222 writes: 同样的代码我这里没有看到警告信息。PHP 5.3.2-1ubuntu4.17 with Suhosin-Patch (cli) (built: Jun 19 2012 01:35:33) APC Version: 3.1.3p1 apc.enable_cli=Onapc.include_once_override=On
  • 2012/09/12, hutushen222 writes: 补充:开启apc.include_once_override后,我遇到的问题是:第一次请求有输出;第二次无响应,服务器端终止服务,后台没有错误日志。ChromeError 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data.
  • 2012/09/12, imbiss writes: 如果使用Zend autoload呢?
  • 2012/09/13, Chon writes: include_once_override没有实现好,不应该成为不使用(include/require)_once, 这是include_once_override的问题呀. 博主应该只能是: 建议include_once_override和once不要同时使用. PHP本身在模块化和命名空间方面支持就不强, 完全靠autoload基本很难解决. 如果不使用只会让PHP只适用于做一些小站了.
  • 2012/09/13, 海纳百川 writes: 学习啦。虽然不太懂呢。
  • 2012/09/14, 再一次, 不要使用(include/require)_once树林/咖啡 成都专业php网站制作 | 树林/咖啡 成都专业php网站制作 writes: [...] 风雪之隅 ? PHP应用 Posted in: php / Tagged: 不要使用include/require_once, 再一次 [...]
  • 2012/09/14, 奇言妙事-文学奇谈小小说阅读xlinblog.sinaapp.com » 再一次, 不要使用(include/require)_once writes: [...] 本文地址: http://www.laruence.com/2012/09/12/2765.html [...]
  • 2012/09/14, 安静 writes: 关于 once 理论上 不会用到 实质上 存在即合理因为有很多 作者开源代码 思维 确实磕碜比如 phpcms 生成的时候 竟然 不断得去 foreach($a as $b){ include_once("b.php");}不得不用 include_once
  • 2012/09/14, Kevin.yt90 writes: 收到。以后会注意
  • 2012/09/16, 剑啸居 » 再一次, 不要使用(include/require)_once writes: [...] 原文地址:?http://www.laruence.com/2012/09/12/2765.html [...]
  • 2012/09/18, 了了也 writes: 当项目比较复杂又团队水平参差不齐时,once还是必要的吧。
  • 2012/09/18, stone writes: 一直使用下面的代码来替代require_once
  • 2012/09/18, stone writes: 呃,刚刚的代码被过滤了。。。function myrequire($file){static $loaded = array();if ( in_array($file, $loaded) ) return;$loaded[] = $file;return require($file);}
  • 2012/09/19, cevin writes: 我能说我严重同意么。千万别用include_once、require_once
  • 2012/09/26, anru writes: 这个理由实在是太牵强。第一个, include 比include_once 快,快多少?几毫秒吧。第二个, 这应该是APC的错,关include_once什麽事。include_once 使用绝对路径名时比include还快,请看这两个讨论,http://drupal.org/node/259623,http://blog.seeit.org/2010/06/php-the-include-include_once-performance-debate/这个是在实际应用的讨论。ZendFrame work, drupal, Sugarcrm, WordPress,symfony framework, 这些流行的PHP 应用都采用require_once/include_once" 排除这些技术因素, 我也一直认为, 我们应该使用include, 而不是include_once, 因为我们完全能做到自己规划, 一个文件只被加载一次. 还可以借助自动加载, 来做到这一点"对于一个程序员来说,能偷懒,为什麽不偷懒(利用工具提高效率)?要是什麽都要自己规划,干脆自己造CPU得了。
  • 2012/09/27, lamp小白 writes: 原来只知道不推荐用once,因为要多做次判断,但看了之后了解的更多了
  • 2012/09/29, zencart writes: 用 require 代替include 。。
  • 2012/10/10, anonymous writes: 我也想说,看样子应该是apc的问题,不用apc就行了嘛
  • 2012/10/23, 小川 writes: 技术的确很重要,但是不要把技术神化。
  • 2012/11/20, 甄码农 writes: 被震撼了,用了几年的include_once了,没出现过您说的这个问题。 存在的即是合理的吧。
  • 2012/11/28, 请不要使用include_once/require_once | 极速笔记 writes: [...] 原文引用自:http://www.laruence.com/2012/09/12/2765.html 此条目发表在 PHP 分类目录,贴了 include, include_once, require, require_once 标签。将固定链接加入收藏夹。 ← CodeIgniter(CI)发邮件长标题中文乱码解决方案 [...]
  • 2012/12/06, 关于PHP的编译和执行分离 | 5iphp writes: [...] 再一次, 不要使用(include/require)_once [...]
  • 2013/01/07, huming17 writes: require_once 还是有必要的,当绝对路径加载文件时,查询一遍已加载的文件列表时间很短,而加载PHP文件对象体积很大耗时间时候, 觉得require_once优于require。
  • 2013/01/09, 华定平 writes: APC是什么 本人愚钝
  • 2013/01/28, hello writes: 看到这句话比较经典: 你使用include_once, 只能证明, 你对自己的代码没信心.顺便山寨一下经典: 你不使用绝对路径做include, 只能证明, 你对自己代码所在的环境不了解.
  • 2013/02/18, minecraftskins writes: 这不是一般人要考虑的
  • 2013/03/09, Leric writes: 新的项目都应该用自动加载了,再到处写include只能说明很久没学习了,只是老项目用APC可能要注意点儿
  • 2013/04/09, 对require和include一个清晰的认识 | Maverick writes: [...] require和require_once的区别,require包含一次文件,如果在后面的编程中 再次包含同一个文件,PHP还是会去查找文件,解析文件,执行文件,require_once 包含一次文件,在后面编程中如果再包含已经require_once的文件则会被忽略,不会再查找文件而是直接到已包含的内存信息中读取. 个人觉得在全局性质的地方一般可以使用require_once,较个性化的地方使用require,全局性的文件在多人开发的过程中可能会被包含多次,个人个性化的地方一般使用require,自己的程序 一般人都知道自己包含了哪些文件吧.php牛人laruence 推荐在使用apc缓存的情况下使用include或require,不推荐 _once操作.?http://www.laruence.com/2012/09/12/2765.html [...]
  • 2013/04/18, 深入研究$ » 再一次, 不要使用(include/require)_once writes: [...] 本文地址: http://www.laruence.com/2012/09/12/2765.html [...]
  • 2013/04/27, kknd li writes: 之所以有once的主要原因是PHP在早期的开发实践中对开发者的约束很少项目又相对简单。当引入了面向对象后虽然有了自动加载的机制但还是依耐开发人员的的实现而且对早期函数式编程并没有改进和支持。对很多开发者来说这不能不说是个负担,实际上现在的PHP已经没有刚开始时的便捷轻便的特点开始变得复杂而有点脆弱。随着项目的复杂化对开发者的要求就进入一个陡峭提高的过程,当项目在你眼里慢慢走向靠拼凑来维持的时候,当你周围的人靠_once来保证不重复加载你又无能为力的时候不得不说对这种语言充满的是怎么样的感觉。
  • 2013/04/30, 再一次, 不要使用(include/require)_once | 午后小憩 writes: [...] 本文地址: http://www.laruence.com/2012/09/12/2765.html [...]
  • 2013/04/30, 关于Yaf的一些说明 | 午后小憩 writes: [...] 再一次, 不要使用(include/require)_once [...]
  • 2013/05/19, Ill tell you some sneak preview along with my favorite comfortable shoes origina writes: Khmer Comedy » Somnangblogs I was proposed this internet site by my own cousin. I am not sure whether this post is published by him since nobody in addition know this sort of detailed with regards to my trouble. You're incredible! Thanks! your write-up about Khmer Humourous » Somnangblogs All the best Lisa Veronica
  • 2013/06/07, roger writes: 其实有时候并不是对自己的代码没有信心,而是在接手别人的代码的时候,为了安全起见,不得已而为之
  • 2013/07/09, xsir317 writes: 怎么感觉APC用了好多HACK的手段。。。
  • 2013/07/11, wsq writes: 也许可以给require_once加上一个参数,限制open file的频率。
  • 2013/09/25, 上海天气预报 writes: 一再强调,队友死型不改,对于有洁癖的程序员来说有时真心累 。。
  • 2013/11/28, soooldier writes: 我的理解与之相反,如果把重复文件包含的工作交给程序员去做的话避免不了会建一个类似“已加载”的类的集合。单拿判断“已加载”这段代码来说,我觉得由底层做更合适,毕竟程序员自己写一个的话那么最终是要通过各种解析成opcode,这样的效率应该会比底层的C实现低下。而至于APC对include_once(require_once)造成的影响那就另说了,这个属于APC的实现问题,而不应该把问题归结到对include_once(require_once)的使用上。
  • 2013/11/28, soooldier writes: 还有鸟哥对于include_once过程描述中的第3步不太理解:为什么还需要再去included_files查找一次?
  • 2013/11/28, soooldier writes: 我对鸟哥关于include_once调用过程描述中的第3步不理解:为什么还需要去included_files里查找一次?
  • 2014/01/06, 小谈博客 writes: 有了命名空间,是不是不用考虑include ,require了,自动导入啊
  • 2014/05/04, How To Set Up A Website writes: Great article.
  • 2014/05/14, Verses writes: 樓下說的用命名來載入什麼意思? 會比 include好嗎?
  • 2014/07/20, consatan writes: 1. 尝试解析文件的绝对路径, 如果能解析成功, 则检查EG(included_files), 存在则返回, 不存在继续存在则返回的话,那为什么在function中调用include_once('/path/to/file.php')后会导致外部引入同一个文件时失败呢?function a() { include_once('/path/to/file.php'); var_dump($var);}a(); // output successinclude_once('/path/to/file.php');var_dump($var); // output NULL“存在则返回”仅仅是标记了下“引入的文件已经存在”然后就不引入了??
  • 2014/09/03, php中的多余的require(),这样会导致多余的执行时间吗? | segment-解决方案 writes: [...] ,被PHP开发组的laruence建议避免使用 --------------------------------------------------------------------------- [...]

Copyright © 2010 风雪之隅 版权所有, 转载务必注明. 该Feed只供个人使用, 禁止未注明的转载或商业应用. 非法应用的, 一切法律后果自负. 如有问题, 可发E-mail至my at laruence.com.(Digital Fingerprint: 73540ba0a1738d7d07d4b6038d5615e2)

郑重声明:本文版权包含图片归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们(delete@yzlfxy.com)修改或删除,多谢。

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。

留言与评论(共有 0 条评论)
昵称:
匿名发表
   
验证码: