由於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 的檔案系統也沒問題了。 

From: