bookこの広告は、90日以上更新していないブログに表示しています。グローバルインタープリタロックと共に使用するのは稀です。これに対して、幾つか注目すべき例外があります。オブジェクトがスレッドセーフではないとき、内部的なスレッドセーフを維持するために使用するメソッドです。オブジェクトが同時に複数のスレッドによって変更されないことを保証します。内部構造をロックしています。明示的にロックされずに複数スレッドによって変更されるリストは、不規則的な動作もするでしょう。開発におけるスレッドの利便性を低くします。直接的にリクエスト間(間接的に、クライアント経由で、状態はセッションやクッキー、又は似たようなものを使用して維持されるかもしれません)の状態を維持できません。各々のリクエストは新しいスレッドです:何のデータがリクエストされたかを決定するデータを取得するデータをフォーマットするデータを送信するこれらの行程の1つ1つは、その前の行程からの状態情報に依存します。非同期処理では多くの箱はありません。サーバへ送り返されることです。ように、それはサーバ/フレームワークで解決されることで、利点も持っています。アプリケーションでは、しかしながら、単純なデータベースのフロントエンドではありません。具体的に言うと、リクエストの副作用があるときです。リクエストのみが副作用を持つとあなたに伝えるでしょう。これは語弊があります。ユーザが意図した副作用のために使用されるべきです。私にメールを送信します。これは素晴らしい(そして、時々迷惑な)機能です。その問題が、そのコードというよりむしろ、私たちが入力したデータによって引き起こされたとしたらどうだろうか?私は、コードの中でこれを検出し、そのユーザに迷惑をかけたことを謝罪する素敵なエラーページを表示します。今は、私は何らかの方法でデータベースのあるエントリが不正であるという内容をチームへ知らせたいです。リモートメールサーバへ接続しているならば、しばらく時間がかかります。これはスレッドの良い使用方法です。そのスレッドは、副作用どころか集中して、できるだけ小さなデータ処理を扱うべきです。使用するのに注意してください。クライアントへデータを返す前にスレッドの終了を待たないということを伝えています。プログラムは静的なファイルへデータを書き込みます。アプリケーションによってはログを保持します。ファイルをエンタープライズサーバへ公開します。スレッドの凄い使用方法があります。リモートのデータをキャッシュする私たちは大企業の、様々な(しばしば独立した)部署でアプリケーションを開発します。私は、しばしば、私のアプリケーションが他のシステムから展開された可変データに依存していて、しかし、そのデータのデータベースへ直接アクセスできない状況に遭遇します。低階層の内部ネットワーク遅延や各々の読み込まれたページ上で展開されたデータをダウンロードするのに依存するよりも、私はそのデータを同期するためのスクリプトを使用しながら、ローカルコピーを保持してそのデータをキャッシュします。低レベルキャッシュを使用しながら保存されます。そのデータを維持するために幾つかの状態が必要になる場合、データベーステーブルがより良い方法です。多くのそのようなオブジェクトがあるとき、定期的な更新処理は大きな負荷になります。オブジェクトの数が規則的に増加するような場合です。それ故に、その解法は、そのデータが(ページ読み込みで)アクセスされたイベントをトリガーにすることです。各々のキャッシュされたデータベースエントリは、その最後の更新を書き留めるためのタイムスタンプフィールドを取得します。そのモデルは更新メソッドを定義します。メソッドは、データが更新される必要があるかどうかを調べるために、そのエントリのタイムスタンプを調べます。更新処理は、別々のスレッドで呼び出されます。経由でアクセスされるからです。