Warum ist CountDownLatch so kompliziert?

Question

Ich möchte wissen, warum utils.concurrent solch komplizierten Quellcode haben. Dies ist ein Code, den ich für die CountDownLatch kam und nach dem Testen erwartete ich etwas ähnliches im Quellcode zu finden, aber nein, es ist super komplex.

Ist die Implementierung falsch?

public class CountDown { 

    private int count; 
    private Object lock; 

    public CountDown(int count) 
    { 
     lock = new Object(); 
     this.count = count; 
    } 
    //Just waits until it is notified by CountDown. Keeps waiting if not 0. 
    public void await() throws InterruptedException 
    { 
     synchronized (lock) { 
      while(count != 0) 
      { 
       lock.wait(); 
      } 
     } 
    } 
    //Decreases the count and notifies for await's lock. 
    public void countDown() 
    { 
     synchronized (lock) { 
      this.count--; 
      lock.notify();   
     } 
    } 
} 

Und hier ist der Quellcode: Source Code CountDownLatch

Answer 1

CountDownLatch scheint AbstractQueuedSynchronizer nur ein Wrapper zu sein. Ich denke, es könnte der Fall sein, dass Doug das bemerkt hat und beschlossen hat, nur mit diesem Ansatz zu gehen, der zu seinem aktuellen Design führt.

Eine wichtige Funktion, die ich in CountDownLatch über die private Synch-Klasse sehe, ist, dass es Überprüfungen für das Interrupt-Flag gibt. Dies ist im allgemeinen Bibliothekscode, der millionenfach verwendet wird, sehr wichtig. Das bedeutet, dass, wenn das Interrupt-Flag irgendwo vorher gesetzt wird, CountDownLatch es respektieren wird und keine Wartezeiten eingehen wird. Dadurch können Threads nicht angehalten werden, wenn die Anwendung beendet wird und alle ihre Threads unterbrochen sein sollten. Ich sehe dieses Problem sehr oft, wenn ich eine Anwendung herunterfahre und gezwungen bin, die PID mit -9-Signal zu beenden. Der übliche Schuldige ist schlechter Multithreaded-Code, der den Interrupt nicht richtig verarbeitet oder nach ihm sucht.