Java Concurrency in Practice - Amostra 14.12

<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>

Eu tenho uma pergunta sobre a amostra acima, que é extraídaConcorrência Java na prática Listagem 14.12 Contando o semáforo implementado usando o bloqueio.

Eu estou querendo saber por que precisamos adquirir o bloqueio no construtor (como mostrado lock.lock () é invocado). Tanto quanto eu sei, construtor éatômico (exceto a referência escapou) como nenhum outro segmento pode obter a referência, portanto, o objeto parcialmente construído não é visível para outros segmentos. Portanto, não precisamos do modificador sincronizado para construtores. Além disso, não precisamos nos preocupar comvisibilidade da memória também, desde que o objeto seja publicado com segurança.

Então, por que precisamos obter o objeto ReentrantLock dentro do construtor?

questionAnswers(3)

yourAnswerToTheQuestion