例があればList<String> strings
、書き続けますか:
Collections.unmodifiableList(strings)
または次のように切り替えます。
List.of(strings.toArray(new String[strings.size()]))
インスタンス化のパフォーマンス (メモリおよびランタイムに関する) への最初の影響は何ですか? List.of
バリアントに実行時の利点はありますか?
例があればList<String> strings
、書き続けますか:
Collections.unmodifiableList(strings)
または次のように切り替えます。
List.of(strings.toArray(new String[strings.size()]))
インスタンス化のパフォーマンス (メモリおよびランタイムに関する) への最初の影響は何ですか? List.of
バリアントに実行時の利点はありますか?
これらのアプローチは異なることを行うため、これは実際には適切な比較ではありません。
Collections::unmodifiable...
変更不可能なビューを作成します。元のバッキング コレクション (この例では) を変更すると変更されるため、不変ではありませんlist
。...::of
一方、不変のコピーを作成します。元のリストを変更しても影響はありません。パフォーマンスの観点からは、1 つのフィールドを持つ 1 つのインスタンスしか作成しないため、変更不可能なラッパーを作成する方が安価であることは明らかです。新しいファクトリ メソッドは、少なくとも 1 つのオブジェクトを作成し、おそらく配列 (要素が 3 つ以上ある場合) によってバックアップされ、そこにコピーする必要があります。
新しい不変コレクションではアクセスが高速になる可能性がありますが、それにはベンチマークが必要です。
しかし、正確さはパフォーマンスに勝ります。何が必要ですか? 不変のcopyが必要な場合は、新しいメソッド (またはImmutable...
私が好むGuava の ) を使用してください。不変なものが必要な場合はunmodifiable...
、元のものを使用して破棄します (そして、そのままにしておくようにしてください)。呼び出し元が編集できないビューが必要な場合は、 を使用しますunmodifiable...
。