Collections.synchronizedSet: примеры (JAVA)

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

1. Базовая обертка над HashSet:

import java.util.*;

Set<String> set = new HashSet<>();
Set<String> sync = Collections.synchronizedSet(set);
sync.add("a");
sync.add("b");
System.out.println(sync);

[a, b]  // порядок может отличаться

2. Итерация с внешней синхронизацией (безопасно):

Set<Integer> s = Collections.synchronizedSet(new HashSet<>());
s.add(1); s.add(2); s.add(3);

synchronized (s) {
    for (Integer i : s) {
        System.out.println(i);
    }
}

1
2
3  // порядок не гарантирован

3. Попытка создать оболочку с null (ошибка):

Set<String> s = Collections.synchronizedSet(null);

Exception in thread "main" java.lang.NullPointerException
    at java.util.Objects.requireNonNull(Objects.java:...) 
    at java.util.Collections.synchronizedSet(Collections.java:...)

4. Использование с исходным множеством, доступным извне (модификации отражаются):

Set<String> base = new HashSet<>();
Set<String> wrapper = Collections.synchronizedSet(base);
base.add("x");
System.out.println(wrapper.contains("x"));

true

Альтернативы внутри Java и их особенности

• Collections.synchronizedCollection / synchronizedList / synchronizedMap - аналогичные обертки для других коллекций. Подход одинаковый: синхронизация на возвращаемом объекте.
• CopyOnWriteArraySet - из java.util.concurrent. Подходит для множеств с редкими модификациями и частыми чтениями. Итераторы не требуют внешней синхронизации и не выбрасывают ConcurrentModificationException, но модификации дорогие (копирование массива).
• ConcurrentSkipListSet - конкурентное сортированное множество. Подходит для упорядоченных данных с высокой конкуренцией.
• ConcurrentHashMap.newKeySet() - эффективное конкурентное множество, основанное на ConcurrentHashMap. Часто предпочтительнее synchronizedSet при высокой конкуренции, так как обеспечивает более тонкую блокировку и лучшую масштабируемость.

Когда выбирать: если требуется простая, быстрая миграция существующего не потокобезопасного Set - synchronizedSet удобен. Если ожидаться высокая конкурентная нагрузка или длительные неподдерживаемые составные операции - лучше рассмотреть структуры из java.util.concurrent.

Аналоги в других языках и отличия

• Python: встроенный set не потокобезопасен для составных операций. Часто используется threading.Lock, например:

import threading
s = set()
lock = threading.Lock()

with lock:
    s.add('a')

with lock:
    for x in s:
        print(x)

a

Отличие: в Python явная блокировка руками, нет стандартной оболочки, аналогичной Collections.synchronizedSet.

• JavaScript (Node.js / браузер): Set однопоточен в основном потоке, поэтому синхронизация обычно не требуется. В многопоточной среде (Worker Threads) требуется передача сообщений или собственные примитивы синхронизации.
• C#: часто используется ConcurrentDictionary для имитации множества (ключи без значений) или ImmutableHashSet/ConcurrentBag. Пример с ConcurrentDictionary:

var set = new System.Collections.Concurrent.ConcurrentDictionary<string, byte>();
set.TryAdd("a", 0);
Console.WriteLine(set.ContainsKey("a"));

True

• Go: нет встроенного множества; обычно используется map[T]struct{} плюс sync.RWMutex для синхронизации:

type SafeSet struct {
    m map[string]struct{}
    mu sync.RWMutex
}

func (s *SafeSet) Add(v string) {
    s.mu.Lock()
    defer s.mu.Unlock()
    s.m[v] = struct{}{}
}

(нет прямого вывода - реализация обеспечивает безопасность)

Кратко: в большинстве языков требуется либо ручная блокировка, либо использование специализированных конкурентных структур. Java предоставляет удобную оболочку и также набор конкурентных коллекций в java.util.concurrent.

Типичные ошибки и последствия

