ThreadLocalをデータのコンテキストとして使用することをお勧めしますか？

Question

WebアプリケーションのデータのコンテキストとしてThreadLocalを使用することをお勧めしますか？

Answer 1

これはそのために作られたものです。ただし、コンテキストの終わりにThreadLocalを削除するよう注意してください。そうしないと、メモリリークが発生したり、少なくとも未使用のデータを長時間保持したりする可能性があります。

ThreadLocalsも非常に高速です。HashMap<Thread,Object>と考えることができます。これは常にThread.getCurrentThread()と照会されます。

Answer 2

これはデータの範囲によって異なります。 ThreadLocalは、ユーザーのセッションに固有のものではなく、要求スレッド固有のものです（各要求ごとに異なる要求処理スレッドが使用されます）。したがって、要求処理が完了したときにデータを削除することが重要になります（同じスレッドが要求を処理するときに他のユーザーのセッションに流入しないようにするため）。

Answer 3

1つのスレッドでリクエスト/レスポンスのペアを完成させているのであれば、私の経験ではうまく動作します。しかし、「イベント駆動型」Webアプリケーションは、Ajaxと高性能コンテナの登場により流行しています。これらのイベント駆動型モデルは、リクエストスレッドをそれらのスレッドプールに返すことを可能にする。 I/Oイベント中にスレッドが占有されず、外部サービス呼び出しが戻るのを待機します。その結果、単一の論理要求が複数の異なるスレッドによって処理される可能性があります。イベント駆動アーキテクチャとサーバー側のNIOを組み合わせることで、スループットが大幅に向上します。

あなたのアプリケーションにこのアーキテクチャがない場合は、私にとっては妥当と思われます。

このモデルに慣れていない場合は、Tomcat 6の「彗星」とJetty 6のContinuationsをご覧ください。これは、公式サーブレット3.0のサポートが予定されている非同期入出力のベンダー固有の実装です。 Tomcat 7は完全に3.0に準拠していると主張しています。

Answer 4

ThreadLocalは、マルチスレッドプログラムでは、スレッド化されていないプログラムの静的/グローバルとほとんど同じです。すなわち、ThreadLocalの使用は偽物です。

Answer 5

一般的に私はいいえと言います。あなたのためにフレームワークを使用してください。

WebアプリケーションのWeb層では、セッションスコープ（またはその他のフレームワーク特有のコンテキスト）を使用して、データを格納し、要求スコープで状態を示します。

ビジネス層を導入する場合、それはもちろん特定のウェブコンテキストに依存すべきではありません。 springおよびJava EEは、セキュリティ、トランザクションおよび永続性のためのソリューションをコンテキストとして提供します。

これを手動でタッチすると、本当に注意する必要があります。それは、クリーンアップの問題、メモリリーク、および奇妙なバグにつながる可能性があります...