問題タブ [unmodifiable]

私がコーディングしているプロジェクトでは、関数からスレッド セーフで不変のビューを返す必要があります。しかし、私はこれについて確信が持てません。リストのビューを返すだけなのでsynchronizedList、unmodifiableList

Collections.synchronizedList(Collections.unmodifiableList(this.data));

トリックを行うでしょう。

これが正しいかどうか誰か教えてもらえますか? そうでない場合、これが失敗する可能性がある状況はありますか?

ご意見ありがとうございます。

ドメイン層がコントローラーによって UI から分離されている Java アプリケーションがあります。問題は、これらのコントローラーがドメイン オブジェクトを返すことができ、ドメイン オブジェクトをパラメーターとして持つことができることです。

これらの返されたドメイン オブジェクトの一部は変更可能であり、これを防止したいと考えています。UI（または将来のUI）がコントローラにアクセスせずにドメインを直接変更できないようにしたい.

私は2つのオプションを試しました：

• 最初のものでは、各クラスがゲッターのみを含む「変更不可能な」インターフェースを実装していることを確認しました。また、オブジェクトを UI に返す必要がある場合は、その「変更不可能な」インターフェイスを返しました。UI がゲッターのみを表示できるようにします。これに伴う問題は、それらがまだ元のオブジェクトに簡単にキャストでき、アクセスが得られることです。最初はこのレベルのセキュリティで十分だと思っていましたが、誰かが誤ってオブジェクトをキャストして間違った方法で使用し、整合性が侵害されたことがありました。

• 2 つ目では、返される可能性のある各オブジェクトに変更不可能なラッパーを提供しようとしました。しかし、問題は、これらの返されたオブジェクトがコントローラーのメソッドのパラメーターとして使用できるため、コントローラーでアンラップする必要があることです。uwrap()メソッドをパッケージ プライベートにしようとしましたが、特定のすべてのラッパー クラスをコントローラーと同じパッケージに配置する必要があり、これは少し不便です。

編集：3番目のオプション：

• ( vicに感謝します) 3 番目のオプションでは、オブジェクトは変更不可能なwrapperによってラップされますが、このラッパーによってラップを解除することはできません。各 Unmodifiable は、Hashmap 内のその変更可能なオブジェクトにリンクされています。したがって、「ラップ解除」は、変更不可能なオブジェクトにリンクされている変更可能なオブジェクトを取得することによって行われます。

オブジェクトを変更不可にしてコントローラーから返せるようにし、コントローラーに戻されたときに再度変更可能にする方法を知っている人やアイデアを持っている人はいますか?

このクラスには、Collections、 などのさまざまなコレクション タイプの読み取り専用ビューを提供するための静的ヘルパー メソッドが多数あります。これらのビュー オブジェクトでは、およびメソッドが呼び出しを基になるコレクションに転送します...例外が 1 つあります。unmodifiableSet()unmodifiableList()hashCode()equals()unmodifiableCollection()

JavaDocには明示的に次のように記載されています。

返されたコレクションは、 hashCode および equals 操作をバッキング コレクションに渡しませんObjectが、equalsおよびメソッドに依存していhashCodeます。これは、バッキング コレクションがセットまたはリストである場合に、これらの操作のコントラクトを保持するために必要です。

私の質問: これは何について話しているのですか?? unmodifiableSet()バッキング コレクションがセットまたはリストの場合、 and と一貫した動作が期待できますunmodifiableList()。それは hashCode/equals 契約にどのように違反しますか?

jsf Webサーバーのリストを使用して、たとえばWebページからデータモデルにアクセスしています。これらのリストへのアクセスは、他のさまざまな場所（Webサービス、ツール）からも行われます。

私が返したリストを頼りにしている誰かによって壊れたコードがあります。私が開発者チームの誰かについて話しているのは、このコードを使用しているのは私たちだけです。私はこの関数についておよそ300の参照を持っており、修正をうまく行うことはパフォーマンスに関連している可能性があります。

リストは1〜10000のエントリで、通常は10〜100のリストがあります。実際には、おそらく20のリストがあり、それぞれに8つのエントリがあるので、それほど大したことではありません。しかし、私はもっと時々持つことができます

私はところでこのような関数について話している：

今、私はもちろんこのように戻ることができます：

しかし、これは最終的にはさまざまなプロジェクト/アプリケーションのいくつかの場所で機能しなくなります。変更不可能なものを返し、javadocを追加し、壊れたものをすべて修正するのが最もクリーンです。しかし:-Dこれは仕事です。おそらく、およそ10個のアプリケーションをテストする必要があります。

一方、私は新しいリストを返すことができます、例えば

これはほとんど作業ではありませんが、これに関するパフォーマンスの問題はどうですか？それ以外は、誰かが私が返したリストから何かを削除している場合、それは黙ってアプリケーションを壊します。

だから：パフォーマンスの問題は何ですか？それは問題ですか？

あなたならどうしますか？

読み取りのために複数のスレッド間で共有する必要がある文字列(tagList)のリストがあるので、変更不可能なバージョンを作成してスレッドに渡します。スレッドはそのリストのみを読み取るため、スレッドセーフかどうかはわかりません。それは大丈夫ですか？

また、その変更不可能なリストをスレッドに渡すと、単一のコピーを渡してスレッドで共有しますか、それとも複数のコピーを作成して各スレッドに 1 つのコピーを渡しますか?

ここに私のコードがあります:

私が書いたら

a2読み取り専用ですが、書き込むと

その後a2も変更されます。

API で次のように指定されている場合:

指定されたコレクションの変更不可能なビューを返します。このメソッドにより、モジュールはユーザーに内部コレクションへの「読み取り専用」アクセスを提供できます。

では、元のコレクションを変更すると、コピー先のコレクションも変更されるのはなぜですか?

意味を誤解したのかもしれません。もしそうなら、そのコレクションの防御的なコピーを書く方法は何ですか?

元の Map のサブビューにエントリを追加するときに、JVM は UnsupportedOperationException をキャッチしますが、JVM は元のビューに直接追加することを気にしません。コードは次のように話します。

ただし、Collections.unmodifiableSortedMap() のドキュメントには次のように書かれています。

返されたソート済みマップを変更しようとすると、そのコレクション ビューを介して、またはその subMap、headMap、または tailMap ビューを介して、直接、UnsupportedOperationException が発生します。

手を貸してください、ありがとう。

Collections.unmodifiableList の実装では、指定されたリストが既に UnmodifiableList であっても、常に UnmodifiableList で指定されたリストをラップしていることがわかります... したがって、このメソッドを何度も呼び出すと、次のような巨大なスタック トレースが得られます。

リストが既に UnmodifiabelList であるかどうかを確認し、Google のコレクションと同じように同じリストを返すことを考えましたが、これはパブリック クラスではありません。

これをエレガントに解決する方法はありますか？

ありがとう