• Отсутствие внешней синхронизации при итерации. Итератор самого synchronizedSet не синхронизирован, поэтому безопасная итерация требует synchronized(wrapper) { ... }. Без этого возможно ConcurrentModificationException или непредсказуемые результаты.
• Непонимание атомарности составных операций. Вызов двух методов (contains и then add) не атомарен, даже если оба метода синхронизированы. Для атомарности требуется внешний synchronized-блок, охватывающий обе операции.
• Передача null в Collections.synchronizedSet вызывает NullPointerException.
• Ожидание масштабируемости как у concurrent структур. synchronizedSet использует один монитор для всех операций, что при высокой нагрузке приводит к узкому месту. В таких сценариях предпочтительнее ConcurrentHashMap.newKeySet или CopyOnWriteArraySet.

Пример ошибки с итерацией без блокировки (возможный вывод при конкурентном изменении):

Set<Integer> s = Collections.synchronizedSet(new HashSet<>());
s.add(1); s.add(2);

for (Integer i : s) { // нет synchronized(s)!
    // если в другом потоке произойдет модификация, может быть исключение
    System.out.println(i);
}

Exception in thread "main" java.util.ConcurrentModificationException
    at java.util.HashMap$HashIterator.nextNode(HashMap.java:...)
    ...

Изменения и история

Метод Collections.synchronizedSet присутствует в API с ранних версий Java (начиная с Java 1.2). За последние релизы крупных изменений в его поведении не вносилось. Основное развитие направлено на появление альтернатив в пакете java.util.concurrent (Java 5 и далее): ConcurrentHashMap, CopyOnWriteArraySet, ConcurrentSkipListSet, которые предоставляют более тонкую или специализированную модель конкурентного доступа.

Таким образом, сам synchronizedSet стабилен и сохраняет старую семантику: синхронизация на возвращаемом объекте и необходимость внешней блокировки при итерации.

Расширенные и нетипичные сценарии использования

1. Сочетание synchronizedSet и Collections.unmodifiableSet для потоко-безопасного только для чтения вида:

Set<String> base = new HashSet<>();
Set<String> sync = Collections.synchronizedSet(base);
Set<String> readOnly = Collections.unmodifiableSet(sync);

// Модифицировать можно через sync/base, а readOnly гарантирует отсутствие вызовов модификации через этот вид
System.out.println(readOnly.contains("x"));

false

2. Использование synchronizedSet с потоками и внешней блокировкой при итерации (демонстрация отсутствия ConcurrentModificationException):

import java.util.*;

Set<Integer> s = Collections.synchronizedSet(new HashSet<>());
for (int i = 0; i < 1000; i++) s.add(i);

Thread modifier = new Thread(() -> {
    for (int i = 1000; i < 2000; i++) s.add(i);
});
modifier.start();

// Без внешней синхронизации возможны ошибки. Здесь обеспечивается консистентность вида при итерации:
synchronized (s) {
    for (Integer v : s) {
        // безопасно, т.к. modifier не может одновременно изменить структуру
    }
}
modifier.join();
System.out.println("size=" + s.size());

size=2000

3. Использование synchronizedSet как адаптера для стороннего множественного интерфейса (например, для совместимости кода):

// Существующий код ожидает Set и многопоточный доступ
Set<String> legacy = getLegacySet();
Set<String> safeView = Collections.synchronizedSet(legacy);
someLibraryMethod(safeView);

(поведение зависит от someLibraryMethod; safeView предоставляет синхронизацию методов)

4. Взаимодействие со Stream API: стримы не синхронизируются автоматически. Для безопасной работы можно либо сперва получить копию под синхронизацией, либо выполнять операции в synchronized-блоке:

Set<String> s = Collections.synchronizedSet(new HashSet<>());
s.add("a"); s.add("b");

List<String> snapshot;
 synchronized (s) {
    snapshot = new ArrayList<>(s);
}
// Работать со snapshot через stream без синхронизации
snapshot.stream().forEach(System.out::println);

a
b

5. Замена synchronizedSet на ConcurrentHashMap.newKeySet для повышения производительности при высокой конкуренции:

Set<String> concurrent = ConcurrentHashMap.newKeySet();
concurrent.add("x");
System.out.println(concurrent.contains("x"));

true

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