Arrays.asList () vs Collections.singletonList ()

C'è un vantaggio (o molta differenza) nell'uso di Arrays.asList (qualcosa) rispetto a Collections.singletonList (qualcosa) per creare un elenco contenente un elemento? Quest'ultimo rende immutabile anche l'elenco restituito.

Collections.singletonList(something)è immutabile mentre Arrays.asList(something)è una Listrappresentazione a dimensione fissa di un array in cui l'elenco e l'array vengono uniti nell'heap.

Arrays.asList(something)consente modifiche non strutturali apportate ad esso, che vengono riflesse sia nella Lista che nella matrice congiunta. Genera UnsupportedOperationExceptionper l'aggiunta, la rimozione di elementi sebbene sia possibile impostare un elemento per un determinato indice.

Tutte le modifiche apportate all'elenco restituito da Collections.singletonList(something)comporteranno UnsupportedOperationException.

Inoltre, la capacità dell'elenco restituito Collections.singletonList(something)sarà sempre 1 a differenza della Arrays.asList(something)cui capacità sarà la dimensione dell'array supportato.

Vorrei solo aggiungere che la singletonlist non è supportata da un array e ha solo un riferimento a quell'unico elemento. Presumibilmente, richiederebbe meno memoria e può essere significativo a seconda del numero di elenchi che si desidera creare.

Il metodo Arrays.asListrestituisce un elenco di dimensioni fisse supportato dall'array specificato. Il metodo restituisce un'istanza di ArrayListcui è una classe statica nidificata privata che si estende AbstractListe non java.util.ArrayList. Questa classe statica fornisce l'implementazione di pochi metodi, ad es set, indexOf, forEach, replaceAll. Ecc. Ma quando invochiamo addnon ha un'implementazione propria, piuttosto AbstractListviene invocato il metodo da che genera java.lang.UnsupportedOperationException.

I Collections.singletonListrendimenti di una lista immutabile contenente solo l'oggetto specificato ed è serializzabile pure.

In una nota a margine , per gli elenchi immutabili usiamo generalmente ciò Collections.unmodifiableListche restituisce una vista non modificabile dell'elenco specificato.

List<String> srcList = Arrays.asList("Apple", "Mango", "Banana");
var fruits = new ArrayList<>(srcList);
var unmodifiableList = Collections.unmodifiableList(fruits);     
fruits.set(0, "Apricot");
var modFruit = unmodifiableList.get(0);
System.out.println(modFruit); // prints Apricot

Una raccolta di viste non modificabile è una raccolta non modificabile ed è anche una vista su una raccolta di supporto. Si noti che le modifiche alla raccolta di backup potrebbero essere ancora possibili e, se si verificano, sono visibili attraverso la vista non modificabile.

Possiamo avere un vero elenco immutabile in Java 10 e versioni successive. Esistono due modi per ottenere un elenco davvero non modificabile :

1. var unmodifiableList = List.copyOf(srcList);
2. var unmodifiableList = srcList.stream().collect(Collectors.toUnmodifiableList()); Se viene utilizzata una di queste due variabili, il valore sarà comunque "Apple" e non "Albicocca".

Secondo il documento di Java 10 :

I metodi factory statici List.ofe List.copyOfforniscono un modo conveniente per creare elenchi non modificabili. Le istanze di Elenco create con questi metodi hanno le seguenti caratteristiche:

1. Sono immodificabili . Gli elementi non possono essere aggiunti, rimossi o sostituiti. La chiamata a qualsiasi metodo mutatore sull'Elenco provoca sempre il UnsupportedOperationExceptionlancio. Tuttavia, se gli elementi contenuti sono essi stessi mutabili, ciò può far sembrare che il contenuto dell'elenco cambi.
2. Non consentono elementi nulli. I tentativi di crearli con elementi null risultano in NullPointerException.
3. Sono serializzabili se tutti gli elementi sono serializzabili.
4. L'ordine degli elementi nell'elenco è uguale all'ordine degli argomenti forniti o degli elementi nell'array fornito.
5. Lo sono value-based. I chiamanti non devono fare ipotesi sull'identità delle istanze restituite. Le fabbriche sono libere di creare nuove istanze o riutilizzare quelle esistenti. Pertanto, le operazioni sensibili all'identità in queste istanze (uguaglianza di riferimento (==), codice hash identità e sincronizzazione) non sono affidabili e dovrebbero essere evitate.
6. Sono serializzati come specificato nella pagina Modulo serializzato .