ThreadLocal;毎回変数のコピーを作成するのと同じではありませんか？

Question

私はまだThreadLocalという概念を混同しています。私はJavaDocと他の関連する質問をここに掲載していますが、使用される専門用語はすべて私をあまり助けませんでした。

私はある種のThreadLocalを得ています。つまり、各スレッドには変数のコピーがあります。だから...これは、どうやってこれと違って、毎回新しい変数を作るのだろうか？

public void convertDate(String date) 
{ 
    // Contruct new date formatter for every invocation of the method. 
    DateFormatter df = new SimpleDateFormatter(...); 
    .... 
} 

public void convertDate(String date) 
{ 
    // Getting date formatter from threadlocal. 
    DateFormatter df = threadLocal.get(); 
    .... 
} 

がどのように第二のものとは異なる最初はすべて二つだけの変数の新しいコピーを返しているんされている場合：例として、たDateFormatterを使用して例えば

、？

ありがとうございました。

Answer 1

ThreadLocalオブジェクトは通常静的です。つまり、同じスレッド内の関数呼び出し間で値を保持します。

最初のコードスニペットでは、convertDateが呼び出されるたびに、新しいSimpleDateFormatterオブジェクトが作成されます。 2番目のスニペットでは、スレッドごとに1つのSimpleDateFormatterオブジェクトが作成されます。 convertDateが同じスレッド内で呼び出されるたびに、同じオブジェクトがget()メソッドによって返されます。

ThreadLocalオブジェクトは、thread-local storageを実装するのに便利です。これは、スレッドごとに変数のインスタンスを個別に維持することを意味します。

Answer 2

ThreadLocalにはいくつかの用途があります。

この例のように、スレッドが安全でないオブジェクトをキャッシュするには高価です。それ以来、オブジェクトは、毎回構築のオーバーヘッドなしで安全な方法で使用することができます。それは必ずしも勝利ではありません（例えば、非ローカルメモリが使用されます）が、それは可能性があります。

また、コンテキスト引数を使用してコンテキストを持つように設計されていないコールバックに「sleaze」することもできます。インターフェイスを簡単にすることもできます。この場合、ThreadLocalへの標準的な参照はおそらく静的ではありません。オブジェクトは意図的に変更可能でもあります。私はこの技術を奨励するファンではありませんが、ボブ・リー氏のような人々はそれを好きです。

ThreadLocalは、タスクを複数のスレッドにフォークするときにうまく機能しません。 InheritableThreadLocalはあまり役に立たないようです。

Answer 3

2つ目のメソッドが毎回別のスレッドで呼び出される場合、2つの例は同じです。この場合、最初の例がより効率的です。

ただし、同じスレッドで同じメソッドを複数回呼び出すと、そのスレッドの値がキャッシュされ、毎回新しいオブジェクトを作成する必要はありません。 （日付に関連するオブジェクトの大半はかなり高価ですが、その場合は実行する価値があります）この場合、スレッド内で同じオブジェクトを再利用する場合のパフォーマンスのメリットは小さくなります。

注：スレッドローカルオブジェクトは、スレッド自体に添付されたマップに格納されています。スレッドが終了すると、そのスレッドにローカルなすべてのオブジェクトがGCされます。これは、ThreadLocalがほとんどのキャッシュより簡単にできる場所です。