<code>// Not really how java.util.concurrent.Semaphore is implemented
@ThreadSafe
public class SemaphoreOnLock {
    private final Lock lock = new ReentrantLock();
    // CONDITION PREDICATE: permitsAvailable (permits > 0)
    private final Condition permitsAvailable = lock.newCondition();
    @GuardedBy("lock") private int permits;

    SemaphoreOnLock(int initialPermits) {
        lock.lock();
        try {
            permits = initialPermits;
        } finally {
            lock.unlock();
        }
    }

/* other code omitted.... */
</code>

У меня есть вопрос о примере выше, который извлечен изJava Concurrency in Practice Листинг 14.12. Подсчет семафоров, реализованных с использованием Lock.

Мне интересно, почему мы должны получить блокировку в конструкторе (как показано, вызывается lock.lock ()). Насколько я знаю, конструкторatomic (кроме ссылки, которой удалось избежать), поскольку никакой другой поток не может получить ссылку, следовательно, полу-построенный объект не виден другим потокам. Поэтому нам не нужен синхронизированный модификатор для конструкторов. Кроме того, нам не нужно беспокоиться оmemory visibility а также, пока объект благополучно опубликован.

So, why do we need to get the ReentrantLock object inside the constructor?