Set.of(): Неизменяемые множества

В отличие от списков, множества предъявляют дополнительное требование — уникальность элементов.

Методы Set.of() строго проверяют это требование:

Set.of("a", "b", "c");        // Допустимо
Set.of("a", "b", "a");        // IllegalArgumentException: дубликат

Внутренняя структура

Для множеств также существуют оптимизированные реализации:
Пустое множество: Синглтон ImmutableCollections.EMPTY_SET
Множество из 1 элемента: ImmutableCollections.Set1
Множество из 2 элементов: Используется специальная структура для двух элементов
Большие множества: Используется ImmutableCollections.SetN на основе хэш-таблицы

Особенности производительности

Малые множества (до 2 элементов) используют особые алгоритмы сравнения, что делает операции contains() чрезвычайно эффективными — O(1) с очень малой константой.


Map.of(): Неизменяемые отображения

Для создания неизменяемых отображений используются два подхода:

// Прямое создание пар (до 10 пар)
Map.of(k1, v1, k2, v2, ..., k10, v10)

// Создание из пар Map.Entry
Map.ofEntries(
    Map.entry(k1, v1),
    Map.entry(k2, v2),
    // ...
)

Требования к ключам

Как и для множеств, ключи в Map.of() должны быть уникальными. Попытка создания отображения с дублирующимися ключами приводит к IllegalArgumentException.

Внутренняя оптимизация

Для малых отображений используются специализированные реализации:
Пустое отображение: ImmutableCollections.EMPTY_MAP
Отображение из 1 пары: ImmutableCollections.Map1
Отображение из 2 пар: Используется оптимизированная структура
Для больших отображений используется массив пар ключ-значение с линейным поиском, что для небольших N (до ~10) оказывается эффективнее хэш-таблиц.


Collections.unmodifiableXXX(): Подход до Java 9

Методы Collections.unmodifiableList(), unmodifiableSet(), unmodifiableMap() и другие создают обертки над существующими изменяемыми коллекциями. Эти обертки делегируют операции чтения исходной коллекции, но запрещают операции модификации.

Механизм работы

Архитектура обертки

// Концептуальная реализация unmodifiableList
public static <T> List<T> unmodifiableList(List<? extends T> list) {
    return (list instanceof UnmodifiableList) ? 
           (List<T>) list : 
           new UnmodifiableList<>(list);
}

static class UnmodifiableList<E> implements List<E> {
    private final List<E> list;
    
    UnmodifiableList(List<E> list) {
        this.list = list;
    }
    
    public E get(int index) {
        return list.get(index); // Делегирование
    }
    
    public void add(int index, E element) {
        throw new UnsupportedOperationException(); // Запрет модификации
    }
    // ... остальные методы
}

Уровни неизменяемости

Важно понимать, что unmodifiableXXX создают только поверхностную (shallow) неизменяемость:
Структурная неизменяемость: Размер и состав коллекции не могут быть изменены
Элементная изменяемость: Объекты внутри коллекции могут быть изменяемыми

List<StringBuilder> list = new ArrayList<>();
list.add(new StringBuilder("Hello"));
List<StringBuilder> unmodifiable = Collections.unmodifiableList(list);

// Нельзя изменить структуру
unmodifiable.add(new StringBuilder("World")); // UnsupportedOperationException

// Но можно изменить содержимое элементов
unmodifiable.get(0).append(" World"); // Допустимо!

Исторический контекст

До Java 9 подход с unmodifiableXXX был единственным стандартным способом создания неизменяемых представлений.

Однако у него было несколько существенных недостатков:
Изменяемость исходной коллекции: Обертка отражает изменения в исходной коллекции
Возможность обхода защиты: Через приведение типов или reflection
Производительность: Дополнительный уровень индирекции


#Java #для_новичков #beginner #immutability #Collection #List_of #Set_of

Сравнительный анализ подходов

Null-безопасность

