1

とにかく、私のThreadLocalシングルトンがリクエストの存続期間中のみ存続する場合は、リクエスト属性を使用しないのはなぜですか？これは、リクエストオブジェクトを通過したり、リクエストオブジェクトに到達したりすることなく、単一のスレッドでコンテキストを取得するための簡単な方法ですか？

4

3 に答える 3

2

ThreadLocal私の意見では、変数を使用するよりもリクエスト属性を使用する方が望ましいということです。

ThreadLocalこれによりコードがきれいになり、 (同じスレッドを再利用する別の要求のコンテキストで再利用される可能性があるため)のクリーニングについて心配する必要はありません。

ThreadLocalただし、 の使用法ThreadLocalがカプセル化されていて、インスタンスを異なるクラス間で単純に共有しない場合 (およびそのライフサイクルが適切に処理される場合) は、適切に設計およびコーディングされたローカル リクエスト ストレージ経由で問題ありません。

于 2012-04-27T17:47:00.470 に答える
1

大規模な多層アプリケーションでは、通常、作業の範囲が Web 要求であると想定したり、下位層内の本質的に「Web」に依存したりすることは望ましくありません。この作業単位をバックグラウンド ジョブとして実行するとどうなるでしょうか。それとも、最終的にサポートすることになるレガシー バイナリ インターフェース経由で到着しますか?

于 2012-04-27T17:53:48.663 に答える
1

ThreadLocal シングルトンを使用することの欠点は、他のコンテキストでシングルトンを使用することの欠点と同じです。カプセル化、再利用性、および機能をモックアウトする機能が失われます。

利点は、使いやすさ、型の安全性 (キャストなし)、および場合によってはパフォーマンス (ただし、物事の全体的なスキームではおそらく重要ではありません) です。

機能が十分にカプセル化されていて、コードの非常に高いレベルのレイヤーでのみアクセスされる場合を除き、ThreadLocal シングルトンを使用しないことをお勧めします (シングルトンにアクセスする代わりに、コンテキストをより深いクラスや関数に明示的に渡します)。

于 2012-04-27T17:56:29.020 に答える