由于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。
php session GC功能，就是Garbage Collector。这个GC启动的时候，会清除那些已经“超时”的session。它的工作原理是这样的：
用户访问并登陆网站，这时候后台会调用session_start来尝试生成一个会话（如果已经有会话，则相当于一次有效会话请求）
对于这样的每一次有效会话请求（Request），apache的php模块会根据session相关的全局变量gc_probability/gc_divisor =>计算出启动GC的概率，并由此概率来决定在这次请求中是否应该启动GC。举例来说，session.gc_probability的缺省值为1，session.gc_divisor的缺省值为100，则启动“垃圾回收”器的概率是1%，这就意味着在每100次请求中，会有可能清理一次过期会话
如果GC启动，则GC会扫描当前会话所在路径（session.save_path）下的所有会话文件，并根据另外一个全局变量session.gc_maxlifetime的多少来判断哪些session已经过期（“当前时间”与“会话文件的atime或者mtime”之间的差大于gc_maxlifetime：过期），并删除这些过期的session
如果你在一个session启动后，长时间没有任何交互操作（譬如，不停地码字，没有提交或者保存为草稿），那么你的保存在后台的会话文件将得不到机会被修改或者访问，在gc_maxlifetime（缺省值1440秒＝24分钟）时间后，它有可能因失效而被清理，这以后你再提交，就会因为会话失效而报错
由此可见，gc_maxlifetime设置为24分钟，对于写某些文章来说还不够。这是一个原因，另外，session.save_path的缺省路径在linux上是/tmp，很少有程序会修改这个设置。如果这台服务器上有多个虚拟主机，那么，/tmp目录下会存放许多不同session_name的会话文件。糟糕的是，php的GC不区分会话归属，它会根据它取得的gc_maxlifetime来清理这个目录下的所有过期session文件。
据以上分析，解决方案是：UTBLOG在.htaccess文件内添加了一条语句，将session.gc_maxlifetime的local value扩大为14400（4小时），同时在后台将session.save_path设置为/tmp/utblog，这样，utblog的会话文件就不受其他网站干扰了，而4小时的失效时间，我想，无论如何应该够用了。
测试下来，一切如我所愿。
另，如果直接改动/etc/php.ini当然也可以。如果没有权限改动php.ini，也没有权限改动apache的conf文件，.htaccess被禁止，那么直接修改plog的sessionmanager.class.php文件，在session_start行前添加ini_alter("session.gc_maxlifetime", 14400)亦可。plog结构良好，只有这一处调用session_start，所以也只有这一处需要修改。我在本地做过测试，可以工作。
--------------------------------------------------------------------------
session.gc_probability integer
session.gc_probability 与 session.gc_divisor 合起来用来管理 gc（garbage collection 垃圾回收）进程启动的概率。默认为 1。详见 session.gc_divisor。
session.gc_divisor integer
session.gc_divisor 与 session.gc_probability 合起来定义了在每个会话初始化时启动 gc（garbage collection 垃圾回收）进程的概率。此概率用 gc_probability/gc_divisor 计算得来。例如 1/100 意味着在每个请求中有 1% 的概率启动 gc 进程。session.gc_divisor 默认为 100。
session.gc_maxlifetime integer
session.gc_maxlifetime 指定过了多少秒之后数据就会被视为“垃圾”并被清除。
Note:
如果不同的脚本具有不同的 session.gc_maxlifetime 数值但是共享了同一个地方存储会话数据，则具有最小数值的脚本会清理数据。此情况下，与 session.save_path 一起使用本指令。
Note: 如果使用默认的基于文件的会话处理器，则文件系统必须保持跟踪访问时间（atime）。Windows FAT 文件系统不行，因此如果必须使用 FAT 文件系统或者其他不能跟踪 atime 的文件系统，那就不得不想别的办法来处理会话数据的垃圾回收。自 PHP 4.2.3 起用 mtime（修改时间）来代替了 atime。因此对于不能跟踪 atime 的文件系统也没问题了。
--------------------------------------------------------