Làm thế nào tôi có thể sao chép bộ sưu tập một cách an toàn?

Trước đây, tôi từng nói sẽ sao chép một cách an toàn một bộ sưu tập làm một việc như:

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

hoặc là

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

Nhưng các hàm tạo "sao chép" này, các phương thức và luồng tạo tĩnh tương tự, có thực sự an toàn không và các quy tắc được chỉ định ở đâu? Nói một cách an toàn, ý tôi là các bảo đảm toàn vẹn ngữ nghĩa cơ bản được cung cấp bởi ngôn ngữ Java và các bộ sưu tập được thi hành chống lại một người gọi độc hại, giả sử được hỗ trợ bởi một hợp lý SecurityManagervà không có sai sót.

Tôi hài lòng với phương pháp ném ConcurrentModificationException, NullPointerException, IllegalArgumentException, ClassCastException, vv, hoặc thậm chí treo.

Tôi đã chọn Stringlàm một ví dụ về một đối số loại bất biến. Đối với câu hỏi này, tôi không quan tâm đến các bản sao sâu cho các bộ sưu tập các loại có thể thay đổi có các vấn đề riêng.

(Để rõ ràng, tôi đã xem mã nguồn OpenJDK và có một số loại câu trả lời cho ArrayListvà TreeSet.)

Không có sự bảo vệ thực sự chống lại mã độc hại cố ý chạy trong cùng một JVM trong các API thông thường, như API Bộ sưu tập.

Như có thể dễ dàng được chứng minh:

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]

Như bạn có thể thấy, hy vọng List<String>không đảm bảo sẽ thực sự có được một danh sách các Stringtrường hợp. Do loại xóa và loại thô, thậm chí không thể khắc phục được về phía thực hiện danh sách.

Một điều khác, bạn có thể đổ lỗi cho nhà ArrayListxây dựng của mình, là sự tin tưởng vào việc toArraytriển khai bộ sưu tập sắp tới . TreeMapkhông bị ảnh hưởng theo cùng một cách, nhưng chỉ vì không có hiệu suất như vậy khi truyền mảng, như khi xây dựng một ArrayList. Cả hai lớp đều không đảm bảo sự bảo vệ trong hàm tạo.

Thông thường, không có điểm nào trong việc cố gắng viết mã giả định mã độc cố ý xung quanh mọi góc. Có quá nhiều thứ có thể làm, để bảo vệ chống lại mọi thứ. Việc bảo vệ như vậy chỉ hữu ích đối với mã thực sự gói gọn một hành động có thể cho phép người gọi độc hại truy cập vào một cái gì đó, nó không thể truy cập mà không có mã này.

Nếu bạn cần sự an toàn cho một mã cụ thể, hãy sử dụng

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);
    }
}

Sau đó, bạn có thể chắc chắn rằng newStrsnó chỉ chứa các chuỗi và không thể được sửa đổi bởi mã khác sau khi xây dựng nó.

Hoặc sử dụng List<String> newStrs = List.of(strs.toArray(new String[0]));với Java 9 hoặc mới hơn
Lưu ý rằng Java 10 cũng List.copyOf(strs)làm như vậy, nhưng tài liệu của nó không nói rằng nó được đảm bảo không tin vào toArrayphương thức của bộ sưu tập đến . Vì vậy, việc gọi List.of(…), chắc chắn sẽ tạo một bản sao trong trường hợp nó trả về một danh sách dựa trên mảng, sẽ an toàn hơn.

Vì không có người gọi nào có thể thay đổi cách thức, các mảng hoạt động, bỏ bộ sưu tập đến vào một mảng, sau đó điền vào bộ sưu tập mới với nó, sẽ luôn làm cho bản sao an toàn. Vì bộ sưu tập có thể giữ một tham chiếu đến mảng được trả về như đã trình bày ở trên, nên nó có thể thay đổi nó trong giai đoạn sao chép, nhưng nó không thể ảnh hưởng đến bản sao trong bộ sưu tập.

Vì vậy, bất kỳ kiểm tra tính nhất quán nên được thực hiện sau khi phần tử cụ thể đã được truy xuất từ ​​mảng hoặc trên toàn bộ bộ sưu tập kết quả.

Tôi muốn để lại thông tin này trong bình luận, nhưng tôi không có đủ danh tiếng, xin lỗi :) Tôi sẽ cố gắng giải thích nó dài dòng nhất có thể sau đó.

Thay vì một cái gì đó như const sửa đổi được sử dụng trong C ++ để đánh dấu các hàm thành viên không được phép sửa đổi nội dung đối tượng, trong Java ban đầu được sử dụng khái niệm "bất biến". Đóng gói (hoặc OCP, Nguyên tắc đóng mở) được cho là để bảo vệ chống lại mọi đột biến (thay đổi) bất ngờ của một đối tượng. Tất nhiên API phản chiếu đi xung quanh điều này; truy cập bộ nhớ trực tiếp làm như vậy; đó là nhiều hơn về chụp chân của chính mình :)

java.util.Collection chính nó là giao diện có thể thay đổi: nó có add phương thức được cho là sửa đổi bộ sưu tập. Tất nhiên, lập trình viên có thể gói bộ sưu tập vào thứ gì đó sẽ ném ... và tất cả các ngoại lệ thời gian chạy sẽ xảy ra do một lập trình viên khác không thể đọc javadoc, trong đó nói rõ rằng bộ sưu tập là bất biến.

Tôi quyết định sử dụng java.util.Iterableloại để trưng bày bộ sưu tập bất biến trong các giao diện của mình. Về mặt ngữ nghĩa Iterablekhông có đặc tính của bộ sưu tập là "tính đột biến". Tuy nhiên, rất có thể bạn sẽ có thể sửa đổi các bộ sưu tập cơ bản thông qua các luồng.

JIC, để hiển thị bản đồ theo cách không thay đổi java.util.Function<K,V>có thể được sử dụng ( getphương pháp của bản đồ phù hợp với định nghĩa này)