PHP セッションのガベージ コレクション メカニズム

概要

PHP の動作メカニズムにより、セッション情報を定期的にスキャンし、セッション情報が無効かどうかを判断するデーモン スレッドがありません。有効なリクエストが発生すると、PHP はグローバル変数 session.gc_probability/session.gc_divisor (php.ini または ini_set() 関数を通じて変更することもできます) の値に基づいて GC (ガベージ コレクター) を開始するかどうかを決定します。 。デフォルトでは、session.gc_probability = 1、session.gc_divisor = 100 です。これは、GC が開始される確率が 1% であることを意味します。 GC の仕事は、すべてのセッション情報をスキャンし、現在の時刻からセッションの最終変更時刻 (変更日) を減算し、それを session.gc_maxlifetime パラメーターと比較し、生存時間が gc_maxlifetime を超えている場合は、セッションを削除することです。 。

gc_maxlifetime は無効です

それでは、なぜ gc_maxlifetime が無効になるのでしょうか?

1. デフォルトでは、セッション情報はテキスト ファイルの形式でシステムの一時ファイル ディレクトリに保存されます。 Linux では、このパスは通常 tmp であり、Windows では通常 C:WindowsTemp です。サーバー上に複数の PHP アプリケーションがある場合、それらのセッション ファイルは同じディレクトリに保存されます。同様に、これらの PHP アプリケーションも一定の確率で GC を開始し、すべてのセッション ファイルをスキャンします。問題は、GC が動作しているときに、異なるサイト上のセッションが区別されないことです。たとえば、サイト A の gc_maxlifetime は 2 時間に設定され、サイト B の gc_maxlifetime はデフォルトの 24 分に設定されます。サイト B の GC が開始されると、パブリック一時ファイル ディレクトリがスキャンされ、サイト A からのものかサイト B からのものかに関係なく、24 分より古いすべてのセッション ファイルが削除されます。このように、サイト A の gc_maxlifetime 設定は役に立ちません。問題が見つかったら、修正するのは簡単です。 session.save_path パラメータを変更するか、session_save_path() 関数を使用して、セッションが保存されるディレクトリを専用のディレクトリに指定します。 gc_maxlifetime パラメータは正常に機能します。

2. もう 1 つの問題は、gc_maxlifetime が保証できるのはセッションの存続時間の最短時間だけであり、この時間を過ぎるとセッション情報はすぐに削除されることです。 GC は確率に基づいて開始され、長期間開始されない可能性があるため、gc_maxlifetime を超えた後も多数のセッションが有効になります。この問題を解決する 1 つの方法は、session.gc_probability/session.gc_divisor の確率を高めることです。これを 100% に引き上げると、この問題は完全に解決されますが、パフォーマンスに重大な影響を与えることは明らかです。もう 1 つの方法は、コード内で現在のセッションの存続期間を確認し、それが gc_maxlifetime を超えた場合は、現在のセッションをクリアすることです。

gc の動作原理

php セッションの GC 関数はガベージ コレクターです。この GC が開始されると、「タイムアウト」になったセッションがクリアされます。仕組みは次のとおりです:

1. ユーザーが Web サイトにアクセスしてログインすると、バックグラウンドは session_start を呼び出してセッションを生成しようとします (すでにセッションがある場合、それは有効なセッション リクエストと同等です)
2. そのような有効なセッション リクエストごとに (リクエスト)、Apache の PHP モジュールは、セッション関連のグローバル変数 gc_probability/gc_divisor => に基づいて GC を開始する確率を計算し、この確率を使用して、このリクエストで GC を開始するかどうかを決定します。たとえば、session.gc_probability のデフォルト値が 1、session.gc_divisor のデフォルト値が 100 の場合、「ガベージ コレクション」が開始される確率は 1% になります。これは、100 リクエストごとに、ガベージ コレクションが開始されることを意味します。期限切れのセッションをクリーンアップすることが可能です
3. GC が開始されると、GC は現在のセッションのパス (session.save_path) にあるすべてのセッション ファイルをスキャンし、別のグローバル変数 session.gc_maxlifetime ("current 「time」と「セッションファイルのatimeまたはmtime」の差がgc_maxlifetime:expiredより大きい場合は、期限切れのセッションを削除してください
4. セッション開始後、長時間対話操作がなかった場合(例えば、ノンストップコーディングワード、送信されていない、または下書きとして保存されていない場合）、バックグラウンドで保存されたセッションファイルは、gc_maxlifetime（デフォルト値 1440 秒 = 24 分）後に変更またはアクセスされる機会がなくなり、無効になる可能性があります。 . クリアされた後、再度送信するとセッションが無効であるためエラーが報告されます

ご理解ください

session_id はブラウザ（クライアント）の Cookie に保存されますので、ブラウザを閉じてください。 sessiond_id cookie はこの時点で無効になります。サーバー側のセッション ファイルは存在する可能性がありますが、削除されていません。
ユーザーが 24 分間操作を行わなかった場合 (サーバーにリクエストを送信し、ブラウザーが開いている場合)、セッション ファイルは 24 分後にアクセスされると、同じ内容の新しいセッション ファイルがガベージ コレクションされる可能性があります。 session_id が元の session_id として作成されます。この時点で、元のセッション ファイルの内容は存在しません。
自動ログインでは、session_id Cookieの有効期間を設定せず、ログイン情報（ユーザー名、パスワードなど）を含むCookieをブラウザ側に保存します。
session_id の効果時間はブラウザを閉じて再度ブラウザを開くと終了し、新しい session_id (新しいセッション ファイル) が生成されます。
サーバー側でセッション ファイルが無効 (削除) であるかどうかを確認します。現在時刻 - ファイル変更時刻 > gc_maxlifetime、この時点では無効になります。
スクリプトが実行されるたびに、ファイル変更時刻が変更されます

原文

http://blog.csdn.net/21aspnet/article/details/7218923