Методы List.of() и аналогичные полностью запрещают null элементы, что способствует написанию более безопасного кода. В противоположность этому, unmodifiableXXX позволяют null, если их разрешает исходная коллекция.

Поведение при модификации

// Пример с List.of()
List<String> immutable = List.of("A", "B", "C");
// Любая попытка модификации: UnsupportedOperationException

// Пример с unmodifiableList
List<String> mutable = new ArrayList<>(Arrays.asList("A", "B", "C"));
List<String> wrapper = Collections.unmodifiableList(mutable);

mutable.add("D"); // Изменяем исходный список
System.out.println(wrapper); // ["A", "B", "C", "D"] - обертка отражает изменения
Это фундаментальное различие: List.of() создает полностью независимую коллекцию, тогда как unmodifiableList() создает зависимое представление.

Производительность в деталях

Для List.of() с малым количеством элементов доступ по индексу может быть реализован через прямое поле:

// Концептуально для List.of(e1, e2)
class List2<E> extends AbstractImmutableList<E> {
    private final E e0, e1;
    
    public E get(int index) {
        return switch (index) {
            case 0 -> e0;
            case 1 -> e1;
            default -> throw new IndexOutOfBoundsException();
        };
    }
}

В то время как unmodifiableList всегда требует двойной диспетчеризации: вызов метода обертки → делегирование исходной коллекции.

Итерация

Итераторы для List.of() не имеют логики проверки модификаций и не поддерживают remove(), что делает их более легковесными.


Принципы проектирования неизменяемых коллекций

Паттерн "Builder" для сложных случаев

Для создания сложных неизменяемых коллекций Java предоставляет строители (builders):

// Для List
List<String> list = List.<String>builder()
    .add("A")
    .addAll(anotherList)
    .build();

// Для Map
Map<String, Integer> map = Map.<String, Integer>builder()
    .put("key1", 1)
    .put("key2", 2)
    .build();

Эти строители позволяют создавать неизменяемые коллекции инкрементально, что особенно полезно при динамическом построении.

Копирование с преобразованием

Частый паттерн — создание неизменяемой коллекции на основе существующей с фильтрацией или преобразованием:

List<String> mutable = Arrays.asList("A", "B", "C", null, "D");

// Фильтрация null и создание неизменяемого списка
List<String> immutable = mutable.stream()
    .filter(Objects::nonNull)
    .map(String::toUpperCase)
    .collect(Collectors.toUnmodifiableList());

Безопасность в многопоточных сценариях

Потокобезопасность по умолчанию

Неизменяемые коллекции от природы потокобезопасны. Поскольку их состояние не может быть изменено после создания, множество потоков может одновременно читать коллекцию без какой-либо синхронизации.

Memory visibility

Благодаря принципам Java Memory Model, правильно опубликованная неизменяемая коллекция гарантирует, что все потоки увидят корректное состояние ее элементов:

// Безопасная публикация
public class Configuration {
    public static final List<String> SETTINGS = List.of("A", "B", "C");
    // Все потоки увидят полностью инициализированную коллекцию
}

Отсутствие race conditions

Поскольку нет операций модификации, полностью исключены race conditions, связанные с конкурентным доступом на запись.

Сравнение с synchronized коллекциями

// Synchronized подход (устаревший)
List<String> syncList = Collections.synchronizedList(new ArrayList<>());
// Требует внешней синхронизации для compound операций

// CopyOnWriteArrayList (частичная неизменяемость)
CopyOnWriteArrayList<String> copyOnWrite = new CopyOnWriteArrayList<>();
// Дорогие операции записи, но безопасное чтение

// Полностью неизменяемый подход
List<String> immutable = List.of("A", "B", "C");
// Идеальная потокобезопасность без накладных расходов

#Java #для_новичков #beginner #immutability #Collection #List_of #Set_of

Практические паттерны использования

Конфигурации и константы

public class ApplicationConstants {
    // Конфигурационные параметры
    public static final List<String> SUPPORTED_LANGUAGES = 
        List.of("en", "es", "fr", "de");
    
