Tests unitaires pour une publication sûre

Question

Comment voulez-vous obtenir une garantie de publication sécurisée en Java?

Pour être concret:

J'ai une interface de cache qui a une méthode getOrLoad (clé K, chargeur ObjectLoader). Le problème est que si un cache ne peut pas trouver un objet pour la clé donnée, il doit alors le charger à partir de l'instance ObjectLoader. Toutefois, le cache est nécessaire pour garantir que le fait de charger un objet depuis le chargeur et de le placer dans le cache constitue une publication sûre.

Je suis en train d'écrire un test Junit générique pour cette interface de cache et je me demande comment je pourrais vérifier que les implémentations de cache respectent cette garantie de publication sûre.

Des idées? Le code actuel se trouve dans la partie test-systest du référentiel de code si vous le souhaitez. vouloir fouiller les vrais fichiers.

Answer 1

J'ai découvert un présentation JavaOne de Bill Pugh, Brian Goetz et Cliff Cliquez sur le test du code concurrent. Ils ont suggéré cette approche, celle qui, à mon avis, est la meilleure que j'ai entendue:

Un certain nombre de producteurs créent des objets avec état et non sécurisés avec une implémentation de hashCode dépendant de l'état. Comme les objets sont envoyés via le point supposé de synchronisation, les hashCodes sont additionnés (thread-localement). De même, les consommateurs de l’autre côté de la porte récapitulent les codes de hachage.

À la fin du test, nous résumons tous les résultats pour les producteurs et les consommateurs. Si les deux sommes sont égales, le test réussit.

Nous pourrions également utiliser XOR comme alternative à la somme. En fait, toute opération commutative fera l'affaire. Gardez simplement à l’esprit que le faisceau de test lui-même ne doit pas introduire de synchronisation supplémentaire.

Answer 2

Peut-être pouvez-vous utiliser ConTest pour au moins vous donner un peu plus de confiance en ce que votre code est correct.

Vous aurez besoin d'implémenter quelques tests qui exécutent plusieurs threads simultanément. ConTest augmentera ensuite la probabilité qu'un bogue d'accès simultané soit réellement révélé en instrumentant du code octet (en ajoutant des instructions de mise en veille conditionnelle et de rendement contrôlées de manière heuristique).

Answer 3

Obtenir une erreur due à une publication non sécurisée est très difficile (si quelqu'un sait comment, dites-le moi). L'analyse statique est votre meilleur choix pour une solution automatisée. Je m'en tiens à la révision du code sans trop m'inquiéter.