2017-11-14 3 views
0

Wir haben eine Situation mit Spring-Cloud-Netflix-Core-Bibliothek, die here beschrieben wird. Ich denke, das Problem ist mit der Art und Weise CachingSpringLoadBalancerFactory ist ConcurrentReferenceHashMap, die here berichtet wird.
Und auch aus der Dokumentation von ConcurrentReferenceHashMap (die Soft-Referenzen verwendet):Wie funktioniert ConcurrentReferenceHashMap?

Die Verwendung von Referenzen bedeutet, dass es keine Garantie dafür gibt, die in die Karte abgestellte Gegenstände anschließend zur Verfügung stehen werden. Der Garbage Collector kann jederzeit Verweise verwerfen, sodass der Eindruck entsteht, dass ein unbekannter Thread unbemerkt Einträge löscht.

Nun meine Fragen sind:
1. mein Verständnis in der folgenden richtig?

// Original code is in CachingSpringLoadBalancerFactory in spring-cloud-netflix-core 
// cache is a field of type ConcurrentReferenceHashMap 
if (this.cache.containsKey(clientName)) { 
    return this.cache.get(clientName); // This can be null, right? 
} 

2. Gibt es trotzdem einen Testfall dafür zu schreiben. Wir haben es geschafft, es einmal in einer eigenständigen Anwendung mit begrenztem Speicher (-Xmx50m) zu reproduzieren. Aber wie können wir einen Komponententest schreiben, um ein solches Szenario abzudecken?

Antwort

0

Zu Ihrer Frage, ja, das ist richtig. Im Allgemeinen ist dies eine Variation von WeakHashMap, wie in den Dokumenten angegeben.

Die JavaDoc für WeakHashMap sagt:

„Das Verhalten der WeakHashMap Klasse teilweise von den Aktionen des Garbage Collector abhängt, so einige bekannte Map Invarianten (wenn auch nicht erforderlich) halten nicht für diese Klasse Weil. Der WeakHashMap kann sich so verhalten, als ob ein unbekannter Thread Einträge im Hintergrund löscht.Insbesondere wenn Sie eine WeakHashMap Instanz synchronisieren und keine Mutator-Methode aufrufen, ist die Methode size möglich um im Zeitverlauf kleinere Werte zurückzugeben, für die Methode isEmpty, false und dannzurückzugeben, für die containsKey Verfahren zurückzukehren true und später false für einen bestimmten Schlüssel, für die get Methode einen Wert für einen bestimmten Schlüssel zurückzukehren aber später null zurückkehren, das put Verfahren null und das remove Verfahren zurückzukehren false für eine Rückkehr Schlüssel, der zuvor in der Karte zu sein schien, und für sukzessive Untersuchungen der Schlüsselmenge, der Wertesammlung und der Eintragmenge, um sukzessive kleinere Zahlen von Elementen zu erhalten. "

Aufgrund dieses Verhaltens ist es ziemlich schwierig zu testen. Sie können die Methode getReference() der Karte und die Methode release() der entsprechenden Elemente verwenden, um die Bereinigungen zu simulieren, wenn Sie einige Invarianten testen möchten.