    public static final Map<String, Integer> DEFAULT_SETTINGS = 
        Map.of("timeout", 30, "retries", 3, "cacheSize", 1000);
}

Возврат из методов

public List<String> getActiveUsers() {
    // Вместо возврата изменяемого списка
    return List.copyOf(internalUserList); // Защитная копия как неизменяемый список
}

Параметры методов

public void processItems(List<String> items) {
    // items должен быть неизменяемым или защищенной копией
    List<String> safeItems = List.copyOf(items);
    // Далее работаем с safeItems
}

Ограничения и когда не использовать

Динамические коллекции

Неизменяемые коллекции не подходят для сценариев, где требуется частое изменение состава:

// НЕПРАВИЛЬНО: постоянное создание новых коллекций
List<String> items = List.of();
for (Item item : source) {
    items = Stream.concat(items.stream(), Stream.of(item.getName()))
                  .collect(Collectors.toUnmodifiableList()); // Очень дорого!
}

// ПРАВИЛЬНО: использование изменяемого построителя
List<String> itemsBuilder = new ArrayList<>();
for (Item item : source) {
    itemsBuilder.add(item.getName());
}
List<String> items = List.copyOf(itemsBuilder);

Большие коллекции

Создание неизменяемых коллекций с помощью List.of() для очень большого количества элементов (тысячи и более) может быть менее эффективно, чем специализированные структуры данных.


Best practices

1. Предпочитайте List.of() над Arrays.asList()

// Хорошо
List<String> good = List.of("A", "B", "C");

// Плохо (возвращает изменяемый список, но фиксированного размера)
List<String> bad = Arrays.asList("A", "B", "C");

2. Защитное копирование при необходимости

public class SafeApi {
    private final List<String> data;
    
    public SafeApi(List<String> input) {
        // Защитное копирование в неизменяемый список
        this.data = List.copyOf(input);
    }
}

3. Документируйте неизменяемость

/**
 * Возвращает неизменяемый список активных пользователей.
 * Попытки модификации приведут к UnsupportedOperationException.
 */
public List<User> getActiveUsers() {
    return Collections.unmodifiableList(internalList);
}

4. Используйте соответствующие типы в сигнатурах

// Хорошо: ясно указывает на намерение
public void processItems(List<? extends String> items) {
    // items может быть любым списком строк, включая неизменяемые
}

// Или даже лучше в Java 16+
public void processItems(SequencedCollection<String> items) {
    // Явное указание на коллекцию с определенным порядком
}

Отладка и диагностика

Выявление скрытых модификаций

Для отладки проблем с неожиданными модификациями можно использовать обертки с логированием:

public static <T> List<T> loggingUnmodifiableList(List<T> list) {
    return new AbstractList<T>() {
        @Override
        public T get(int index) {
            return list.get(index);
        }
        
        @Override
        public int size() {
            return list.size();
        }
        
        @Override
        public void add(int index, T element) {
            logError("Attempt to modify unmodifiable list at index " + index);
            throw new UnsupportedOperationException();
        }
    };
}

Профилирование использования памяти

Неизменяемые коллекции могут привести к неожиданному потреблению памяти, если создается много временных коллекций.

Профилирование помогает выявить такие проблемы:

// Мониторинг создания коллекций
public class CollectionMonitor {
    private static final AtomicLong listCreations = new AtomicLong();
    
    public static <E> List<E> monitoredListOf(E... elements) {
        listCreations.incrementAndGet();
        return List.of(elements);
    }
    
    public static long getCreationCount() {
        return listCreations.get();
    }
}

#Java #для_новичков #beginner #immutability #Collection #List_of #Set_of

Глава 8. Дополнительные аспекты коллекций

Потокобезопасные коллекции и типичные ошибки

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


Эволюция подходов к потокобезопасности в Java

