看到之前mr_jing的session文章，受益匪浅。碰巧我也遇到了在win下session的问题。他在文章最后一个有意思的事提到了，当时我看到之后的感觉就是，太tmd(甜蜜的)缘分了。再然后我自己整了一篇比较水的日记我所理解的session_set_save_handler的执行顺序机制，可还是不甘心，究竟看看linux下session到底行不行，（现在win下肯定是不行的）。
在win下测试session gc机制
2.php.ini配置
3、代码开始write.php写入session，值为当前时间戳
立即学习“PHP免费学习笔记（深入）”；
<?php session_start();$_SESSION['nametime']=date('Y-m-d H:i:s',time());echo '已经写入'.$sessionSavePath = ini_get('session.save_path');var_dump($_SESSION);4、读取session代码
<?phpecho 'maxlifetime'. ini_get('session.gc_maxlifetime')."<br>";echo 'gc_probability'.ini_get('session.gc_probability')."<br>";echo 'gc_divisor'.ini_get('session.gc_divisor')."<br>";session_start();echo '<hr>'.'Session::=>';var_dump($_SESSION);echo '<hr>'.'Cookie::=>';var_dump($_COOKIE);echo '<hr>';echo "<br>ReadTime".date('Y-m-d H:i:s',time());5、执行read.php
看到写入时间为17:57:04
6、读取session，可以看到读取session的值的（上面红椭圆圈）时间和写入时间都一样，都是
17：57：04，注意下面的readtime那一行是13：58：56，
篇文章是针对git版本控制和工作流的总结，如果有些朋友之前还没使用过git，对git的基本概念和命令不是很熟悉，可以从以下基本教程入手： Git是分布式版本控制系统，与SVN类似的集中化版本控制系统相比，集中化版本控制系统虽然能够令多个团队成员一起协作开发，但有时如果中央服务器宕机的话，谁也无法在宕机期间提交更新和协同开发。甚至有时，中央服务器磁盘故障，恰巧又没有做备份或备份没及时，那就可能有丢失数据的风险。感兴趣的朋友可以过来看看
好的，截至到现在，win上都没有问题。因为即使你的session的最大生存时间（session.gc_maxlifetime）为5秒，你的gc比例为1：1，就是百分百回收。
但是注意：
gc回收是从你的session_start开始，然后执行的是open，read，然后是gc。
具体可以点这里看关于session的执行顺序。
所以即使某个session已经过期，你去读他，还是有值的，下一次就被gc掉了。
（有些朋友可能会想，那第一次读取有值，那判断用户登录与否就不准确了啊，但是真实生产环境，肯定不是单用户，触发session_start机制的情境很多，所以就不足为奇了。）
那么问题来了！！ 当我们不停的在win平台刷新read.php这个页面，session的值一直能拿到。这就奇怪了，应该被回收了啊。怎么还能不停的拿到。理解中session gc是根据文件的最后修改时间与当前时间和ini中设置的maxlifetime时间做对比，然后触发回收机制。
我们来张图
这就是奇葩所在
1、如果把这个session删除掉，然后在直接write，发现创建时间和刚刚删除之前的创建时间一样。名字相同咱可以理解，但是这个时间相同是肿么回事！windows偷懒把回收站给拿回来了？我把他清空了也是这样。
附上个gif图（我是有多无聊~，请用ie浏览器打开此图，或者美图秀秀，acdsee之类）
在linux下session的gc
我本地搭建的virtualbox （ubuntu下的lamp）
配置如下图：
然后在来个动态图：显示写入session，然后查看session文件的状态，再然后读取，第一次读取，是有值的，而且两次查看stat sess**文件还在，我在刷新一次之后，那么值没有了。也就验证了session的流程是open read （gc） write close。请注意我第一次有值是之前打开的，并不是读取的write的值
写在最后：
文章写的有点毛糙，乱起八遭。
最后感谢各位前辈的指点，尤其是cfc4nx。
