Как я могу безопасно копировать коллекции?

В прошлом я говорил, что для безопасного копирования коллекции сделайте что-то вроде:

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

или

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

Но действительно ли эти «копирующие» конструкторы, подобные статические методы создания и потоки действительно безопасны и где указаны правила? Под безопасностью я подразумеваю базовые гарантии семантической целостности, предлагаемые языком Java и коллекциями, которые применяются против злонамеренного вызывающего, при условии, что они подкреплены разумными данными SecurityManagerи что в них нет недостатков.

Я доволен метод метания ConcurrentModificationException, NullPointerException, IllegalArgumentException, ClassCastExceptionи т.д., или , возможно , даже висит.

Я выбрал Stringв качестве примера аргумент неизменного типа. На этот вопрос меня не интересуют глубокие копии коллекций изменяемых типов, которые имеют свои собственные ошибки.

(Чтобы было ясно, я посмотрел исходный код OpenJDK и у меня есть какой-то ответ за ArrayListи TreeSet.)

Нет реальной защиты от намеренно вредоносного кода, работающего в той же JVM в обычных API, таких как API Collection.

Как легко можно продемонстрировать:

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]

Как вы можете видеть, ожидание List<String>не гарантирует получение списка Stringэкземпляров. Из-за стирания типов и необработанных типов на стороне реализации списка даже исправить невозможно.

Другая вещь, за которую вы можете винить ArrayListконструктора, это доверие к реализации входящей коллекции toArray. TreeMapне подвержен такому же влиянию, но только потому, что при передаче массива нет такого выигрыша в производительности, как в конструкции ArrayList. Ни один класс не гарантирует защиту в конструкторе.

Обычно нет смысла пытаться писать код, предполагающий намеренно вредоносный код на каждом шагу. Слишком много всего можно сделать, чтобы защититься от всего. Такая защита полезна только для кода, который действительно инкапсулирует действие, которое может дать злоумышленнику доступ к чему-либо, к которому он уже не может получить доступ без этого кода.

Если вам нужна безопасность для конкретного кода, используйте

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

Тогда вы можете быть уверены, что newStrsон содержит только строки и не может быть изменен другим кодом после его создания.

Или используйте List<String> newStrs = List.of(strs.toArray(new String[0]));с Java 9 или новее.
Обратите внимание, что Java 10 List.copyOf(strs)делает то же самое, но в документации не говорится, что он не будет доверять toArrayметоду входящей коллекции . Поэтому вызов List.of(…), который обязательно сделает копию в случае, если он возвращает список на основе массива, безопаснее.

Поскольку никакой вызывающий объект не может изменить способ, массивы работают, выгрузив входящую коллекцию в массив, а затем заполнив новую коллекцию, всегда сделайте копию безопасной. Поскольку коллекция может содержать ссылку на возвращенный массив, как показано выше, она может изменить ее на этапе копирования, но это не может повлиять на копию в коллекции.

Таким образом, любые проверки согласованности должны выполняться после того, как конкретный элемент был извлечен из массива или из результирующей коллекции в целом.

Я бы предпочел оставить эту информацию в комментариях, но у меня недостаточно репутации, извините :) Я постараюсь объяснить это настолько многословно, насколько смогу.

Вместо чего-то вроде constмодификатора, используемого в C ++ для обозначения функций-членов, которые не должны изменять содержимое объекта, в Java изначально использовалась концепция «неизменяемости». Инкапсуляция (или OCP, принцип Open-Closed) должна была защищать от любых неожиданных мутаций (изменений) объекта. Конечно, API отражения идет вокруг этого; прямой доступ к памяти делает то же самое; это больше о стрельбе по собственной ноге :)

java.util.Collectionсам по себе является изменяемым интерфейсом: у него есть addметод, который должен модифицировать коллекцию. Конечно, программист может заключить коллекцию во что-то, что выкинет ... и все исключения во время выполнения произойдут, потому что другой программист не смог прочитать javadoc, который ясно говорит, что коллекция неизменна.

Я решил использовать java.util.Iterableтип, чтобы выставить неизменную коллекцию в моих интерфейсах. Семантически Iterableне имеет такой характеристики коллекции, как «изменчивость». Тем не менее, вы (скорее всего) сможете изменять базовые коллекции с помощью потоков.

JIC, для показа карт в неизменном виде java.util.Function<K,V>можно использовать ( getметод map соответствует этому определению)