Исторически Java прошла несколько этапов в развитии многопоточных коллекций:
Java 1.0-1.1: Примитивная синхронизация через ключевое слово synchronized
Java 1.2: Введение Collections.synchronizedXXX() методов
Java 5 (J2SE 5.0): Революция с пакетом java.util.concurrent
Java 7-8: Усовершенствование ConcurrentHashMap и других структур
Java 9+: Дальнейшие оптимизации и новые методы

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


Collections.synchronizedList: Классический подход с явной синхронизацией

Collections.synchronizedList() представляет собой декоратор (wrapper) паттерн, применяемый к существующему списку для добавления потокобезопасности. Это подход минимального вмешательства — вместо создания новой потокобезопасной реализации с нуля, мы оборачиваем существующую реализацию в слой синхронизации.

Архитектура реализации

Механизм обертки

// Упрощенная концептуальная реализация
public static <T> List<T> synchronizedList(List<T> list) {
    return (list instanceof RandomAccess ?
        new SynchronizedRandomAccessList<>(list) :
        new SynchronizedList<>(list));
}

static class SynchronizedList<E> implements List<E> {
    final List<E> list;   // Оборачиваемый список
    final Object mutex;   // Объект для синхронизации
    
    SynchronizedList(List<E> list) {
        this.list = list;
        this.mutex = this; // По умолчанию синхронизируемся на обертке
    }
    
    public E get(int index) {
        synchronized (mutex) { return list.get(index); }
    }
    
    public void add(int index, E element) {
        synchronized (mutex) { list.add(index, element); }
    }
    
    // Все методы синхронизированы аналогично
}

Выбор объекта монитора

Ключевое решение в дизайне — выбор объекта для синхронизации:
По умолчанию: сама обертка (this)
Альтернатива: можно передать внешний объект через конструктор SynchronizedList(list, mutex)

Это позволяет нескольким коллекциям синхронизироваться на одном мониторе, обеспечивая атомарность составных операций.


Семантика синхронизации

Уровень синхронизации

Каждый метод обертки синхронизирован индивидуально. Это обеспечивает:
Атомарность отдельных операций: Один поток не может вмешаться в выполнение метода другим потоком
Консистентность данных: Внутреннее состояние коллекции защищено от одновременных модификаций

Ограничения атомарности

Важное ограничение: хотя каждая операция атомарна, последовательность операций — нет:

// ОПАСНО: неатомарная составная операция
List<String> syncList = Collections.synchronizedList(new ArrayList<>());

if (!syncList.contains("item")) {    // Операция 1
    syncList.add("item");            // Операция 2
}
// Между проверкой и добавлением другой поток может добавить элемент

Производительность и contention

Гранулярность блокировок

Collections.synchronizedList использует coarse-grained locking (грубозернистую блокировку):
Одна блокировка на всю коллекцию
Все потоки конкурируют за одну блокировку
Высокий contention при высокой конкуренции


#Java #для_новичков #beginner #immutability #Collection #synchronizedList #ConcurrentHashMap #CopyOnWriteArrayList

Итерация и fail-fast семантика

Синхронизированные обертки не решают проблему итерации:

List<String> syncList = Collections.synchronizedList(new ArrayList<>());

// ОПАСНО: ConcurrentModificationException все еще возможен
for (String item : syncList) {
    // Другой поток может модифицировать список
    syncList.remove("someItem"); // Из другого потока
}

Для безопасной итерации требуется внешняя синхронизация:

List<String> syncList = Collections.synchronizedList(new ArrayList<>());

// Безопасная итерация
synchronized (syncList) {
    Iterator<String> it = syncList.iterator();
    while (it.hasNext()) {
        String item = it.next();
        process(item);
    }
}

ConcurrentHashMap: Современный подход к параллельным отображениям

ConcurrentHashMap представляет собой фундаментально иную философию по сравнению с синхронизированными обертками.

