Współbieżność Java w praktyce - próbka 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>

Mam pytanie dotyczące próbki powyżej, z której pochodziWspółbieżność Java w praktyce Listing 14.12 Semafor zliczający zaimplementowany przy użyciu blokady.

Zastanawiam się, dlaczego musimy uzyskać blokadę w konstruktorze (jak pokazano lock.lock () jest wywoływany). O ile wiem, konstruktor jestatomowy (z wyjątkiem ucieczki referencji), ponieważ żaden inny wątek nie może uzyskać referencji, a zatem pół skonstruowany obiekt nie jest widoczny dla innych wątków. Dlatego nie potrzebujemy zsynchronizowanego modyfikatora dla konstruktorów. Poza tym nie musimy się martwić owidoczność pamięci tak samo, jak długo obiekt jest bezpiecznie publikowany.

Dlaczego więc musimy uzyskać obiekt ReentrantLock wewnątrz konstruktora?

questionAnswers(3)

yourAnswerToTheQuestion