Bezpieczny dla wątków, ale szybki dostęp do "ostatecznej" zmiennej?

Question

Mam serwer trochę tak:

class Server { 

    private WorkingThing worker; 

    public void init() { 
     runInNewThread({ 
      // this will take about a minute 
      worker = new WorkingThing(); 
     }); 
    } 

    public Response handleRequest(Request req) { 
     if (worker == null) throw new IllegalStateException("Not inited yet"); 
     return worker.work(req); 
    } 

} 

Jak widać, istnieją wątki obsługi żądań i gwint initing serwer. Żądania mogą nadejść przed zakończeniem wnioskowania, dlatego istnieje czek z IllegalStateException.

Teraz, aby uczynić ten wątek bezpiecznym (tak, aby wątki obsługi nie pojawiały się po przeterminowaniu, null, wersja worker, musiałbym uczynić pracownika zmiennym, zsynchronizować go lub taki.

Jednak po zakończeniu init, worker nigdy więcej się nie zmieni, więc jest skuteczny. Dlatego wydaje się, że każda kłótnia o zamek, która może wystąpić, byłaby marnotrawstwem. Więc, co jest najbardziej efektywnego, co mogę tutaj zrobić?

Teraz wiem, że to naprawdę nie ma znaczenia w sensie praktycznym (z całym ciężkim uniesieniem czytania żądania sieci, itp., Co ma wspólnego pojedynczy zamek?), Ale chciałbym wiedzieć z ciekawości .

Answer 1

Notatka na temat lotności: oznaczanie zmiennej zmienności jest tańsze niż używanie synchronizacji (nie wymaga blokad) i jest na ogół wystarczająco tanie, że nie zauważysz. W szczególności na architekturach x86 odczyt zmiennej lotnej nie kosztuje więcej niż odczyt zmiennej nielotnej. Jednak pisanie do zmiennej jest droższe, a fakt, że zmienna jest niestabilna, może zapobiec optymalizacji kompilatora.

Używanie volatile jest prawdopodobnie opcją zapewniającą najlepszy stosunek wydajności do złożoności w scenariuszu.

Nie masz zbyt wielu alternatyw. Ostatecznie sprowadza się to do zapewnienia bezpiecznej publikacji twojego pracownika. I bezpiecznych idiomy publikacji należą:

• inicjalizacji instancji ze statycznego initialiser
• znakowanie odwołanie do instancji jako ostatecznego
• oznakowanie odwołanie do instancji jako lotny
• synchronizacji wszystkich dostępów

W twoim przypadku dostępne są tylko dwie ostatnie opcje, a użycie metody lotnej jest bardziej efektywne.

Answer 2

Należy zadeklarować, że pracownik jest volatile.

powodu dwóch powodów

1. jeśli nie uznaniu jej jako lotny niż ze względu na zmianę kolejności i widoczności efektów Widać było niezerowe odniesienie do niekompletne zbudowane Pracownik obiektu. iw ten sposób można uzyskać niepożądane efekty. Nie stanie się tak, jeśli uczynisz swojego pracownika niezmiennym przy użyciu wszystkich zmiennych końcowych .

2. Teoretycznie może się zdarzyć, że główny wątek może przez dłuższy czas nie widzieć niezerowej referencji obiektu roboczego. Więc unikaj tego.

Podsumowując, jeśli pracownik jest niezmienny, również w przypadku punktu 2, należy go uaktywnić. Zawsze unikaj nieprzewidywalnych wyników. Zadeklarowanie tego, że jest niestabilna, zajmie się tymi kwestiami.

Answer 3

Użyłbym ava.util.concurrent.atomic.AtomicReference , jeśli ma wartość NULL, tzn. Rzuca lub czeka i spróbuj ponownie (jeśli init jest wystarczająco szybki).

Answer 4

Zastosowanie prosty zamek do pierwotnego wniosku:

public synchronized void init() { 
    if(worker!=null) return; 
    runInNewThread({ 
     synchronized(Server.this){ 
      worker = new WorkingThing(); 
      Server.this.notify(); 
     } 
    }); 
    this.wait(); 
} 

public Response handleRequest(Request req) { 
    if (worker == null) synchronized(this) { 
     this.wait(); 
    } 
    return worker.work(req); 
} 

To działa, ponieważ istnieją punkty synchronizacji między dostępów do pracownika.