Вместо блокировки всей структуры используется комбинация:
Fine-grained locking (тонкозернистые блокировки)
Lock-free алгоритмы для чтения
CAS операции (Compare-And-Swap)
Сегментирование (в версиях до Java 8)

В Java 8 архитектура была полностью переработана:

// Концептуальная структура с Java 8
public class ConcurrentHashMap<K,V> {
    volatile Node<K,V>[] table;
    
    static class Node<K,V> implements Map.Entry<K,V> {
        final int hash;
        final K key;
        volatile V val;
        volatile Node<K,V> next;
    }
    
    static final class TreeNode<K,V> extends Node<K,V> {
        TreeNode<K,V> parent;
        TreeNode<K,V> left;
        TreeNode<K,V> right;
        TreeNode<K,V> prev;
        boolean red;
    }
}

Инновации:
CAS для вставки: sun.misc.Unsafe.compareAndSwapObject
Tree bins: Преобразование в красно-черные деревья при длинных цепочках
Параллельные операции: forEach, search, reduce


Memory model и happens-before

ConcurrentHashMap обеспечивает строгие гарантии memory ordering:

ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<>();

// Поток 1
map.put("key", 42); // Запись с memory barrier

// Путок 2
Integer value = map.get("key"); // Чтение с happens-before гарантиями
// Гарантированно увидит 42, если нет перезаписи

Atomicity guarantees

// Атомарные операции
map.putIfAbsent(key, value);    // Вставить если отсутствует
map.replace(key, oldValue, newValue); // Заменить если совпадает
map.compute(key, (k, v) -> v == null ? 1 : v + 1); // Атомарное вычисление

Параллельные операции bulk

ConcurrentHashMap<String, Long> wordCounts = new ConcurrentHashMap<>();

// Параллельный forEach
wordCounts.forEach(1, // Параллелизм
    (key, value) -> System.out.println(key + ":" + value));

// Поиск
String result = wordCounts.search(1, 
    (key, value) -> value > 1000 ? key : null);

// Свертка
long total = wordCounts.reduceValues(1, Long::sum);

Параметризация параллелизма

ConcurrentHashMap<String, Data> map = new ConcurrentHashMap<>(
    16,      // initial capacity
    0.75f,   // load factor
    8        // concurrency level (оценочное количество потоков)
);

#Java #для_новичков #beginner #immutability #Collection #synchronizedList #ConcurrentHashMap #CopyOnWriteArrayList

Производительность в различных сценариях

Для сценариев с частым чтением ConcurrentHashMap показывает исключительную производительность:
Чтение полностью lock-free
Минимальный contention между читателями
Эффективное использование кэшей процессора

При частой записи производительность зависит от:
Качества хэш-функции
Количества коллизий
Наличия tree bins
Конкуренции за конкретные бакеты

В конкурентной среде точный размер постоянно меняется. ConcurrentHashMap использует приближенные методы:

ConcurrentHashMap<String, String> map = new ConcurrentHashMap<>();

// Приближенный размер (O(1), но может быть неточным)
int approximateSize = map.size();

// Более точный (но дорогой) подсчет
int exactSize = map.mappingCount(); // Java 8+

// Проверка пустоты (эффективная)
boolean isEmpty = map.isEmpty();

CopyOnWriteArrayList: Оптимизация для read-mostly сценариев

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


Архитектурные принципы

Неизменяемое состояние

public class CopyOnWriteArrayList<E> {
    private transient volatile Object[] array;
    
    final Object[] getArray() {
        return array;
    }
    
    final void setArray(Object[] a) {
        array = a;
    }
}

Ключевые особенности:
Массив объявлен как volatile для обеспечения memory visibility
Все операции чтения работают с текущим массивом
Операции записи создают новую копию

Гарантии consistency

Итераторы обеспечивают strong consistency для snapshot:
Видят состояние на момент создания
Никогда не выбрасывают ConcurrentModificationException
Не поддерживают операцию remove() (UnsupportedOperationException)


Практические паттерны использования

Event listeners и наблюдатели

