Synchronisation + Vector/ArrayList/LinkedList

[-frank]

ich habe ein programm mit mehreren threads, die auf diverse Listen zugreifen müssen. Mir geht es nun um die Wahl der Synchronisationsmöglichkeit und der das List-Interface implementierenden Klasse.

Synchronisation mittels...
1. Vector (ist bereits synchronisiert (allerdings nicht der Iterator))
2. java.util.Collections.synchronizedList(List...)
3. synchronisations-objekt

Listen:
1. Vector
2. ArrayList
3. LinkedList

ich bin mir nun nicht sicher, welche Kombination ich wählen soll. Google liefert dazu einige Diskussionen, zb diese hier: http://www.velocityreviews.com/forums/t132806-arraylist-vs-vector.html
Bei Vector sagen zb viele, dass die Klasse veraltet ist bzw. im Nachhinein ans Collection-Framework angepasst wurde und von daher nur verwendet werden sollte, wenn das Program auf alten JVMs laufen soll (das ist mir egal, java1.5 brauche ich sowieso). andere wiederum meinen, dass die automatische Synchronisation von Vector ein großer Vorteil ist und weniger Overhead hat als java.util.syncronizedList(List..). anderswo hab ich wieder gelesen, dass man die synchronisation sowieso immer über ein synch-objekt machen sollte. auch weil man dann für den synchronisierten zugriff auf mehrere objekte nur ein synchronisationsobjekt benötigt (--> weniger synchronisationsarbeit).
zum synchronisierten zugriff habe ich auch in diesem post: http://www.java-forum.org/de/viewtopic.php?t=44279&highlight= schon mal was geschrieben (allerdings keine antwort bekommen).

bezüglich linkedlist versus arraylist sehe ich in erster line mal den vorteil, dass linkedlist einfach einige praktische methoden anbietet wie getLast() und sowas. da meine Referenzen (bis jetzt) aber sowieso nur auf das List-Interface referenzieren, würde dieser Vorteil für mich wegfallen. Hat damit LinkedList keinen Vorteil mehr?
ArrayList soll ja schneller sein. Von dem, was ich über Arrays weiß, leuchtet mir auch ein, dass der Zugriff auf Elemente viel schneller sein muss (O(1) statt O(n)). Greift man aber seltener zu und verändert dafür relativ oft die Liste, sprich viele add/remove. sollte dann nicht linkedlist besser sein? (ich frage, weil bei meiner googlesuche in diversen foren fast immer zu arraylist geraten wurde (statt vector) und nie zu linkedlist).

 

[Wildcard]

Wenn du wahlfreien Zugriff brauchst ist eine LinkedList nicht zu gebrauchen.
Für häufige add/remove Operationen scheidet die ArrayList aus.
Vector würde ich nicht nehmen.

 

[-frank]

Wenn du wahlfreien Zugriff brauchst ist eine LinkedList nicht zu gebrauchen.
Für häufige add/remove Operationen scheidet die ArrayList aus.

okay, das hilft mir schon mal insofern weiter als es eben doch gründe gibt, sich das zu überlegen (wie gesagt heißt es im netz meist einfach "nimm statt vector arraylist". linkedlist hab ich selten gelesen). bei mir ist es so, dass ich viele add/removes haben werde aber auch viele zugriffe. sehr viele zugriffe sind aber iterationen über alle elemente. allerdings habe ich auch etliche indexOf(Element) aufrufe. da ich die equals-Methode des objekts überscheibe und somit das "echte" objekte noch garnicht habe (also das entsprechende element in der liste), muss ich mir danach auch mit get(index) das element holen.

also ich habe alles drin. kommts einen dann wirklich auf die performance an, müsste man das problem wohl analysieren und testen, was in diesem fall schneller ist oder?

 

[Wildcard]

Wenn du wahlfreien Zugriff brauchst ist eine LinkedList nicht zu gebrauchen.
Für häufige add/remove Operationen scheidet die ArrayList aus.

okay, das hilft mir schon mal insofern weiter als es eben doch gründe gibt, sich das zu überlegen (wie gesagt heißt es im netz meist einfach "nimm statt vector arraylist". linkedlist hab ich selten gelesen).

Der Grund ist einfach das Vector genauso wie ArrayList funktioniert, hier ist die Wahl der Implementierung also schon getroffen, daher braucht man keine LinkedList zu empfehlen.
Im EInzelfall muss man tatsächlich testen.
Iterationen über LinkedList und ArrayList sind vergleichbar schnell.
ArrayList bekommt Probleme wenn das interne Array umkopiert werden muss und LinkedList bekommt bei get(index) Probleme (da sie intern eine Iteration vom ersten Element ab starten muss).

 

[-frank]

achso... auf diese idee bin ich nicht gekommen. arraylist ist vector natürlich ähnlicher, deswegen...

okay, also so wies aussieht ist mein erstes problem gelöst, denn ich werde wie gesagt alle möglichen zugriffe und list-modifikationen haben. wenns da nicht eindeutig ist, was ich nehmen solle, dann teste ich das eben in zukunft in fällen, wo performance wichtig ist.

bleibt noch die frage der synchronisationsmethode. kann ich davon ausgehen, dass ein zusätzliches synchronisationsobjekt dann sinn macht, wenn man sich dadurch mehrere andere synchronisationen erspart, es aber egal ist, wenn man sowieso nur synchronisiert auf die Liste zugreifen will?

 

[Wildcard]

bleibt noch die frage der synchronisationsmethode. kann ich davon ausgehen, dass ein zusätzliches synchronisationsobjekt dann sinn macht, wenn man sich dadurch mehrere andere synchronisationen erspart, es aber egal ist, wenn man sowieso nur synchronisiert auf die Liste zugreifen will?

synchronisiert wird immer mit einem 'synchronisationsobjekt'. Etwas anderes gibt es nicht.

 

[-frank]

synchronisiert wird immer mit einem 'synchronisationsobjekt'. Etwas anderes gibt es nicht.

was ich meinte, ist, dass ich entweder mit Collections.synchronizedList(..) eine synchronisierte Liste erzeugen kann, wo ich dann eben, wenn ich drüber iteriere, synchronized(list) {...} schreibe oder aber dass ich bei einer unsynchronisierten liste bleibe und bei jedem zugriff dafür ein synchronized(synchronizeListAccess) {..} schreiben kann.

 

[Wildcard]

Ist doch Jacke wie Hose. Was eben besser ins Konzept passt.