問題タブ [thread-local]

私は、昔ながらのほとんどが JDBC のパターンでいくつかのサーブレットを作成しています。単一のトランザクションを共有したいオブジェクトがいくつかあることに気付きました。1 つの HTTP トランザクション = 1 つのデータベース トランザクションを強制したいと考えています。

ThreadLocal変数で接続を渡し、その接続の作成/コミット/ロールバックを処理するサーブレットフィルターを使用することで、これを行うことができると思います。

私が関与していないこれを行う既存のフレームワークはありますか、それともこれは2000年代後半の合理的な方法ですか?

本質的に、ブロックが終了するまで、スタック上のその部分の下のすべての呼び出しによって到達可能な変数をスタックに配置したいと考えています。Java では、メソッドからアクセスできるサポート メソッドを備えた静的スレッド ローカルを使用してこれを解決します。

典型的な例: リクエストを受け取り、データベース接続を開きます。リクエストが完了するまで、すべてのコードでこのデータベース接続を使用する必要があります。要求を終了して閉じた後、データベース接続を閉じます。

これが必要なのは、レポートジェネレーターです。各レポートは複数の部分で構成され、各部分は異なる計算に依存する場合があり、異なる部分が同じ計算に部分的に依存する場合もあります。重い計算を繰り返したくないので、それらをキャッシュする必要があります。私の考えは、メソッドをキャッシュ デコレータで装飾することです。キャッシュは、メソッド名とモジュールに基づいて id を作成し、その引数は、これがスタック変数で既に計算されているかどうかを調べ、そうでない場合はメソッドを実行します。

現在の実装を示すことで明確にしようと思います。私がやりたいのは、計算を実装するためのコードを単純化することです。

まず、MathContext と呼ぶ中央キャッシュ アクセス オブジェクトがあります。

fn 引数は、コンテキストが関連して作成されるファイル名であり、そこからデータを読み取って計算することができます。

次に、Calculation クラスがあります。

そして、これはばかげたフィボナッチの例です。メソッドは実際には再帰的ではなく、代わりに大量のデータセットで機能しますが、他の計算にどのように依存するかを示すために機能します。

代わりにフィボナッチにしたいのは、装飾されたメソッドです。

math_context の例では、math_context が範囲外になると、キャッシュされた値もすべて範囲外になります。デコレータにも同じことが必要です。すなわち。ポイント X では、@cache によってキャッシュされたものはすべて参照解除されて gced されます。

メソッドObjectOutputStream.writeStreamHeader()をオーバーライドして、データをヘッダーの先頭または末尾に追加できます。ただし、そのデータが次のような派生クラスのコンストラクターに渡される引数に基づいている場合:

が初期化されて呼び出さsuper()れる前に呼び出されるため、機能しません。これを回避する唯一の方法は、次のように使用することです。m_myDatasuper()writeStreamHeader()ThreadLocal

これは機能しているように見えますが、より良い (不格好でない) 方法はありますか?

ThreadLocal はどのように実装されていますか? それはJavaで実装されていますか（ThreadIDからオブジェクトへの同時マップを使用していますか）、それともJVMフックを使用してより効率的に実行していますか？

最近、一部のプラットフォームでスレッドローカルストレージが制限されていることに気づきました。たとえば、C++ライブラリのブースト::スレッドのドキュメントは次のとおりです。

「注：作成できるスレッド固有のストレージオブジェクトの数には実装固有の制限があり、この制限は小さい場合があります。」

さまざまなプラットフォームの制限を見つけようと探していましたが、信頼できるテーブルを見つけることができませんでした。TLSを使用するクロスプラットフォームアプリを作成している場合、これは重要な質問です。Linuxは、2002年にIngo MonarがTLSサポートを追加するカーネルリストに送信したパッチの形で情報を見つけた唯一のプラットフォームでした。彼は次のように述べています。「TLS領域の数は無制限であり、関連する追加の割り当てオーバーヘッドはありません。 TLSサポート付き。」2009年にまだ真実である場合（そうですか？）、かなり気の利いたものです。

しかし、今日のLinuxはどうですか？OS X？ウィンドウズ？Solaris？組み込みOS？複数のアーキテクチャで実行されるOSの場合、アーキテクチャによって異なりますか？

編集：なぜ制限があるのか​​知りたい場合は、スレッドローカルストレージ用のスペースが事前に割り当てられることを考慮してください。そのため、すべてのスレッドでそのコストを支払うことになります。たくさんのスレッドに直面して少量でも問題になる可能性があります。

ここで示したThreadLocalの目的は、変数がThreadLocal変数を含むオブジェクトにアクセスするすべてのスレッドに対してローカルであることを示しています。ThreadLocal変数をクラスのメンバーとして持ち、それをスレッド自体に対してローカル変数にするのではなく、スレッドに対してローカルにするという点で、どのような違いがありますか？

