session自动退出登陆解决方法

先说说现象：今天登陆后台的时候，很奇怪一登陆就退出，后台代码一直没有改动过，查了一下缘由，找到了根本缘由，后面会贴上找到的相关文档。解决办法就是在产生的session的页面session_star();加上如下三句代码：

PHP Code 复制内容到剪贴板

1. ini_set("session.gc_divisor", 1);  
2. ini_set("session.gc_maxlifetime", 5);  
3. ini_set("session.cookie_lifetime", 10);  

同时也能够用查看设置路径是否有问题

PHP Code 复制内容到剪贴板

1. print_r(session_get_cookie_params())  

如下是转摘网上文档

首先 gc是什么?

gc, 是garbage collection 的简称.这个进程通常都跟着每起一个SESSION而开始运行的.gc目的是为了在session文件过时之后自动销毁删除这些文件.

一、session_gc_probaility
PHP默认不是每一个SESSION启动都会启动一个GC来跟踪。这个参数是控制gc跟session启动几率。默认 1。值越大，几率越大。

二、session.gc_divisor
功能同上。 默认100。值越小，几率越大。

三、session.gc_maxlifetime
超过设定时间，gc就认为是垃圾文件。

总结
session_gc_probaility和session.gc_divisor是一对控制gc启动的几率的两个参数。前者是分子，后者是分母。默认是1/100。 1%的概率。 也就是说100个请求中只有一个gc会伴随100个中的某个请求而启动。
session处理是全部的Web应用都必须面对的问题。PHP中对session有效期的处理，和其余的解决方案有着很大的不一样，这是和PHP的工做机制相关的。

   在传统的client/server应用中，对于session失效的状况，能够交给网络协议本身来处理。不管是client端主动关闭链接，仍是由于网络异常而致使的链接中断，server端都可以获得通知，触发链接中断的事件。只要编程响应这一事件，执行指定的操做便可。     但对于web应用来讲，状况却彻底不同。HTTP协议自己是无状态的，也就是说，每当client/server完成一次请求/响应的过程后，链接就会被断开。在断开链接之后，server并不知道client是否继续“在线”，还会继续发送下一次请求。     换句话说，不管client端的用户已经关闭了浏览器窗口，仍是用户仅仅在阅读当前网页并准备在下一秒钟继续浏览，或者用户由于Windows崩溃/停电/硬盘坏掉/网线被拔/地球爆炸而完全没法再发送下一个请求，server都一无所知。（在HTTP 1.1中，浏览器能够经过keep-alive参数，来通知server不要在响应请求后主动断开链接，从而实现物理上的长链接。可是，这只是为了提升网络传输的性能而采起的措施，HTTP 在逻辑上仍然是无状态的。）所以，只能经过某种模拟的方式来判断当前session是否有效。若是某个session在超过一段时间后没有对server 端发出请求，server都会判断用户已经“离线”，当前session失效，并触发链接中断的事件。要作到这一点，server须要运行一个后台线程，定时扫描全部的session信息，判断session是否已经超时。     PHP处理session的原理也不例外，可是在具体的实现方式上，却不同凡响。这是由于，因为PHP的工做机制，它并无一个后台线程，来定时地扫描session信息并判断其是否失效。它的解决之道是，当一个有效请求发生时，PHP会根据某个几率，来决定是否调用一个GC（Garbage Collector）。     GC的工做，就是扫描全部的session信息，用当前时间减去session的最后修改时间（modified date），同配置参数（configuration option）session.gc_maxlifetime的值进行比较，若是生存时间已经超过gc_maxlifetime，就把该session删除。     这是很容易理解的，由于若是每次请求都要调用GC代码，那么PHP的效率就会低得使人吃不消了。这个几率取决于配置参数 session.gc_probability/session.gc_divisor的值（能够经过php.ini或者ini_set()函数来修改）。     默认状况下，session.gc_probability = 1，session.gc_divisor=100，也就是说有1%的可能性会启动GC。这三个参 数，session.gc_maxlifetime/session.gc_probability/session.gc_divisor均可以经过 php.ini或者ini_set()函数来修改。但要记得，若是使用ini_set()函数的话，必须在每个页面的开始处都调用 ini_set()。 这又致使了另一个问题，gc_maxlifetime只能保证session生存的最短期，并不可以保存在超过这一时间以后session信息当即会获得删除。由于GC是按几率启动的，可能在某一个长时间内都没有被启动，那么大量的session在超过 gc_maxlifetime之后仍然会有效。固然，发生这种状况的几率很小，可是若是你的应用对 session的失效期要求很精确的话，这会致使很严重的问题。解决这个问题的一个方法是，把 session.gc_probability/session.gc_divisor的机率提升，若是提到100%，就会完全解决这个问题，但显然会对性能形成严重的影响。另外一个方法是放弃PHP的GC，本身在代码中判断当前session的生存时间，若是超出了 gc_maxlifetime，就清空当前session。     PHP中的session有效期默认是1440秒（24分钟），也就是说，客户端超过24分钟没有刷新，当前session就会失效。要修改这个默认值，正确的解决办法是修改配置参数session.gc_maxlifetime。 我曾经在网上搜索过这个问题的解决方式，找到的结果千奇百怪。     有的说要设置“session_life_time”，据我知所，PHP中没有这个参数。有的说要调用session_set_cookie_params，或者设置 session.cookie_lifetime，这仅仅用于设置client端cookie的生存时间，换言之，只当client端cookie的生存时间小于server端的session生存期时，修改这个值才有效，而且最长不能超过server端的session生存期，缘由很简单，当 server端的session已经失效时，client端cookie的生存时间再长也是没有意义的。还有的说要调用 session_cache_expire，这个参数用于通知浏览器和proxy，当前页面的内容应该被缓存多长时间，和session的生存期并无直接关系。     听起来，这种解决方案很完美。可是，当你在实际中尝试修改session.gc_maxlifetime的值的时候，你极可能会发现，这个参数基本不起做用，session有效期仍然保持24分钟的默认值。甚至可能出现，在开发环境下工做正常，在服务器上却无效！ 为了完全解决这个问题，须要对PHP的工做细节进行进一步的分析。 在默认状况下，PHP 中的session信息会以文本文件的形式，被保存在系统的临时文件目录中。这个路径由配置参数session.save_path指定。在Linux下，这一路径一般为\tmp，在 Windows下一般为C:\Windows\Temp。当服务器上有多个PHP应用时，它们会把本身的session文件都保存在同一个目录中（由于它们使用同一个session.save_path参数）。一样地，这些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的目录指向一个专用的目录，例如\tmp\myapp\。这样，gc_maxlifetime参数就工做正常了。     使用公用的session.save_path还会致使安全性问题，由于这意味着，同一台服务器上的其它PHP程序也能够读取你的站点的session文 件，这可能被用于黑客攻击。另外一个问题是效率：在一个繁忙的站点中，可能存在成千上万个session文件，而把许多不一样网站的session文件都放在 同一个目录下，不管是对单个文件的读写，仍是遍历全部文件进行GC，都无疑会致使性能的下降。所以，若是你的PHP应用和别的PHP应用运行在同一台服务 器上的话，强烈建议你使用本身的 session.save_path。     严格地来讲，这算是PHP的一个bug。当PHP在进行GC时，它应该区别来自不一样站点的session文件，并应用不一样的gc_maxlifetime值。目前，最新的PHP 5.2.X仍然存在这个问题。     上文说到，在一个繁忙的站点中，可能存在成千上万个session文件，即便区分了不一样站点的session.save_path目录，单个站点的session文件数目仍然可能致使效率问题。