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?