私の以前の質問を参照して、もう少し進んで、

1. ローカル変数ではなく ThreadLocals を使用することの欠点は何ですか
2. それらはどのように実装されていますか
3. セッション変数は ThreadLocals ですか
4. 頻繁に使用される ThreadLocals の例は他にもありますか

次のイディオムを持つレガシーコードを見ています：

Intelli-J のコード インスペクションから得られる警告は次のとおりです。

これは適切な同期ですか? またその理由は?

クラスReentrantReadWriteLockには、次の興味深いコメントがあります。

「可視性を確保する」とはどういう意味ですか? 私が尋ねる理由は、スレッド ローカルの readHolds がリセットされているように見える状況があるためです (スレッド ローカルは WeakReferences として実装されているため、含まれている Sync オブジェクトがまだ生きている限り、それは発生しないはずです)。setState/getState は単に別のインスタンス変数を変更し、readHolds には触れないでください。

スレッドローカルデータベース接続を使用する場合、スレッドが存在するときに接続を閉じる必要があります。

これは、呼び出し元のスレッドのrun（）メソッドをオーバーライドできる場合にのみ実行できます。それでも素晴らしい解決策ではありません。終了時に、そのスレッドによって接続が開かれたことがあるかどうかはわかりません。

問題は実際にはもっと一般的です：スレッドが終了するときにスレッドローカルオブジェクトのファイナライズメソッドを呼び出すようにスレッドを強制する方法。

java 1.5のソースを調べたところ、スレッドローカルマップがnullに設定されていることがわかりました。これにより、最終的にガベージコレクションがfinalize（）を呼び出すようになりますが、ガベージコレクターを頼りにしたくありません。

データベース接続を確実に閉じるには、次のオーバーライドが避けられないようです。

ここで、release（）は、データベース接続が開かれている場合は、データベース接続を閉じます。しかし、スレッドがこのスレッドローカルを使用したことがあるかどうかはわかりません。get（）がこのスレッドによって呼び出されたことがない場合は、ここでかなりの労力が無駄になります。ThreadLocal.initialValue（）が呼び出され、このスレッドにマップが作成されます。

Thorbjørnのコメントによるさらなる説明と例：

java.lang.ThreadLocalは、スレッドにバインドされているオブジェクトのファクトリの一種です。このタイプには、オブジェクトのゲッターとファクトリメソッド（通常はユーザーが作成）があります。getterが呼び出されると、このスレッドによって以前に呼び出されたことがない場合にのみ、ファクトリメソッドが呼び出されます。

ThreadLocalを使用すると、開発者は、スレッドコードがサードパーティによって作成された場合でも、リソースをスレッドにバインドできます。

例： MyTypeというリソースタイプがあり、スレッドごとに1つだけにしたいとします。

usingクラスで定義します。

このクラスのローカルコンテキストで使用します。

get（）は、呼び出し元のスレッドのライフサイクルで一度だけinitialValue（ ）を呼び出すことができます。その時点で、MyTypeのインスタンスがインスタンス化され、このスレッドにバインドされます。このスレッドによるget（）の後続の呼び出しは、このオブジェクトを再度参照します。

典型的な使用例は、MyTypeがスレッドセーフでないtext / date/xmlフォーマッターである場合です。

しかし、そのようなフォーマッターは通常、解放または閉じる必要はありません。データベース接続は解放する必要があります。私はjava.lang.ThreadLocalを使用して、スレッドごとに1つのデータベース接続を確立しています。

私の見方では、java.lang.ThreadLocalはそのためにほぼ完璧です。呼び出し元のスレッドがサードパーティのアプリケーションに属している場合、リソースのクローズを保証する方法がないためです。

私はあなたの頭脳の従者が必要です：java.lang.ThreadLocalを拡張することによって、私はスレッドごとに1つのデータベース接続をバインドすることができました。これは、変更またはオーバーライドできないスレッドを含む排他的な使用法です。キャッチされない例外でスレッドが停止した場合に備えて、接続が確実に閉じられるようにしました。

通常のスレッド終了の場合、ガベージコレクターは接続を閉じます（MyTypeがfinalize（）をオーバーライドするため）。実際には、それは非常に迅速に発生しますが、これは理想的ではありません。

もし私が自分のやり方を持っていたら、java.lang.ThreadLocalに別のメソッドがあったでしょう：

このメソッドがjava.lang.ThreadLocalに存在し、スレッドの終了/終了時にJVMによって呼び出された場合、それを自分でオーバーライドして、接続を閉じることができます（そして、償還者はZionに来たはずです）。

そのような方法がない場合、私は閉鎖を確認する別の方法を探しています。JVMガベージコレクションに依存しない方法。