Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
ich brauche ein passende Collection, die mir bei folgendem Szenario helfen kann:
Zur Laufzeit in einem eigenen Thread werden ständig neue Objekte des gleichen Typs hinzugefügt. Zur gleichen Zeit in einem anderen Thread sollen die Objekte nacheinander (in der Reihenfolge des Hinzufügens) wieder ausgelesen werden. Nach dem letzten Element in der Liste soll mit dem ersten wieder begonnen werden.
Nach den Prinzipien der Informatik hätte ich mich direkt für eine zirkuläre einfach verkettete Liste entschieden: über next() würde ich mit dem Pointer die Elemente laufen, zum Speichern wird einfach das nächste Element drangehangen...
Doch die Implementation der LinkedList von Java hilft mir nicht weiter. Lediglich über den Iterator kann ich die Elemente schrittweise durchlaufen, der mir aber eine Exception schmeißt, wenn der Inhalt der Liste geändert wurde. Warum gibt es in der LinkedList nicht einfach eine next()-Methode?
Muss ich mir nun selber was zusammenbasteln oder gibt es eine andere Alternative?
Mh, auch wenn ArrayDeque abgeblich schneller als die LinkedList ist, bringt mich das auch nicht weiter. Auch hier muss die Abfrage über einen Iterator laufen, der es gar nicht gut findet, wenn neue Objekte hinzugefügt werden.
Ja, mit pop() würde mir ein einmaliger Durchlauf gelingen, aber dann geht es nicht mehr weiter. Man könnte zwar die ge-pop()-ten Elemente in einer andere Collection sichern, aber das ist doch auch wieder nur ein Workaround.
naja fassen wir mal zusammen: for-each und iterator kannst du nicht nehmen, weil du wo anders die collection noch veränderst. stacks/queues auch nicht, weil du mehrmals durchlaufen willst. dann nehm doch einfach eine sync. arraylist oder einen vector und greif über den Index zu bzw. schreib dir einen IndexIterator (glaube nicht, dass es sowas in der SE gibt, vllt aber als lib - wobei das eine Sache von 5 Min. ist). Mehr fällt mir jetzt auch nicht ein...
Ok, hätte nur gedacht, es gibt da schon was angepasstes. Mit Vektoren habe ich noch nicht gearbeitet, vielleicht bekomme ich damit ja was vernünftiges hin.
also Vektor nehm ich prinzipiell gar nicht. Habe auch irgendwo mal aufgeschnappt, dass sie inoffiziell Deprecated sein sollen (bzw. das man Sie halt einfach nicht unbedingt nehmen sollte). Wie gesagt, wirds eine synchronisierte ArrayList auch machen. Du kannst genauso auch bei deiner LinkedList bleiben.
also Vektor nehm ich prinzipiell gar nicht. Habe auch irgendwo mal aufgeschnappt, dass sie inoffiziell Deprecated sein sollen (bzw. das man Sie halt einfach nicht unbedingt nehmen sollte).
Es ist einfach die alte Version der ArrayList, und man sollte den Vector nur nehmen, wenn man Sachen Thread-save machen muss. Also warum eine syncronized ArrayList erstellen, wenn Vector es bereits ist?
Kleiner Tipp: In dem einen Thread, wo nur durchlaufen wird, muß ja eh immer wieder an den Anfang der Liste "gesprungen" werden. Ein guter Zeitpunkt die Original-Liste in eine neue Liste zu Klonen, die man anschliessend nicht mal mehr syncrhonisieren muß.
Java:
public void run()
{
List<?> threadCopy;
while(running) {
synchronized(originalList) {
threadCopy = originalList.clone();
}
for(Object element : threadCopy) {
//... do something on element
}
}
}
Es ist einfach die alte Version der ArrayList, und man sollte den Vector nur nehmen, wenn man Sachen Thread-save machen muss. Also warum eine syncronized ArrayList erstellen, wenn Vector es bereits ist?
@nrg: Warum kein synchronisierten Vector? Weil dann alle Threads synchronisiert darauf zugreifen müssen und alle irgendwann längere Zeit warten müssen. Wenn man einen synchonisierten Zugriff benötigt, kann man diesen wie oben ganz leicht selbst implementieren. das klappt nun nicht mehr blos bei ArrayList, sondern bei jeder Collection bzw. jeder Map und nicht nur bei Vector. Ich selbst hab auch mal gehört, dass es den Vector blos noch aus Kompatibilitätsgründen gibt. Für die Tatsache, dass er nicht als Deprecated markiert wurde, gab' es afaik auch einen Grund. War glaub' ich sowas banales, wie "Wenn es wirklich nötig ist, alle Zugriffe auf eine Liste zu synchronisieren, kann man schlicht den Vector nehmen."
