Sous Bean Not Safe-Safe: la méthode additifnotexist n'est pas synchronisée, il est donc possible que le même terme soit ajouté deux fois en raison de la condition de course. J'ai annoté la classe à l'aide de JCIP Annotation @Threadsafe En espérant que les tremblements de recherche constateraient que la mise en œuvre n'est pas thread-coffre-fort et signalez-la comme une erreur, mais ce n'est pas le cas. Existe-t-il des outils qui identifient ces types d'erreurs dans la base de code?
Méthodes Additifnotexist et IsExist doivent être synchronisés pour faire ce filet-coffre-fort. Si la méthode isexist est également synchronisée? P>
package com.test;
import java.util.ArrayList;
import java.util.Collection;
import net.jcip.annotations.GuardedBy;
import net.jcip.annotations.ThreadSafe;
@ThreadSafe
public class Dictionary {
@GuardedBy("this")
public Collection<String> terms = new ArrayList<String>();
public void addIfNotExist(final String input) {
if (!this.terms.contains(input)) {
this.terms.add(input);
}
}
public boolean isExist(final String input){
return this.terms.contains(input);
}
public void remove(final String input){
this.terms.remove(input);
}
}
3 Réponses :
Il est extrêmement Difficile pour écrire un code multi-fileté sûr que A un degré de complexité: ce type de verrouillage (utilisant des moniteurs) est semé de toutes sortes de conditions de course intermittentes, de blocages et de problèmes de Livelock qui échappent souvent à la détection jusqu'à la promotion dans les systèmes de production; Si vous le pouvez, envisagez d'utiliser message qui passe , logiciel transactionnelle de mémoire ou structures de données persistantes < / a> à la place.
Findbugs (ou en effet des outils d'analyse statiques) ne peuvent aller que jusqu'à présent pour détecter le code de sécurité non-thread: par leur définition même, les conditions de race sont sensibles au temps - elles nécessitent de nombreuses exécutions à manifester, une analyse statique échoue. Ce respect parce qu'ils n'exécutent aucun code et recherchent uniquement des signatures de code communes. Les meilleures choses sur lesquelles détecter les problèmes sont les suivantes:
Une deuxième paire d'yeux - Reviews de code rigoureux avec des pairs familiarisés avec le code - se rendent en cours dans la recherche de bogues qui ne sont pas immédiatement évidentes pour l'auteur d'origine.
Intégration continue et tests automatisés exhaustifs qui exercent une multi-threadeur sur une variété de matériel et En réponse à la deuxième question, oui, toutes les méthodes qui font référence à Au mieux, vous ne pourrez pas déterminer le résultat de Synchroniser, et pendant que vous ne pouvez toujours pas être sûr de l'ordre dans lequel les appels sont faits (en raison de la nature non déterministe de la planification), mais au moins vous serez garantis que des opérations sur
termes doivent être gardées par un moniteur de synchronisation, qu'il s'agisse d'une opération d'écriture ou de lecture; Considérons ce qui se passe si le thread a des appels Supprimer ("BOB") tandis que le thread B appelle isexists ("BOB") Lorsque vous n'avez pas de synchronisation - le fil a Compactage de la liste des matrices pendant que le thread B tentera de la traverser.
isexists ("bob") , mais il est tout à fait possible que b pourrait lancer intermittente une exception indexporofbounds depuis La taille de la matrice aurait pu changer (c'est-à-dire rétrécie) car elle était traversée.
termes < / code> sera atomique - c'est-à-dire qu'ils ne sont pas modifiés par autre chose, tandis que le fil actuel est en cours d'exécution.
Merci de votre réponse - votre raisonnement sur la raison pour laquelle les isexistes devraient être synchronisés a du sens.
C'est quelque chose que vous pouvez utiliser au moment de l'exécution (lors des tests d'unités automatisés ou des tests d'intégration ou qu'avez-vous) pour aide trouver des problèmes de filetage: Concours IBM (Test de concurrence)
Description du concours:
"La technologie du concours est innovante et contre-intuitive. Spécifiquement, le concours systématiquement et transparent de manière transparente l'exécution des threads de programme tels que les scénarios de programme susceptibles de contenir des conditions de course, des blocages et d'autres bugs intermittemt - sont appelés collectivement des problèmes de synchronisation - sont Forcé de paraître avec une fréquence élevée. Ce faisant, le concours améliore dramatiquement la qualité des tests et réduit les dépenses de développement, car les bogues sont trouvés plus tôt dans le processus de test. "
Où peut-on télécharger le concours? Tout ce que j'ai trouvé, j'ai été des liens morts et des résultats de recherche vides.
Pour trouver des blocs de code incorrectement synchronisé, j'utilise l'algorithme suivant:
enregistrer les threads pour toutes les modifications de champ à l'aide de l'instrumentation. Si un champ est modifié par plusieurs threads sans synchronisation, j'ai trouvé une course de données.
J'ai implémenté cet algorithme à l'intérieur de http://vmlens.com , qui est un outil dynamique pour trouver des races de données à l'intérieur de Java Programmes.