Thread-safe cache d'un objet en java

google collections effectivement fournitures juste la chose pour ce genre de chose: Fournisseur

Votre code pourrait être quelque chose comme:

private Supplier<List<String>> supplier = new Supplier<List<String>>(){
    public List<String> get(){
        return loadCountryList();
    }
};


//volatile reference so that changes are published correctly see invalidate()
private volatile Supplier<List<String>> memorized = Suppliers.memoize(supplier);


public List<String> list(){
    return memorized.get();
}

public void invalidate(){
    memorized = Suppliers.memoize(supplier);
}

Chaque fois que j'ai besoin de cache quelque chose, j'aime utiliser le Modèle de Proxy.
De le faire avec ce modèle propose la séparation des préoccupations. L'original de votre
l'objet peut être concerné par le chargement paresseux. Votre proxy (ou le tuteur) de l'objet
peut être responsable de la validation de la cache.

En détail:

• Définir un objet CountryList classe qui est thread-safe, de préférence à l'aide de blocs de synchronisation ou d'autres sémaphore serrures.
• Extrait de cette classe d'interface dans un CountryQueryable interface.
• Définir un autre objet, CountryListProxy, qui implémente l'CountryQueryable.
• Seulement permettre à la CountryListProxy être instancié, et seulement lui permettre d'être référencé
  par le biais de son interface.

À partir d'ici, vous pouvez insérer votre invalidation du cache de la stratégie dans l'objet proxy. Enregistrez le temps de la dernière charge, et la prochaine fois demande à voir les données, de les comparer à l'heure actuelle pour le cache de temps. Définir un niveau de tolérance, où, si trop de temps s'est écoulé, les données sont rechargées.

Autant que le Lazy Load, reportez-vous ici.

Maintenant, pour certains, de bonne maison, un exemple de code:

public interface CountryQueryable {
public void operationA();
public String operationB();
}
public class CountryList implements CountryQueryable {
private boolean loaded;
public CountryList() {
loaded = false;
}
//This particular operation might be able to function without
//the extra loading.
@Override
public void operationA() {
//Do whatever.
}
//This operation may need to load the extra stuff.
@Override
public String operationB() {
if (!loaded) {
load();
loaded = true;
}
//Do whatever.
return whatever;
}
private void load() {
//Do the loading of the Lazy load here.
}
}
public class CountryListProxy implements CountryQueryable {
//In accordance with the Proxy pattern, we hide the target
//instance inside of our Proxy instance.
private CountryQueryable actualList;
//Keep track of the lazy time we cached.
private long lastCached;
//Define a tolerance time, 2000 milliseconds, before refreshing
//the cache.
private static final long TOLERANCE = 2000L;
public CountryListProxy() {
//You might even retrieve this object from a Registry.
actualList = new CountryList();
//Initialize it to something stupid.
lastCached = Long.MIN_VALUE;
}
@Override
public synchronized void operationA() {
if ((System.getCurrentTimeMillis() - lastCached) > TOLERANCE) {
//Refresh the cache.
lastCached = System.getCurrentTimeMillis();
} else {
//Cache is okay.
}
}
@Override
public synchronized String operationB() {
if ((System.getCurrentTimeMillis() - lastCached) > TOLERANCE) {
//Refresh the cache.
lastCached = System.getCurrentTimeMillis();
} else {
//Cache is okay.
}
return whatever;
}
}
public class Client {
public static void main(String[] args) {
CountryQueryable queryable = new CountryListProxy();
//Do your thing.
}
}

Qu'en pensez-vous? Voyez-vous quelque chose de mauvais à ce sujet?