public class EventPublisher {
    private final CopyOnWriteArrayList<EventListener> listeners =
        new CopyOnWriteArrayList<>();
    
    public void addListener(EventListener listener) {
        listeners.add(listener); // Безопасно даже во время уведомлений
    }
    
    public void publish(Event event) {
        for (EventListener listener : listeners) {
            // Итерация по snapshot - безопасна
            listener.onEvent(event);
        }
    }
}

Кэширование конфигураций

public class ConfigurationCache {
    private volatile CopyOnWriteArrayList<Config> cache;
    
    public ConfigurationCache() {
        cache = new CopyOnWriteArrayList<>();
    }
    
    public void refresh() {
        List<Config> newConfigs = loadConfigs();
        // Атомарная замена всего кэша
        cache = new CopyOnWriteArrayList<>(newConfigs);
    }
    
    public List<Config> getConfigs() {
        return cache; // Безопасное чтение
    }
}

Ограничения и альтернативы

Когда не использовать CopyOnWriteArrayList
Частые модификации: Большие коллекции с частыми изменениями
Реальные требования: Когда нужны актуальные данные, а не snapshot
Ограничения памяти: Когда копирование больших массивов непозволительно

Альтернативные подходы

// Для частых модификаций
List<String> frequentWrites = Collections.synchronizedList(new ArrayList<>());

// Для mixed workloads
ConcurrentLinkedQueue<String> queue = new ConcurrentLinkedQueue<>();

// Для сценариев с преобладанием чтения
List<String> readMostly = new CopyOnWriteArrayList<>();

#Java #для_новичков #beginner #immutability #Collection #synchronizedList #ConcurrentHashMap #CopyOnWriteArrayList

Типичные ошибки многопоточного программирования с коллекциями

ConcurrentModificationException: Анатомия ошибки

ConcurrentModificationException возникает при обнаружении структурных изменений коллекции во время итерации.

Механизм основан на сравнении счетчика модификаций:

// Внутренний механизм ArrayList
protected transient int modCount = 0;

// В итераторе
int expectedModCount = modCount;

void checkForComodification() {
    if (modCount != expectedModCount)
        throw new ConcurrentModificationException();
}

Типичные сценарии возникновения

Сценарий 1: Модификация во время итерации в одном потоке

List<String> list = new ArrayList<>(Arrays.asList("A", "B", "C"));

for (String item : list) {          // Создается итератор
    if (item.equals("B")) {
        list.remove(item);           // modCount++ → исключение!
    }
}

Сценарий 2: Конкурентная модификация в разных потоках

// Поток 1
for (String item : sharedList) {
    process(item);                   // Итерация
}

// Поток 2
sharedList.add("new");              // ConcurrentModificationException в потоке 1

NullPointerException в многопоточном контексте

NullPointerException в многопоточных сценариях часто является следствием race conditions, а не просто нулевых ссылок:

public class UnsafeCache {
    private Map<String, Data> cache = new HashMap<>();
    
    public Data get(String key) {
        Data data = cache.get(key);
        if (data == null) {
            data = loadData(key);         // Дорогая операция
            cache.put(key, data);         // Race condition!
        }
        return data;                      // Может вернуть null
    }
}

Классический антипаттерн с небезопасной публикацией:

public class BrokenSingleton {
    private static Data instance;
    
    public static Data getInstance() {
        if (instance == null) {                    // Первая проверка (без синхронизации)
            synchronized (BrokenSingleton.class) {
                if (instance == null) {            // Вторая проверка
                    instance = new Data();         // Небезопасная публикация!
                }
            }
        }
        return instance;                           // Может вернуть частично инициализированный объект
    }
}

Разные коллекции по-разному обрабатывают null:

// ConcurrentHashMap: запрещает null
ConcurrentHashMap<String, String> chm = new ConcurrentHashMap<>();
chm.put("key", null);               // NullPointerException

