[PHP]session回收机制及php.ini session生命期

因为PHP的工做机制，它并无一个daemon线程，来定时地扫描session信息并判断其是否失效。当一个有效请求发生时，PHP会根据全局变量 session.gc_probability/session.gc_divisor（一样能够经过php.ini或者ini_set()函数来修改） 的值，来决定是否启动一个GC（Garbage Collector）。默认状况下，session.gc_probability ＝ 1，session.gc_divisor ＝100，也就是说有1%的可能性会启动GC。

GC的工做，就是扫描全部的session信息， 用当前时间减去session的最后修改时间（modified date），同session.gc_maxlifetime参数进行比较，若是生存时间已经超过gc_maxlifetime，就把该session删 除。

那为何会发生gc_maxlifetime无效的状况呢？

在默认状况下，session信息会以文本文件的形式，被保存在系统 的临时文件目录中。在Linux下，这一路径一般为\tmp，在Windows下一般为C:\Windows\Temp。当服务器上有多个PHP应用时， 它们会把本身的session文件都保存在同一个目录中。一样地，这些PHP应用也会按必定机率启动GC，扫描全部的session文件。

问 题在于，GC在工做时，并不会区分不一样站点的session。举例言之，站点A的gc_maxlifetime设置为2小时，站点B的 gc_maxlifetime设置为默认的24分钟。当站点B的GC启动时，它会扫描公用的临时文件目录，把全部超过24分钟的session文件所有删 除掉，而无论它们来自于站点A或B。这样，站点A的gc_maxlifetime设置就形同虚设了。

找到问题所在，解决起来就很简单了。修改session.save_path参数，或者使用session_save_path()函数，把保存session的目录指向一个专用的目录，gc_maxlifetime参数工做正常了。

还有一个问题就是，gc_maxlifetime只能保证session生存的最短期，并不可以保存在超过这一时间以后session信息当即 会获得 删除。由于GC是按机率启动的，可能在某一个长时间内都没有被启动，那么大量的session在超过gc_maxlifetime之后仍然会有效。解决这 个问题的一个方法是，把session.gc_probability/session.gc_divisor的机率提升，若是提到100%，就会完全解 决这个问题，但显然会对性能形成严重的影响。另外一个方法是本身在代码中判断当前session的生存时间，若是超出了gc_maxlifetime，就清 空当前session。

Tiwer


在window下設置wamp的session時間，即便設置了10秒超時，到時間都不會清空session。
linux的設置：
在apache1.2以上的版本中，能够在httpd.conf里面设置：
　　KeepAlive on
　　KeepAliveTimeout 15

session.auto_start 开启就自动完成了session_start()


php.ini 中 session.auto_start 开启与关闭的区别

区别就在于在用SESSION前是否须要session_start();


当session.auto_start = on
时，执行 session_start() 将产生新的 session_id

session.auto_start = on 的优势在于，任什么时候候都不会因忘记执行 session_start() 或 session_start() 在程序里的位置不对，而致使错误
缺点在于，若是你使用的是第三方代码，则必须删去其中的所有 session_start() 。不然将不能获得正确的结果