Bleah - vous à l'aide d'une structure de données complexe, Cartographe, avec plusieurs fonctionnalités (carte d'accès, la concurrence un accès différé à la construction de valeurs, etc) en raison d'une seule fonction, vous êtes après (reporté à la création d'une construction-cher objet).

Tout en réutilisant le code est un bon objectif, cette approche ajoute une charge supplémentaire et de la complexité. En outre, il trompe les futurs responsables quand ils voient une carte de données structure de là à penser qu'il y a une carte de clés/valeurs dans là quand il ya vraiment seulement 1 chose (liste des pays). La simplicité, la lisibilité et la clarté sont la clé de maintenance.

Est-il d'autres façon de le faire? Comment puis-je faire mieux? Dois-je regarder tout à fait une autre solution dans ce cas?

Semble que vous êtes après chargement différé. Chercher des solutions à d'autres AFIN de chargement différé des questions. Par exemple, celui-ci couvre la classique double-vérifier approche (assurez-vous que vous utilisez Java 1.5 ou version ultérieure):

Comment résoudre le "Double-Vérifier le Verrouillage est Cassé" Déclaration en Java?

Plutôt que de simplement répéter la solution de code ici, je pense qu'il est utile de lire la discussion sur le chargement différé par l'intermédiaire de double-vérifier qu'il n'y à développer votre base de connaissances. (désolé si cela se présente comme une pompeux - essaye juste apprendre à pêcher plutôt que de nourrir des bla bla bla ...)

Vos besoins sembler assez simple ici. L'utilisation de Cartographe fait de la mise en œuvre plus compliqué que ce qu'il a à être. L'ensemble de la double-vérifier le verrouillage de l'idiome est difficile d'obtenir un droit, et ne fonctionne que sur 1.5+. Et pour être honnête, c'est la rupture de l'une des règles les plus importantes de la programmation:

Optimisation prématurée est la racine de
tous les maux.

Le double-vérifier le verrouillage de l'idiome essaie d'éviter le coût de la synchronisation dans le cas où le cache est déjà chargé. Mais est-ce que les frais généraux vraiment à l'origine des problèmes? Vaut-il le coût de code plus complexe? Je dis supposer qu'il n'est pas jusqu'à ce que le profilage vous dit le contraire.

Voici une solution très simple qui ne nécessite pas de 3ème partie du code (en ignorant les JCIP annotation). Elle permet de faire l'hypothèse que la liste vide signifie que le cache n'a pas encore été chargé. Il empêche également le contenu de la liste des pays d'échapper à code client qui pourrait potentiellement modifier la liste retournée. Si ce n'est pas une préoccupation pour vous, vous pouvez supprimer l'appel à des Collections.unmodifiedList().

public class CountryList {
@GuardedBy("cache")
private final List<String> cache = new ArrayList<String>();
private List<String> loadCountryList() {
//HEAVY OPERATION TO LOAD DATA
}
public List<String> list() {
synchronized (cache) {
if( cache.isEmpty() ) {
cache.addAll(loadCountryList());
}
return Collections.unmodifiableList(cache);
}
}
public void invalidateCache() {
synchronized (cache) {
cache.clear();
}
}
}

C'est simple d'utiliser le ComputingMap choses. Vous avez seulement besoin d'un simple morts de mise en œuvre où toutes les méthodes sont synchronisés, et vous devriez être bien. Ce sera bien évidemment le bloc le premier thread frapper à elle (avoir), et toute autre thread frapper alors que le premier thread charge le cache (et la même chose si quelqu'un appelle le invalidateCache chose - lorsque vous devez également décider si le invalidateCache devrait charger le cache de nouveau, ou tout simplement nulle sortir, laissant la première tentative d'obtenir de nouveau bloc), mais alors tous les fils doivent traverser joliment.

Suivi de Mike solution ci-dessus. Mon commentaire n'a pas de format comme prévu... 🙁

Regarder dehors pour des problèmes de synchronisation dans operationB, surtout depuis load() est lente:

public String operationB() {
if (!loaded) {
load();
loaded = true;
}
//Do whatever.
return whatever;
}

Vous pu le résoudre de cette façon:

public String operationB() {
synchronized(loaded) {
if (!loaded) {
load();
loaded = true;
}
}
//Do whatever.
return whatever;
}

Assurez-vous de TOUJOURS synchroniser sur tous les accès pour le chargement variable.