Java 9 führte neue Factory-Methoden für Listen ein List.of:

List<String> strings = List.of("first", "second");

Was ist der Unterschied zwischen der vorherigen und der neuen Option? Das heißt, was ist der Unterschied zwischen diesem:

Arrays.asList(1, 2, 3);

und das:

List.of(1, 2, 3);

Arrays.asListliefert eine veränderbare Liste , während die Liste zurück durch List.ofist unveränderlich :

List<Integer> list = Arrays.asList(1, 2, null);
list.set(1, 10); // OK

List<Integer> list = List.of(1, 2, 3);
list.set(1, 10); // Fails with UnsupportedOperationException

Arrays.asListerlaubt null Elemente, während List.ofnicht:

List<Integer> list = Arrays.asList(1, 2, null); // OK
List<Integer> list = List.of(1, 2, null); // Fails with NullPointerException

contains verhält sich anders mit Nullen:

List<Integer> list = Arrays.asList(1, 2, 3);
list.contains(null); // Returns false

List<Integer> list = List.of(1, 2, 3);
list.contains(null); // Fails with NullPointerException

Arrays.asListGibt eine Ansicht des übergebenen Arrays zurück, sodass die Änderungen am Array auch in der Liste angezeigt werden. Denn List.ofdas ist nicht wahr:

Integer[] array = {1,2,3};
List<Integer> list = Arrays.asList(array);
array[1] = 10;
System.out.println(list); // Prints [1, 10, 3]

Integer[] array = {1,2,3};
List<Integer> list = List.of(array);
array[1] = 10;
System.out.println(list); // Prints [1, 2, 3]

Die Unterschiede zwischen Arrays.asListundList.of

Siehe die JavaDocs und diesen Vortrag von Stuart Marks (oder früheren Versionen davon).

Für die Codebeispiele verwende ich Folgendes:

List<Integer> listOf = List.of(...);
List<Integer> asList = Arrays.asList(...);
List<Integer> unmodif = Collections.unmodifiableList(asList);

Strukturelle Unveränderlichkeit (oder: Unmodifizierbarkeit)

Jeder Versuch, sich strukturell zu verändern, List.offührt zu einem UnsupportedOperationException. Dazu gehören Vorgänge wie Hinzufügen , Festlegen und Entfernen . Sie können jedoch den Inhalt der Objekte in der Liste ändern (wenn die Objekte nicht unveränderlich sind), sodass die Liste nicht "vollständig unveränderlich" ist.

Dies ist das gleiche Schicksal für nicht veränderbare Listen, die mit erstellt wurden Collections.unmodifiableList. Nur diese Liste ist eine Ansicht der ursprünglichen Liste, sodass sie sich ändern kann, wenn Sie die ursprüngliche Liste ändern.

Arrays.asListist nicht vollständig unveränderlich, es gibt keine Einschränkung auf set.

listOf.set(1, "a");  // UnsupportedOperationException
unmodif.set(1, "a"); // UnsupportedOperationException
asList.set(1, "a");  // modified unmodif! unmodif is not truly unmodifiable

In ähnlicher Weise ändert das Ändern des Hintergrundarrays (wenn Sie es gedrückt halten) die Liste.

Strukturelle Unveränderlichkeit bringt viele Nebenwirkungen mit sich, die mit defensiver Codierung, Parallelität und Sicherheit zusammenhängen und über den Rahmen dieser Antwort hinausgehen.

Null Feindseligkeit

List.ofund jede Sammlung seit Java 1.5 nicht nullals Element zulassen . Der Versuch, nullals Element oder sogar als Suche zu übergeben, führt zu a NullPointerException.

Da Arrays.asListes sich um eine Sammlung aus 1.2 (dem Collections Framework) handelt, können nulls.

listOf.contains(null);  // NullPointerException
unmodif.contains(null); // allowed
asList.contains(null);  // allowed

Serialisierte Form

Da List.ofes in Java 9 eingeführt wurde und die mit dieser Methode erstellten Listen eine eigene (binäre) serialisierte Form haben, können sie in früheren JDK-Versionen nicht deserialisiert werden (keine Binärkompatibilität ). Sie können jedoch beispielsweise mit JSON de / serialisieren.

Identität

Arrays.asListInterne Anrufe new ArrayList, die Referenzungleichheit garantieren.

List.ofhängt von der internen Implementierung ab. Die zurückgegebenen Instanzen können Referenzgleichheit haben, aber da dies nicht garantiert ist, können Sie sich nicht darauf verlassen.

asList1 == asList2; // false
listOf1 == listOf2; // true or false

Erwähnenswert ist, dass Listen gleich sind (via List.equals), wenn sie dieselben Elemente in derselben Reihenfolge enthalten, unabhängig davon, wie sie erstellt wurden oder welche Operationen sie unterstützen.

