ThreadLocal
最近、オブジェクトを使用してその中に保持するコードを見つけましたConcurrentHashMap
。
これには論理/利点がありますか、それとも冗長ですか?
ThreadLocal
最近、オブジェクトを使用してその中に保持するコードを見つけましたConcurrentHashMap
。
これには論理/利点がありますか、それとも冗長ですか?
同時ハッシュマップへの唯一の参照がにある場合ThreadLocal
、ハッシュマップは明らかに単一のスレッドからのみ参照されます。そのような場合、私はそれが完全に冗長であると言うでしょう。
ただし、誰かがスレッドを「共有」することを想像するのは難しいことではありません-ローカルに保存されたハッシュマップを他のスレッドと共有します。
ThreadLocal<ConcurrentHashMap<String, String>> tl = ...
// ...
final ConcurrentHashMap<String, String> props = tl.get();
EventQueue.invokeLater(new Runnable() {
public void run() {
props.add(key.getText(), val.getText());
}
});
ThreadLocal
彼は間違って使用したか、ConcurrentHashMap
間違って使用しました。組み合わせが理にかなっている可能性は0に近いです。
@aioobeが言ったことに加えて、InheritableThreadLocal
localの値がスレッドからそれが作成する各子スレッドに渡される場合を考えてみましょう。
そして、@ pstが言うように、同じ値が異なる(継承できない)で使用されるのを防ぐことはできませんThreadLocal
。
要するに、スレッドローカルがスレッドセーフである必要がないと安全に結論付ける前に、スレッドローカル、それらが初期化される方法、およびそれらが使用される方法を徹底的に分析する必要があります。