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

Tengo una pregunta sobre la muestra anterior que se extrae deJava concurrencia en la práctica Listado 14.12 Se cuenta el semáforo de conteo implementado usando Lock.

Me pregunto por qué necesitamos adquirir el bloqueo en el constructor (como se muestra, se invoca lock.lock ()). Por lo que yo sé, el constructor esatómico (excepto la referencia escapada) ya que ningún otro subproceso puede obtener la referencia, por lo tanto, el objeto semiconstruido no es visible para otros subprocesos. Por lo tanto, no necesitamos el modificador sincronizado para los constructores. Además, no tenemos que preocuparnos por lavisibilidad de la memoria también, siempre y cuando el objeto se publique de forma segura.

Entonces, ¿por qué necesitamos obtener el objeto ReentrantLock dentro del constructor?