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:WindowsTemp。當服務器上有多個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的目錄指向一個專用的目錄，例如tmpmyapp。這樣，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文件數目仍然可能導致效率問題。為了解決這一問題，可行的幾種方法有：
如果PHP運行在Linux系統下，使用ReiserFS文件系統取代默認的ext2/ext3文件系統。ReiserFS對於大量小文件的存取性能，比ext2/ext3有極大的提高。
將session.save_path指向一個內存路徑。這意味著，session文件的讀寫只在內存中進行，而不執行磁盤操作。
session.save_path接受一個額外的N參數，用於指定目錄的級數。例如，“5;/tmp” 將導致創建類似這樣的session文件：/tmp/4/b/1/e/3/sess_4b1e384ad74619bd212e236e52a5a174If。具體的說明，請參見：http://cn.php.net/manual/en/session.configuration.php#ini.session.save-path
終極的解決方案，是放棄PHP的session處理機制，自己編碼接管所有的session處理操作，通過session_set_save_handler()函數來實現。通過自己接管session處理，可以將所有的session保存在專門的數據庫（往往使用內存表）中，從而徹底解決session文件帶來的問題，並且可以方便地實現session的共享和復制。這也是大型的PHP應用一般會使用的方式。關於session_set_save_handler()函數的使用，網上和相關圖書都有詳細的說明，這裡不再贅述。值得一提的是，即使在這種方式下，啟動GC的概率仍然取決於session.gc_probability/session.gc_divisor。