// CopyOnWriteArrayList: разрешает null
CopyOnWriteArrayList<String> cowal = new CopyOnWriteArrayList<>();
cowal.add(null);                    // Допустимо

// Collections.synchronizedList: зависит от оборачиваемой коллекции
List<String> syncList = Collections.synchronizedList(new ArrayList<>());
syncList.add(null);                 // Допустимо для ArrayList

#Java #для_новичков #beginner #immutability #Collection #synchronizedList #ConcurrentHashMap #CopyOnWriteArrayList

Race conditions и data races

Race condition: Неправильное поведение из-за непредсказуемого порядка выполнения
Data race: Одновременный доступ к shared memory без proper synchronization

Пример race condition

public class Counter {
    private int count;
    
    public void increment() {
        count++; // Неатомарная операция: read-modify-write
    }
}

// Два потока вызывают increment() 1000 раз каждый
// Ожидаемый результат: 2000
// Фактический результат: что угодно между 1000 и 2000

Пример data race

public class VisibilityProblem {
    private boolean ready = false;
    private int value;
    
    // Поток 1
    public void writer() {
        value = 42;
        ready = true; // Без happens-before!
    }
    
    // Путок 2
    public void reader() {
        if (ready) {
            System.out.println(value); // Может увидеть 0 вместо 42!
        }
    }
}

Deadlock, livelock и starvation

Deadlock с коллекциями

// Классический deadlock с synchronizedList
List<String> list1 = Collections.synchronizedList(new ArrayList<>());
List<String> list2 = Collections.synchronizedList(new ArrayList<>());

// Поток 1
synchronized (list1) {
    synchronized (list2) {  // Ждет list2
        // Критическая секция
    }
}

// Путок 2 (обратный порядок)
synchronized (list2) {
    synchronized (list1) {  // Ждет list1 → DEADLOCK!
        // Критическая секция
    }
}

Livelock в конкурентных алгоритмах

public class LivelockExample {
    private final ConcurrentHashMap<String, Boolean> locks = 
        new ConcurrentHashMap<>();
    
    public void process(String key) {
        // Бесконечные попытки захвата "локера"
        while (!locks.putIfAbsent(key, true)) {
            Thread.yield(); // Livelock: постоянно уступаем, но не прогрессируем
        }
        
        try {
            // Работа с ресурсом
        } finally {
            locks.remove(key);
        }
    }
}

Starvation в synchronized коллекциях

// Поток, постоянно читающий
synchronized (sharedList) {
    // Долгая операция чтения
    processAllElements(sharedList);
}

// Другие потоки не могут получить доступ для записи
// → Starvation писателей

#Java #для_новичков #beginner #immutability #Collection #synchronizedList #ConcurrentHashMap #CopyOnWriteArrayList

Раздел 6. Коллекции в Java

Глава 8. Дополнительные аспекты коллекций

Практика: В «Библиотеке» сделать коллекцию книг потокобезопасной (CopyOnWriteArrayList). Реализовать неизменяемый список популярных книг для чтения

Перед началом убедитесь, что проект готов, и вспомните ключевые концепции:
CopyOnWriteArrayList: Thread-safe версия List, где модификации создают копию массива (copy-on-write), а чтение — без locks. Идеально для read-heavy сценариев (много чтения, мало записи).
Преимущества: Безопасность без синхронизации, итераторы не fail-fast (не бросают ConcurrentModificationException при mod).
Недостатки: Высокий overhead на память и время для модификаций (копия всего списка), не подходит для write-heavy.

Неизменяемые коллекции: Collections.unmodifiableList делает List read-only — методы mod бросают UnsupportedOperationException. Полезно для constants или защиты данных.
Импорты: java.util.concurrent.CopyOnWriteArrayList, java.util.Collections.


Откройте проект

