Что хотят услышать интервьюеры:

Оптимистичная блокировка предполагает, что конфликты между потоками или транзакциями случаются редко, поэтому ресурс не блокируется заранее. При сохранении изменений выполняется проверка, что данные не были изменены кем-то ещё. Если изменение было, операция откатывается или повторяется.

Определение:

Оптимистичная блокировка — это подход к управлению конкурентным доступом, при котором чтение данных происходит без удержания блокировки, а при записи система проверяет, что с момента чтения запись никто не менял. Обычно для этого используют поле версии, метку времени или сравнение состояния объекта. Если проверка не проходит, возникает конфликт обновления.

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

Типичный пример — редактирование карточки товара в админке. Два пользователя открыли одну и ту же карточку, оба внесли изменения. Первый сохранился успешно, второй при сохранении получает ошибку, потому что версия записи уже изменилась.

public class Product {
    private Long id;
    private String name;
    private int quantity;
    private long version;

    // getters/setters
}

public boolean updateProduct(Product currentFromDb, Product edited) {
    if (edited.getVersion() != currentFromDb.getVersion()) {
        return false; // конфликт: данные устарели
    }

    edited.setVersion(edited.getVersion() + 1);
    // save edited to DB
    return true;
}

Пояснение кода:

В примере у сущности есть поле version, которое меняется при каждом успешном обновлении. Сначала из базы читается текущая версия записи. Перед сохранением сравнивается версия, которую видел пользователь, с актуальной версией в базе. Если версии не совпадают, значит кто-то уже обновил данные, и сохранение нельзя делать без дополнительной обработки.

Если версия совпала, запись обновляется, а version увеличивается. В реальных системах эта логика обычно реализуется на уровне ORM или SQL-запроса вида «обновить, если версия не изменилась».

Ключевые моменты:

Не блокирует ресурс на время чтения, поэтому хорошо подходит для сценариев с редкими конфликтами.
Конфликт обнаруживается только в момент записи, а не заранее.
Чаще всего реализуется через поле version или timestamp.
При конфликте нужно либо повторить операцию, либо показать пользователю ошибку и предложить обновить данные.
Лучше работает, когда чтений много, а одновременных изменений мало.
Если конфликтов много, оптимистичный подход может быть неэффективен из-за частых повторных попыток.

Объясните принцип работы оптимистичной блокировки в управлении конкурентностью и ее особенности.