Чем важна потокобезопасность?

Почему потокобезопасность критически важна

Проблема без потокобезопасности

В многопоточных приложениях (а все современные веб-приложения многопоточные) без потокобезопасности происходят data races — когда несколько потоков одновременно обращаются к общим данным.

Конкретный пример проблемы

public class BankAccount {
    private int balance = 1000;
    
    public void withdraw(int amount) {
        // Читаем текущий баланс
        int current = balance;  // Шаг 1
        
        // Проверяем, достаточно ли денег
        if (current >= amount) {
            // Имитируем длинную операцию (запрос на сервер, БД)
            Thread.sleep(100);
            
            // Пишем новый баланс
            balance = current - amount;  // Шаг 2
        }
    }
}

// Два потока одновременно снимают деньги
BankAccount account = new BankAccount();

Thread thread1 = new Thread(() -> account.withdraw(600));
Thread thread2 = new Thread(() -> account.withdraw(600));

thread1.start();
thread2.start();

thread1.join();
thread2.join();

System.out.println(account.getBalance());
// Ожидаемый результат: -200 (невозможно)
// Реальный результат: 400 или -200 (случайный!)

Что произошло:

Время  | Thread 1           | Thread 2           | balance
-------|--------------------|--------------------|--------
1      | current = 1000     |                    | 1000
2      |                    | current = 1000     | 1000
3      | sleep(100)         |                    | 1000
4      |                    | sleep(100)         | 1000
5      | balance = 400      |                    | 400
6      |                    | balance = 400      | 400

Оба потока прочитали одинаковый баланс и вычли свои суммы, что привело к потере данных!

Реальные последствия

В финтехе и платежах:

public class PaymentProcessor {
    private List<Transaction> transactions = new ArrayList<>();
    
    public void processPayment(Payment payment) {
        // БЕЗ синхронизации!
        Transaction txn = createTransaction(payment);
        transactions.add(txn);  // Race condition
        
        updateBalance(payment.account, -payment.amount);
        log(txn);
    }
}

Результат: потерянные платежи, двойные начисления, неконсистентные данные.

В e-commerce (инвентаризация):

public class Inventory {
    private Map<String, Integer> stock = new HashMap<>();
    
    public boolean canBuy(String productId, int quantity) {
        int available = stock.get(productId);  // 1 шт
        if (available >= quantity) {
            // Два клиента одновременно покупают последний товар
            Thread.sleep(100);  // сетевая задержка
            stock.put(productId, available - quantity);  // Race condition
            return true;
        }
        return false;
    }
}

Результат: переполнение заказов, конфликты с logistics, возвраты товаров.

Опасность Data Races

1. Непредсказуемость

Ошибка может не проявиться на разработке, но вспыхнуть в production под нагрузкой:

# На локальной машине: работает идеально
# На production с 1000 RPS: неожиданные ошибки

2. Невозможно воспроизвести

// Баг проявляется случайно раз в 100000 запросов
// Сложно отловить в логах
// Еще сложнее воспроизвести в отладчике

3. Скрытые ошибки

Проблема может скрываться месяцы, потом проявиться:

private int counter = 0;

public void increment() {
    counter++;  // Три операции: read, add, write
}

// 100 потоков вызывают increment() 1 млн раз
// Ожидаемый результат: 100 млн
// Реальный результат: 87 млн (потеряны 13 млн операций!)

Почему синхронизация сложна

1. Видимость (Visibility)

Один поток пишет данные, другой их не видит:

public class DataHolder {
    private boolean ready = false;
    private int value = 0;
    
    public void process() {
        value = 42;
        ready = true;  // Запись может быть переупорядочена!
    }
    
    public int getValue() {
        while (!ready) {
            Thread.sleep(1);  // Потенциально вечный цикл
        }
        return value;  // value может быть 0, не 42!
    }
}

Решение: использовать volatile или синхронизацию

private volatile boolean ready = false;
private int value = 0;

2. Atomicity (Атомарность)

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

public synchronized void transfer(Account from, Account to, int amount) {
    from.withdraw(amount);
    to.deposit(amount);
    // Оба должны выполниться вместе, иначе деньги пропадут
}

3. Ordering (Упорядочение)

Операции должны выполняться в правильном порядке:

public class Initialization {
    private Object[] cache;
    private volatile boolean ready = false;
    
    public void init() {
        cache = new Object[100];
        // ... инициализируем cache ...
        ready = true;  // volatile гарантирует, что cache инициализирован ДО ready=true
    }
}

Решения потокобезопасности

1. Synchronized (самый простой, но медленный)

public synchronized void withdraw(int amount) {
    // Только один поток одновременно
    if (balance >= amount) {
        balance -= amount;
    }
}

2. Atomic типы (для простых значений)

private AtomicInteger counter = new AtomicInteger(0);

public void increment() {
    counter.incrementAndGet();  // Атомарно!
}

3. Locks (больше контроля)

private final ReentrantLock lock = new ReentrantLock();

public void withdraw(int amount) {
    lock.lock();
    try {
        if (balance >= amount) {
            balance -= amount;
        }
    } finally {
        lock.unlock();
    }
}

4. Concurrent коллекции

// Thread-safe по умолчанию
Map<String, User> users = new ConcurrentHashMap<>();
Queue<Task> tasks = new ConcurrentLinkedQueue<>();
List<String> list = new CopyOnWriteArrayList<>();

5. Immutability (лучший подход)

public final class ImmutableAccount {
    private final int balance;
    
    public ImmutableAccount(int balance) {
        this.balance = balance;
    }
    
    public ImmutableAccount withdraw(int amount) {
        if (balance < amount) throw new InsufficientFundsException();
        return new ImmutableAccount(balance - amount);
    }
}

// Потокобезопасно всегда!

Реальные примеры проблем

1. ORM Query Race Condition

User user = userRepository.findById(id);  // SELECT * FROM users WHERE id = ?
if (user.getBalance() >= amount) {
    user.setBalance(user.getBalance() - amount);
    userRepository.save(user);  // UPDATE с потерей данных
}
// Два потока одновременно: потеря денег!

Решение: SELECT FOR UPDATE

SELECT * FROM users WHERE id = ? FOR UPDATE;

2. Cache Stampede

private Cache<String, Data> cache = new Cache<>();

public Data getData(String key) {
    if (!cache.contains(key)) {
        // 1000 потоков одновременно пересчитывают кэш!
        Data data = expensiveComputation();  // Race condition
        cache.put(key, data);
    }
    return cache.get(key);
}

Вывод

Потокобезопасность критична, потому что:

• Финансовые потери — в финтехе баги = реальные деньги
• Потеря данных — data races корректируют состояние
• Непредсказуемость — баг может появиться под нагрузкой
• Сложность отладки — race conditions почти невозможно воспроизвести
• Масштабируемость — проблемы усугубляются с числом потоков

Ведущий подход — использовать concurrent структуры данных вместо ручной синхронизации, и где возможно — immutable объекты.