Запустите IDE, откройте LibraryProject. Проверьте List<Book> books, методы addBook, printAllBooks и т.д.
Импортируйте пакеты: В Library.java добавьте import java.util.concurrent.CopyOnWriteArrayList; и import java.util.Collections;. IDE поможет.
Планирование: Мы изменим поле books на CopyOnWriteArrayList, добавим метод для создания неизменяемого списка популярных книг и протестируем в multi-thread (опционально).

Замена List на CopyOnWriteArrayList для потокобезопасности
CopyOnWriteArrayList — отличный выбор для библиотеки, где чтение (поиск, вывод) частое, а запись (добавление книг) редкое. Это сделает коллекцию thread-safe без manual locks.


Измените поле books

В классе Library замените private List<Book> books = new ArrayList<>(); на private CopyOnWriteArrayList<Book> books = new CopyOnWriteArrayList<>();.
Это обеспечит thread-safety: при add/remove создается копия внутреннего массива, читатели видят snapshot.


Обновите конструктор Library

Если инициализация в конструкторе — обновите на CopyOnWriteArrayList.


Обновите метод addBook(Book book)

Используйте books.add(book); — это thread-safe (копия под капотом).
Добавьте проверку: if (book == null) return; или бросьте IllegalArgumentException.
Выведите сообщение о добавлении.


Обновите методы, использующие books

В printAllBooks() или findBookByTitle используйте for-each или Iterator — они работают на snapshot, безопасны при параллельных mod.
В removeBookByIndex(int index): books.remove(index); — thread-safe.


Реализация неизменяемого списка популярных книг

Неизменяемый список — это read-only view, полезный для "популярных" книг, которые не должны изменяться.

Добавьте поле для популярных книг:
В Library добавьте приватное поле List<Book> popularBooks = new ArrayList<>();.
В конструкторе или методе initPopularBooks() добавьте 3-5 статических книг (new Book("1984", "Orwell", 1949) и т.д.).

Сделайте список неизменяемым:
После заполнения popularBooks присвойте ему Collections.unmodifiableList(popularBooks);.
Теперь методы mod (add, remove) бросят UnsupportedOperationException.

Добавьте метод getPopularBooks():
Возвращайте unmodifiable список — public List<Book> getPopularBooks() { return popularBooks; }.
Это безопасно — внешний код не сможет изменить.

Добавьте метод printPopularBooks():
Переберите unmodifiable список и выведите детали книг.
Попробуйте в Main popularBooks.add(new Book(...)) — поймайте исключение.


#Java #для_новичков #beginner #immutability #Collection #synchronizedList #ConcurrentHashMap #CopyOnWriteArrayList #Практика

Тестирование и отладка (объемно)

Базовое тестирование:
В Main добавьте книги, вызовите printAllBooks — всё как раньше.

Неизменяемость тест:
В Main получите getPopularBooks(), попробуйте add/remove — UnsupportedOperationException.
Переберите и выведите — чтение работает.

Отладка нюансов:
В CopyOnWriteArrayList добавьте breakpoint в add — увидите копию массива.
Тестируйте с большим размером (1000 элементов) — замерьте время (System.nanoTime()) для add в multi-thread.
Ловушки: CopyOnWriteArrayList slow для write-heavy — если много добавлений, используйте synchronized List.

Эксперименты (объемно и превышает текущий уровень экспертизы):
Замените на synchronizedList(new ArrayList<>()) — протестируйте thread-safety, но заметьте locks (медленнее для read-heavy).
Добавьте метод addPopularBook(Book book) — но сделайте так, чтобы он работал только до unmodifiable (или используйте builder для init).
Тестируйте с null — CopyOnWriteArrayList позволяет null элементы.
В multi-thread добавьте System.out в add/print — увидите interleaving, но без ошибок.
Измерьте память (Runtime.getRuntime().totalMemory()) перед/после многих add — увидите overhead копий в CopyOnWrite.


Работу данных коллекций мы будем проверять когда дойдем до многопоточности в java.


#Java #для_новичков #beginner #immutability #Collection #synchronizedList #ConcurrentHashMap #CopyOnWriteArrayList #Практика