ArrayBlockingQueue und fügen Sie vs-stellen, vs-Kapazität

Aus der Javadoc von ArrayBlockingQueue ArrayBlockingQueue:

hinzufügen

public boolean add(E e)

Inserts the specified element at the tail of this queue if it is possible 
to do so immediately without exceeding the queue's capacity, returning true 
upon success and throwing an IllegalStateException if this queue is full.

Ich immer interpretted diese Aussage (der Teil if it is possible to do so immediattely) wie folgt:

Wenn die Warteschlange hat freie Kapazität, dann wird das insert erfolgreich sein wird. Wenn es keinen leeren Raum gibt, dann wird es nicht gelingen.

Aber mein Verständnis war hier falsch.

In einem einfachen Fall, dass ich mich entschieden habe, ein ArrayBlockingQueue für z.B. 20 Elemente (kleine Schlange) und mit einem thread zu tun:

queue.take()

den anderen thread nicht fügen Sie ein element in der queue über die add Methode trotz der Warteschlange war fast leer.

Ich überprüft, dass es auch über debugging.

Einmal ersetzte ich den Anruf von queue.add(element) zu queue.put(element) element wurde in der Tat der Warteschlange Hinzugefügt.

Also, was ist so anders in diesen Methoden?

Für welchen anderen Grund (außer der Kapazität), könnte der Zusatz nicht passieren?

UPDATE:

public class ConnectionListener implements Observer {

  public static BlockingQueue<ConnectionObject> queueConnections = new   ArrayBlockingQueue<ConnectionObject>(10);

  @Override
  public void update(Observable arg0, Object arg1) {
      ConnectionObject con = ((ConnectionObject)arg1);
      queueConnections.add(con);
  }

}

ConnectionObject ist nur ein Platzhalter für String-Werte.

public class ConnectionObject {
  private String user;  
  private String ip;
   //etc  
}

Und die Verbraucher:

