問題タブ [unmodifiable]

ArrayLists の ArrayList をスレッドセーフにする必要があります。また、クライアントにコレクションを変更させることもできません。変更不可能なラッパーはスレッド セーフになりますか、それともコレクションに 2 つのラッパーが必要ですか?

Java では、 Collections#unmodifiableList() メソッドを使用して、既存の List オブジェクトから変更不可能なリストを作成できます。C# に対応するものはありますか? 私はこの言語に不慣れで、MSDN ドキュメントでこのようなものを見つけることができませんでした。

これは、指定されたセットの変更不可能なビューを返すことがわかりますが、これを実現するために修飾子をCollections.unmodifiableSet使用できない理由がわかりません。final

私の理解ではfinal、定数を宣言します：変更できないもの。したがって、セットが定数として宣言されている場合、それを変更することはできません。セットから何も削除できず、何も追加できません。

なぜ必要なのCollections.unmodifiableSetですか？

上記のコードを試して、最終的な配列の変数を再割り当てできるかどうかを確認しました[ ans：it can be]。最終的なInteger[]配列では、現在のインスタンスとは別にInteger[]の別のインスタンスを割り当てることができないことを理解しています。最初に割り当てられます。配列変数も変更できないようにすることが可能かどうかを知りたいです。

次のような定数のマップがあります。

Collections.unmodifiableMap()このマップを作成するために本当に を使用する必要がありますか? それを使用する利点は何ですか？それらが実際には一定になっていないという明らかな事実以外に、それを使用しないことの欠点はありますか?

Map インスタンスを返すさまざまなカスタム (ソース コードは利用できません) フレームワークによって少しずつ細かな作業が行われています。残念ながら、これらのフレームワークは、Collections.unmodifiableMap でラップされた Map インスタンスを返す点で一貫性がありません。私のコードで高度な不変性を (より簡単にマルチスレッドで使用できるように) 保証するために、これらのフレームワークによって返されるものに対して Collections.unmodifiableMap を一律に呼び出しました。

設計のこの部分でパフォーマンスの問題が発生する可能性があることに気付きました。また、場合によっては、 Collections.unmodifiableMap を呼び出して、同じ呼び出しでフレームワークによって既にラップされているインスタンスを渡していました。そして、再ラップにより、インスタンス全体で余分なメソッド呼び出しが発生する可能性がありました。

「instanceof Collections.UnmodifiableMap」を使用しても機能しないようです。そして、現在参照している Map インスタンスをラップする必要があるかどうかを検出する方法を見つけることができません (この状況ではオプションではないリフレクションの使用を除く - 遅すぎる)。

質問:

A) Collections.unmodifiableMap() メソッドは、UnmodifiableMap のインスタンスが渡されたかどうかを確認し、渡された場合は同じ参照を返すだけですか (それにより、メソッドを呼び出す前に確認する必要がなくなります)?

B) 変更例外の受信を積極的に回避するために、(リフレクションを使用する以外に) Map インスタンスにクエリを実行して、それが可変 (または不変) かどうかを検出する方法はありますか?

C) A に対する答えが「いいえ」の場合、JVM/HotSpot には、コア インスタンスに到達するために複数のメソッド ホップを介して呼び出すオーバーヘッドを排除する効率がありますか?

Collections.unmodifiableList(...)静的内部クラス の新しいインスタンスを返しますUnmodifiableList。他の変更不可能なコレクション クラスは、同じ方法で構築されます。

これらのクラスが公開された場合、1 つには 2 つの利点がありました。

• より具体的な戻り値 ( などUnmodifiableList) を示す機能。これにより、API ユーザーはそのコレクションを変更するという考えに至りません。
• Listaが であるか実行時にチェックする機能instanceof UnmodifiableList。

では、これらのクラスを公開しないことに利点はありましたか?

編集：確実に説得力のある議論が提示されなかったため、最も支持された回答を選択します。

私が理解している不変コレクションの欠陥が正しいかどうかわからないので、この回答にそれらをリストします。誰かがここで私を訂正してくれることを願っています。

a）：Collections.unmodizableXXX（）と比較すると、ImmutableXXX.copyOf（）はソースコレクション機能を失います。たとえば、linkedListがImmutableList.copyOf（）に入れられると、ImmutableListはリンクされなくなります。ツリーベースのコレクションと同じです。

b）：人々は、Collections.unmodizableXXXがソースコレクションの同じ参照を使用していると考えているため、ソースコレクションが変更されると、Collections.unmodizableXXXも変更されます。しかし、私の解決策は、ソースコレクションをImmutableXXX.copyOf（）に渡される一時コレクションにラップすることです。以下のコードを参照してください。

イミュータブルコレクションについてどう思いますか？ありがとう！

メンバー変数を直接返すのではなく Collections.unmodifiableList() を返すことを提案しましたが、同僚はパフォーマンスが低下するのではないかと懸念しています。もちろん、最良の答えはそれを測定することであり、私たちはそれを行うかもしれませんが、あなたの経験と、賛否両論の参考文献を知りたい.