Bagaimana saya bisa menyalin koleksi dengan aman?

Di masa lalu, saya telah mengatakan untuk menyalin koleksi dengan aman, lakukan sesuatu seperti:

public static void doThing(List<String> strs) {
    List<String> newStrs = new ArrayList<>(strs);

atau

public static void doThing(NavigableSet<String> strs) {
    NavigableSet<String> newStrs = new TreeSet<>(strs);

Tetapi apakah konstruktor "salin" ini, metode dan aliran penciptaan statis yang serupa, benar - benar aman dan di mana aturan ditentukan? Maksud saya adalah jaminan integritas semantik dasar yang ditawarkan oleh bahasa Jawa dan koleksi yang diberlakukan terhadap penelepon jahat, dengan asumsi didukung oleh alasan yang masuk akal SecurityManagerdan tidak ada kekurangan.

Saya senang dengan metode lempar ConcurrentModificationException, NullPointerException, IllegalArgumentException, ClassCastException, dll, atau mungkin bahkan menggantung.

Saya telah memilih Stringsebagai contoh dari argumen tipe yang tidak dapat diubah. Untuk pertanyaan ini, saya tidak tertarik pada salinan yang dalam untuk koleksi jenis yang bisa berubah yang memiliki gotcha sendiri.

(Untuk lebih jelasnya, saya telah melihat kode sumber OpenJDK dan memiliki beberapa jenis jawaban untuk ArrayListdan TreeSet.)

Tidak ada perlindungan nyata terhadap kode jahat yang sengaja dijalankan dalam JVM yang sama di API biasa, seperti API Pengumpulan.

Seperti yang dapat dengan mudah ditunjukkan:

public static void main(String[] args) throws InterruptedException {
    Object[] array = { "foo", "bar", "baz", "and", "another", "string" };
    array[array.length - 1] = new Object() {
        @Override
        public String toString() {
            Collections.shuffle(Arrays.asList(array));
            return "string";
        }
    };
    doThing(new ArrayList<String>() {
        @Override public Object[] toArray() {
            return array;
        }
    });
}

public static void doThing(List<String> strs) {
    List<String> newStrs = new ArrayList<>(strs);

    System.out.println("made a safe copy " + newStrs);
    for(int i = 0; i < 10; i++) {
        System.out.println(newStrs);
    }
}

made a safe copy [foo, bar, baz, and, another, string]
[bar, and, string, string, another, foo]
[and, baz, bar, string, string, string]
[another, baz, and, foo, bar, string]
[another, bar, and, foo, string, and]
[another, baz, string, another, and, foo]
[string, and, another, foo, string, foo]
[baz, string, foo, and, baz, string]
[bar, another, string, and, another, baz]
[bar, string, foo, string, baz, and]
[bar, string, bar, another, and, foo]

Seperti yang Anda lihat, mengharapkan List<String>tidak menjamin untuk benar-benar mendapatkan daftar Stringinstance. Karena penghapusan tipe dan jenis mentah, bahkan tidak ada perbaikan yang mungkin pada sisi implementasi daftar.

Hal lain, Anda dapat menyalahkan ArrayListkonstruktor, adalah kepercayaan pada toArrayimplementasi koleksi yang masuk . TreeMaptidak terpengaruh dengan cara yang sama, tetapi hanya karena tidak ada keuntungan kinerja seperti itu dari melewati array, seperti dalam konstruksi suatu ArrayList. Kelas tidak menjamin perlindungan pada konstruktor.

Biasanya, tidak ada gunanya mencoba menulis kode dengan asumsi kode jahat sengaja ada di setiap sudut. Ada terlalu banyak yang bisa dilakukan, untuk melindungi dari segalanya. Perlindungan semacam itu hanya berguna untuk kode yang benar-benar merangkum tindakan yang dapat memberikan akses penelepon jahat ke sesuatu, itu tidak bisa diakses tanpa kode ini.

Jika Anda membutuhkan keamanan untuk kode tertentu, gunakan

public static void doThing(List<String> strs) {
    String[] content = strs.toArray(new String[0]);
    List<String> newStrs = new ArrayList<>(Arrays.asList(content));

    System.out.println("made a safe copy " + newStrs);
    for(int i = 0; i < 10; i++) {
        System.out.println(newStrs);
    }
}

Kemudian, Anda dapat yakin bahwa newStrsitu hanya berisi string dan tidak dapat dimodifikasi oleh kode lain setelah konstruksinya.

Atau gunakan List<String> newStrs = List.of(strs.toArray(new String[0]));dengan Java 9 atau yang lebih baru.
Perhatikan bahwa Java 10 List.copyOf(strs)melakukan hal yang sama, tetapi dokumentasinya tidak menyatakan bahwa ia dijamin tidak mempercayai metode pengumpulan yang masuk toArray. Jadi menelepon List.of(…), yang pasti akan membuat salinan kalau-kalau mengembalikan daftar berbasis array, lebih aman.

Karena tidak ada penelepon yang dapat mengubah cara, array bekerja, membuang koleksi yang masuk ke dalam array, diikuti dengan mengisi koleksi baru dengannya, akan selalu membuat salinan aman. Karena koleksi dapat menyimpan referensi ke array yang dikembalikan seperti yang ditunjukkan di atas, itu bisa mengubahnya selama fase salin, tetapi itu tidak dapat mempengaruhi salinan dalam koleksi.

Jadi setiap pemeriksaan konsistensi harus dilakukan setelah elemen tertentu telah diambil dari array atau pada koleksi yang dihasilkan secara keseluruhan.

Saya lebih suka meninggalkan informasi ini dalam komentar, tetapi saya tidak memiliki reputasi yang cukup, maaf :) Saya akan mencoba menjelaskannya sebanyak mungkin.

Alih-alih sesuatu seperti constpengubah yang digunakan dalam C ++ untuk menandai fungsi anggota yang tidak seharusnya mengubah konten objek, di Jawa awalnya digunakan konsep "immutability". Enkapsulasi (atau OCP, Prinsip Terbuka-Tertutup) seharusnya melindungi terhadap setiap mutasi (perubahan) objek yang tidak terduga. Tentu saja refleksi API berjalan sekitar ini; akses memori langsung melakukan hal yang sama; itu lebih lanjut tentang menembak kaki sendiri :)

java.util.Collectionitu sendiri adalah antarmuka yang bisa berubah: ia memiliki addmetode yang seharusnya mengubah koleksi. Tentu saja programmer dapat membungkus koleksi menjadi sesuatu yang akan dibuang ... dan semua pengecualian runtime akan terjadi karena programmer lain tidak dapat membaca javadoc yang dengan jelas mengatakan bahwa koleksi tidak dapat diubah.

Saya memutuskan untuk menggunakan java.util.Iterabletipe untuk mengekspos koleksi abadi di antarmuka saya. Semantik Iterabletidak memiliki karakteristik koleksi seperti "mutabilitas". Anda masih (kemungkinan besar) dapat memodifikasi koleksi yang mendasarinya melalui aliran.

JIC, untuk mengekspos peta dengan cara yang tidak java.util.Function<K,V>dapat diubah dapat digunakan ( getmetode peta sesuai dengan definisi ini)