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

Ich habe eine Frage zu dem obigen Beispiel, aus dem extrahiert wurdeJava-Parallelität in der Praxis Listing 14.12: Mit Lock implementiertes Zählen von Semaphoren

Ich frage mich, warum wir die Sperre im Konstruktor erwerben müssen (wie gezeigt, wird lock.lock () aufgerufen). Soweit ich weiß, ist Konstruktoratomar Da kein anderer Thread die Referenz abrufen kann, ist das halbkonstruierte Objekt für andere Threads nicht sichtbar. Daher benötigen wir den synchronisierten Modifikator nicht für Konstruktoren. Außerdem brauchen wir uns keine Sorgen zu machenSpeicher Sichtbarkeit auch, solange das Objekt sicher veröffentlicht ist.

Also, warum müssen wir das ReentrantLock-Objekt in den Konstruktor bekommen?