看到以前Mr_jing的session文章,受益不淺。碰巧我也遇到了在win下session的問題。他在文章最後一個有意思的事提到了,當時我看到以後的感受就是,太TMD(甜蜜的)緣分了。再而後我本身整了一篇比較水的日記我所理解的session_set_save_handler的執行順序機制,可仍是不甘心,究竟看看linux下session到底行不行,(如今win下確定是不行的)。php
2.php.ini配置linux
三、代碼開始write.php寫入session,值爲當前時間戳laravel
<?php session_start(); $_SESSION['nametime']=date('Y-m-d H:i:s',time()); echo '已經寫入'.$sessionSavePath = ini_get('session.save_path'); var_dump($_SESSION);
四、讀取session代碼ubuntu
<?php echo '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());
五、執行read.php
看到寫入時間爲17:57:04segmentfault
六、讀取session,能夠看到讀取session的值的(上面紅橢圓圈)時間和寫入時間都同樣,都是
17:57:04,注意下面的readtime那一行是13:58:56,
windows
好的,截至到如今,win上都沒有問題。由於即便你的session的最大生存時間(session.gc_maxlifetime
)爲5秒,你的gc比例爲1:1,就是百分百回收。
可是注意:
gc回收是從你的session_start開始,而後執行的是open,read,而後是gc。
具體能夠點這裏看關於session的執行順序。瀏覽器
因此即便某個session已通過期,你去讀他,仍是有值的,下一次就被gc掉了。
(【有些朋友可能會想,那第一次讀取有值,那判斷用戶登陸與否就不許確了啊,可是真實生產環境,確定不是單用戶,觸發session_start機制的情境不少,因此就不足爲奇了。】以上說法是胡扯的!!!啓動會話後,PHP 根據 session_id 找到並打開了對應的 Session 文件,而後才啓動 GC 進程。GC 進程就只檢查除了當前這個 Session 文件外的其餘文件,發現過時的就幹掉。全部,即便當前這個 Session 文件已通過期了,GC 也沒有刪除它。具體怎麼實現,能夠看源碼<( ̄▽ ̄)/)session
那麼問題來了!!
當咱們不停的在win平臺刷新read.php這個頁面,session的值一直能拿到。這就奇怪了,應該被回收了啊。怎麼還能不停的拿到。理解中session gc是根據文件的最後修改時間與當前時間和ini中設置的maxlifetime時間作對比,而後觸發回收機制。
咱們來張圖
測試
這就是奇葩所在
一、若是把這個session刪除掉,而後在直接write,發現建立時間和剛剛刪除以前的建立時間同樣。名字相同咱能夠理解,可是這個時間相同是腫麼回事!windows偷懶把回收站給拿回來了?我把他清空了也是這樣。
附上個gif圖(我是有多無聊~,請用ie瀏覽器打開此圖,或者美圖秀秀,acdsee之類)
spa
我本地搭建的virtualbox (ubuntu下的lamp)
配置以下圖:
而後在來個動態圖:顯示寫入session,而後查看session文件的狀態,再而後讀取,第一次讀取,是有值的,並且兩次查看stat sess**文件還在,我在刷新一次以後,那麼值沒有了。也就驗證了session的流程是open read (gc) write close
。請注意我第一次有值是以前打開的,並非讀取的write的值
寫在最後:
文章寫的有點毛糙,亂起八遭。
最後感謝各位前輩的指點,尤爲是cfc4nx。
下次再寫清楚 點。。