asList.equals(listOf); // true i.f.f. same elements in same order

Implementierung (Warnung: Details können sich über Versionen ändern)

Wenn die Anzahl der Elemente in der Liste von List.of2 oder weniger beträgt, werden die Elemente in Feldern einer speziellen (internen) Klasse gespeichert. Ein Beispiel ist die Liste, in der 2 Elemente gespeichert sind (Teilquelle):

static final class List2<E> extends AbstractImmutableList<E> {
    private final E e0;
    private final E e1;

    List2(E e0, E e1) {
        this.e0 = Objects.requireNonNull(e0);
        this.e1 = Objects.requireNonNull(e1);
    }
}

Andernfalls werden sie auf ähnliche Weise wie in einem Array gespeichert Arrays.asList.

Zeit- und Raumeffizienz

Die List.offeldbasierten Implementierungen (Größe <2) arbeiten bei einigen Operationen etwas schneller. Als Beispiele size()können eine konstante zurückzukehren , ohne die Arraylänge Abrufen und contains(E e)nicht Iteration Overhead erfordert.

Das Erstellen einer nicht veränderbaren Liste über List.ofist ebenfalls schneller. Vergleichen Sie den obigen Konstruktor mit 2 Referenzzuweisungen (und sogar der für eine beliebige Anzahl von Elementen) mit

Collections.unmodifiableList(Arrays.asList(...));

Dadurch werden 2 Listen plus anderer Overhead erstellt. In Bezug auf den Platz sparen Sie den UnmodifiableListWrapper plus ein paar Cent. Letztendlich sind die Einsparungen im HashSetÄquivalent überzeugender.

Abschlusszeit: Verwenden List.ofSie diese Option, wenn Sie eine Liste wünschen, die sich nicht ändert, undArrays.asList wenn Sie eine Liste möchten, die sich ändern kann (wie oben gezeigt).

Fassen wir die Unterschiede zwischen List.of und Arrays.asList zusammen

1. List.ofkann am besten verwendet werden, wenn der Datensatz kleiner und unverändert ist, während Arrays.asListam besten bei großen und dynamischen Datensätzen verwendet werden kann.

2. List.ofNehmen Sie sehr wenig Overhead-Speicherplatz in Anspruch, da die Implementierung vor Ort erfolgt und weniger Heap-Speicherplatz verbraucht wird, sowohl in Bezug auf den festen Overhead als auch auf Elementbasis. während Arrays.asListnehmen mehr Kopfraum , weil während der Initialisierung es mehr Objekte im Heap erzeugt.

3. Die von zurückgegebene Sammlung List.ofist unveränderlich und daher threadsicher, während die von zurückgegebene Sammlung Arrays.asListveränderlich und nicht threadsicher ist. (Unveränderliche Sammlungsinstanzen verbrauchen im Allgemeinen viel weniger Speicher als ihre veränderlichen Gegenstücke.)

4. List.oferlaubt keine Nullelemente , während NullelementeArrays.asList erlaubt sind.

Abgesehen von den oben genannten Antworten gibt es bestimmte Operationen an den beide List::ofund Arrays::asListunterscheiden:

+----------------------+---------------+----------+----------------+---------------------+
|      Operations      | SINGLETONLIST | LIST::OF | ARRAYS::ASLIST | JAVA.UTIL.ARRAYLIST |
+----------------------+---------------+----------+----------------+---------------------+
|          add         |       ❌      |     ❌  |        ❌      |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|        addAll        |       ❌      |     ❌  |        ❌      |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|         clear        |       ❌      |     ❌  |        ❌      |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|        remove        |       ❌      |     ❌  |        ❌      |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|       removeAll      |       ❗️       |     ❌   |        ❗️       |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|       retainAll      |       ❗️       |     ❌  |        ❗️        |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|      replaceAll      |       ❌      |     ❌  |        ✔️       |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|          set         |       ❌      |     ❌  |        ✔️       |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|         sort         |       ✔️       |     ❌   |        ✔️      |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|  remove on iterator  |       ❌      |     ❌  |        ❌      |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
| set on list-iterator |       ❌      |     ❌  |        ✔️       |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+

1. ✔️ bedeutet, dass die Methode unterstützt wird
2. ❌ bedeutet, dass beim Aufrufen dieser Methode eine UnsupportedOperationException ausgelöst wird
3. ❗️ bedeutet, dass die Methode nur unterstützt wird, wenn die Argumente der Methode keine Mutation verursachen, z. B. Collections.singletonList ("foo"). RetainAll ("foo") ist in Ordnung, Collections.singletonList ("foo"). RetainAll ("bar") ) löst eine UnsupportedOperationException aus

Mehr über Informationen zu Collections :: singletonList Vs. Liste von