Краткий ответ

Он обязан видеть записи, выполненные другим потоком до вызова release(), если его acquire() успешно получил разрешение, связанное с этой синхронизацией. Для этого поля не требуется объявлять его volatile.

Гарантия касается видимости предшествующих действий, но не превращает последующие операции над полем в атомарные и не защищает их от конкурентных изменений.

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

Semaphore предназначен для координации доступа к ограниченному числу ресурсов: разрешениям соответствуют доступные места, соединения или задачи. В отличие от обычного сигнала, семафор сохраняет количество разрешений, поэтому сигнал, отправленный до ожидания, не теряется.

В Java семафор также является средством синхронизации в смысле Java Memory Model. Это позволяет использовать его не только для ограничения количества участников, но и для публикации результатов работы между потоками.

Постановка проблемы

Пусть производитель изменяет обычные поля объекта, а затем сообщает потребителю о готовности через release(). Потребитель после успешного acquire() читает эти поля.

Без отношения happens-before поток-потребитель не обязан наблюдать актуальные значения обычных полей: компилятор, процессор и кэширование могут привести к наблюдению устаревшего состояния. При этом сам факт успешного получения разрешения ещё не означает, что любые произвольные записи в программе стали видимыми.

Подробное решение

В документации Semaphore указано отношение памяти: действия потока до вызова release() происходят раньше действий другого потока после успешного acquire(). Поэтому записи обычных полей, выполненные перед освобождением разрешения, становятся видимыми читателю после получения разрешения.

Минимальный пример публикации данных:

import java.util.concurrent.Semaphore;

class Demo {
    static int value;
    static final Semaphore ready = new Semaphore(0);

    public static void main(String[] args) throws Exception {
        Thread writer = new Thread(() -> {
            value = 42;
            ready.release();
        });
        Thread reader = new Thread(() -> {
            try {
                ready.acquire();
                System.out.println(value);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });
        reader.start();
        writer.start();
        writer.join();
        reader.join();
    }
}

Ключевая цепочка здесь такова: запись value = 42 выполняется до release(), а чтение value — после успешного acquire(). Поэтому читатель должен получить значение 42.

Гарантия не распространяется на чтение, выполненное до acquire(), и не возникает просто из-за наличия объекта Semaphore. Если потребитель получил заранее существовавшее разрешение, которое не было опубликовано производителем после нужных записей, нельзя автоматически считать эти записи опубликованными через данный семафор.

Семафор не заменяет защиту составных операций. Например, видимость значения после acquire() не делает выражение «прочитать, увеличить, записать» атомарным. Для взаимного исключения нужен подходящий lock, монитор или атомарная операция; семафор с одним разрешением может использоваться как бинарная блокировка, но обладает другой семантикой и не является повторно входящим.

Ситуация из практики

Сервис подготавливает пакет данных в одном потоке и передаёт его рабочему потоку. Рассматривались три варианта: volatile-флаг, CountDownLatch и Semaphore.

volatile-флаг обеспечивает видимость записи, но не хранит количество сигналов и требует корректного протокола проверки состояния. CountDownLatch хорошо подходит для одноразового события, однако после отсчёта до нуля его нельзя повторно использовать. Semaphore позволяет накапливать несколько разрешений и ограничивать число одновременно обрабатываемых пакетов.

Для повторяющейся схемы «готов один пакет — разрешить одну обработку» выбран Semaphore с нулевым начальным числом разрешений. Производитель записывает данные перед release(), потребитель сначала успешно вызывает acquire(), а затем читает данные. Это одновременно обеспечивает сигнализацию, сохранение лишних разрешений и требуемую публикацию данных; для одноразового запуска более простым выбором был бы CountDownLatch.

Что кандидаты часто упускают

1. Эквивалентен ли Semaphore объявлению общего поля volatile?

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

Например, volatile-счётчик всё ещё может терять обновления при конкурентном увеличении. Семафор с одним разрешением может обеспечить взаимное исключение, но только если каждый участник строго соблюдает протокол захвата и освобождения.

2. Достаточно ли вызвать acquire() после release(), чтобы увидеть все изменения программы?

Нет, важна конкретная причинная цепочка. Изменения должны быть выполнены до release(), а чтение — после успешного acquire(), получившего разрешение в рамках соответствующего протокола. Вызов acquire(), который использует ранее доступное разрешение, не доказывает публикацию данных, записанных другим потоком позднее.

Кроме того, если данные после release() продолжают изменяться, семафор не защищает читателя от гонки. Для стабильного снимка нужно завершить подготовку до сигнала либо дополнительно защищать последующие изменения.

3. Можно ли использовать Semaphore как очередь сообщений без дополнительных гарантий?

Нет. Семафор хранит только число разрешений, но не сами данные и не соответствие конкретного разрешения конкретному сообщению. Если несколько сообщений записываются в общий слот, требуется отдельная безопасная структура данных или строгий протокол владения слотами.

Для передачи элементов обычно подходит BlockingQueue, поскольку она связывает данные с операциями добавления и извлечения. Semaphore лучше выбирать, когда нужно считать доступные ресурсы, ограничивать параллелизм или сигнализировать о наличии работы, а хранение и согласованность самих данных обеспечиваются другим механизмом.