public class ConnectionTreeUpdater extends Thread {  
  @Override
  public void run() {
    while(true){  
    try {  
    final ConnectionObject con = ConnectionListener.queueConnections.take();

Wenn ich add es wird keine exception geworfen, sondern element nicht der Warteschlange Hinzugefügt.

Nur so ein Gedanke: vielleicht da der Verbraucher ist "warten" in der Warteschlange, wenn für einige interne housekeeping-das element kann nicht Hinzugefügt werden, es wird nicht Hinzugefügt und es wird keine exception geworfen.Könnte das der Fall sein.

Ansonsten kann ich nicht verstehen, warum es ist keine Ausnahme, und mit put code funktioniert.

Sind put und add soll anders genutzt werden?

Ich vermute, Sie waren zu fangen und ignorieren dabei, dass die Ausnahme ausgelöst wird, durch add() aber ohne zu sehen, Ihren code, ist nur eine Vermutung. Sie müssen die post ein kleines code-Beispiel zeigt das problem, das Sie haben.
Eigentlich gab es keine Ausnahme hinzufügen. Ich habe gerade queue.add und den code zurückgegeben immediatelly ohne das hinzufügen das element und keine Ausnahme
Bitte können wir sehen, eine vollständige und reproduzierbare test-Fall, der zeigt dieses Verhalten (add() nicht eine Ausnahme zu werfen, aber auch nicht hinzufügen, das element der Warteschlange).
Nein, das ist es nicht. Es wird entweder Hinzugefügt, um die Warteschlange, oder es hat eine Ausnahme ausgelöst. Das sind die nur zwei mögliche Ergebnisse.
post mit dem code
Hinzugefügt der wichtigste Teil des Codes.Wird versuchen einen vollständigen Testfall in eine kleine Weile

InformationsquelleAutor Cratylus | 2011-10-09

15

Es ist eigentlich ganz einfach:
- wenn die Warteschlange nicht voll ist, sind beide Methoden erfolgreich zu sein;
- wenn die Warteschlange voll ist, add() schlägt mit einer Ausnahme fehl in der Erwägung, dass put() Blöcke.
Ich denke die Dokumentation ist ziemlich klar, auf der oben. Wenn Sie damit nicht einverstanden, und möchte eine zweite Meinung, man könnte untersuchen Sie die Quelle code für ArrayBlockingQueue:
```
public boolean add(E e) {
    if (offer(e))
        return true;
    else
        throw new IllegalStateException("Queue full");
}

public boolean offer(E e) {
    if (e == null) throw new NullPointerException();
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        if (count == items.length)
            return false;
        else {
            insert(e);
            return true;
        }
    } finally {
        lock.unlock();
    }
}

public void put(E e) throws InterruptedException {
    if (e == null) throw new NullPointerException();
    final E[] items = this.items;
    final ReentrantLock lock = this.lock;
    lock.lockInterruptibly();
    try {
        try {
            while (count == items.length)
                notFull.await();
        } catch (InterruptedException ie) {
            notFull.signal(); //propagate to non-interrupted thread
            throw ie;
        }
        insert(e);
    } finally {
        lock.unlock();
    }
}
```
- If you find the documentation ambiguous, you can verify this by looking at the source code - Nun, es gibt einen Unterschied zwischen einem detail und Dokumentation, so bin ich nicht wirklich glücklich mit, dass die Beratung im Allgemeinen. Wenn die Dokumentation nicht klar ist (obwohl ich denke, es ist ziemlich klar, in diesem Fall), das ein bug ist eher sinnvoll denke ich (noch nicht gemacht, dass für Java, aber mehr als einmal für msdn [sowie die win32-api-doc ist ein Chaos, obwohl ;-)])
- Ich sehe Ihren Punkt. Aber für einen sinnvollen bug-report gibt es einen Fehler (oder einen vernünftigen überzeugung, dass es ein bug ist). In diesem Fall, der Dokumentation und der code sehr deutlich die gleiche Sache (in meinen Augen sowieso).
- Ich bin damit einverstanden, dass in diesem Fall die Dokumentation ist klar genug (naja, und der code offensichtlich nicht den richtigen thingTM). Nur wenn die Dokumentation war wirklich unklar, nur einen Blick auf die Umsetzung und die Annahme, es könnte sich nie ändern, wäre eine schlechte Idee. Erstellen Sie einen Fehler bei der Dokumentation zu sehen, ob das war nur ein ehrliches versehen oder undefiniert aus gutem Grund ist imo die bessere Vorgehensweise (zuerst googlen um offensichtlich 😉 )
- Während ich Stimme mit Ihnen auf einer bestimmten Ebene, wenn Sie vermuten, dass es ein bug schreiben Sie einen wiederholbaren Testfall zu demonstrieren und dann die Datei des Berichts. Die OP scheint nicht in der Lage dies zu leisten, nachdem er gefragt worden, so dass an dieser Stelle Ihnen zu sagen, Blick auf die Quelle, nicht ein schrecklicher Vorschlag. Verdacht ist ein Fehler im stabilen, alten code, der verwendet wird, die durch Millionen von Entwicklern, die jeden Tag ist einfach nur arm-Logik und die Kennzeichen einer schlechten Ingenieur. Jeff (co-Gründer SO) beschreibt dazu in: codinghorror.com/blog/2008/03/...
- Ich bin nicht sagen, dass es einen Fehler gibt, nur, dass es keine gute Idee, sich an der Umsetzung, wenn die Dokumentation nicht angeben oder etwas unklar ist. Also die Beantwortung einer Frage über das Verhalten einer Funktion mit "Blick auf die src-code geschieht Folgendes" führen kann, um interessante Probleme die Straße hinunter. Beispiel? Der C# - string-hash-Funktion ist nirgendwo dokumentiert, und tatsächlich ändern Sie durch Versionen, die dazu führen, dass interessante Probleme die Straße hinunter. Edit: Die OP veränderte sein Beitrag ganz etwas ein, da dies hier geschrieben wurde, so dass der Zusammenhang ein wenig verändert.
- In diesem Fall, es gibt einfach keine Unklarheiten und ich denke, wir sind auf einem nicht verwandten Tangente ein bisschen. Die OP beginnt seine Frage mit "ich lese die Dokumentation, und Sie sagen, dieses" und das ist genau der Fall als erwiesen, wenn Sie schreiben einen test-Fall (das der OP nicht getan hat) oder einen Blick auf die Quelle. Ich denke, das ist mehr das, was ich versuche zu betonen. Wie wäre es, wenn aix änderte seine Antwort auf die Frage "Wenn Sie einen Blick auf die Quelle, die es bestätigt, was die docs sagen"? 🙂
- Es war mehr eine Allgemeine meckern (müssen fix einige bugs eingeführt, die von undefiniertem Verhalten in ein c-Projekt, hatte vielleicht etwas damit zu tun ;)), da die Antwort könnte so interpretiert werden, "Wenn Sie nicht verstehen, die docs, Lesen Sie einfach die Umsetzung" (ich bin mir ziemlich sicher, dass aix nicht beabsichtigen, es zu Lesen, als solche aber). Ich wollte nur betonen den Unterschied zwischen der Umsetzung Verhalten und dem, was die Dokumentation beschreibt. Über die OPs problem, das ich damit einverstanden - debugging und erstellen von guten Testfällen ist eine wichtige Kunst zu lernen hat 😉
InformationsquelleAutor NPE

Einer der wichtigsten Teile der debugging-problem ist schreiben einen test-Fall, um sicherzustellen, was Sie denken, ist passiert, ist tatsächlich passiert. Entweder beweist oder widerlegt Ihre Theorie.

Den Testfall zeigt, dass die Methoden, die Sie verwenden, Verhalten sich genau wie in der Dokumentation (die Sie zitieren) Staaten:

public static void main(String[] args) {

    final ArrayBlockingQueue<Integer> myQueue =
            new ArrayBlockingQueue<Integer>(10);


    Thread t1 = new Thread(new Runnable() {

        public void run()
        {
            int i = 0;
            while (true)
            {
               try
                {
                    myQueue.add(i);
                    System.out.println("Added to queue! value: " + 
                                        i + 
                                        " size: " + myQueue.size());
                    i++;
                }
                catch (Exception e)
                {
                    System.out.println("add() threw exception, size: " +
                                        myQueue.size());
                    try
                    {
                        Thread.sleep(1000);
                    }
                    catch (InterruptedException ex)
                    {
                        Logger.getLogger(Main.class.getName()).log(Level.SEVERE, 
                                                                   null, ex);
                    }
                }
            }
        }

    });

    Thread t2 = new Thread(new Runnable() {

        public void run()
        {
            while (true)
            {
                try
                {
                    Integer i = myQueue.take();
                    System.out.println("Took a off the queue! value: " + 
                                        i + 
                                       " size: " + myQueue.size());
                    Thread.sleep(100);
                }
                catch (InterruptedException ex)
                {
                    Logger.getLogger(Main.class.getName()).log(Level.SEVERE, 
                                                               null, ex);
                }
            }
        }
    });

    t1.start();
    t2.start();

}

InformationsquelleAutor Brian Roach

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.