Ich habe ein Projekt, das die Zustandsinformationen in über 500.000 Objekten verfolgt, das Programm empfängt 10.000 Aktualisierungen / Sekunde über diese Objekte, die Aktualisierungen bestehen aus neuen, Aktualisierungs- oder Löschoperationen.
Im Rahmen des Programms müssen etwa alle fünf Minuten Hausaufgaben an diesen Objekten durchgeführt werden. Zu diesem Zweck habe ich sie in DelayQueue eingefügt, um die Delayed -Schnittstelle zu implementieren, was die Sperrfunktion von DelayQueue ermöglicht. um das Haushalten dieser Objekte zu kontrollieren.
-
Neu wird ein Objekt auf dem DelayQueue platziert.
-
Beim Aktualisieren wird das Objekt remove() 'd von DelayQueue aktualisiert und dann an der neuen Position, die von den aktualisierten Informationen bestimmt wird, erneut eingefügt.
-
Nach dem Löschen ist das Objekt remove() 'd von DelayQueue .
Das Problem, mit dem ich konfrontiert bin, ist, dass die remove() -Methode zu einer prohibitiv langen Operation wird, sobald die Warteschlange etwa 450.000 Objekte passiert.
Das Programm ist Multithread, ein Thread kümmert sich um Updates und ein anderer um die Hausverwaltung. Aufgrund der Verzögerung remove() erhalten wir fiese Probleme mit der Sperrleistung, und schließlich verbraucht der Update-Thread-Puffer den gesamten Heap-Speicher.
Ich habe es geschafft, dies zu umgehen, indem ich eine DelayedWeakReference (extends WeakReference implements Delayed) erstelle, die es mir erlaubt, "Schatten" -Objekte in der Warteschlange zu lassen, bis sie normal ablaufen.
Dadurch wird das Leistungsproblem beseitigt, die Speicheranforderungen werden jedoch erheblich erhöht. Dies ergibt ca. 5 DelayedWeakReference für jedes Objekt, das sich tatsächlich in der Warteschlange befinden muss.
Kennt jemand eine DelayQueue mit zusätzlicher Verfolgung, die schnelle remove() -Operationen zulässt? Oder gibt es irgendwelche Vorschläge für bessere Möglichkeiten, dies zu bewältigen, ohne wesentlich mehr Speicher zu verbrauchen?