Java Regex Thread est-il sûr?

J'ai une fonction qui utilise Pattern#compileet a Matcherpour rechercher une liste de chaînes pour un motif.

Cette fonction est utilisée dans plusieurs threads. Chaque thread aura un modèle unique transmis au Pattern#compilelorsque le thread est créé. Le nombre de threads et de modèles est dynamique, ce qui signifie que je peux ajouter plus de Patternthreads et de threads pendant la configuration.

Dois-je mettre un synchronizesur cette fonction si elle utilise regex? Est-ce que regex dans les threads Java est sûr?

Oui , à partir de la documentation de l'API Java pour la classe Pattern

Les instances de cette classe (Pattern) sont immuables et peuvent être utilisées en toute sécurité par plusieurs threads simultanés. Les instances de la classe Matcher ne sont pas sûres pour une telle utilisation.

Si vous recherchez du code centré sur les performances, essayez de réinitialiser l'instance Matcher à l'aide de la méthode reset (), au lieu de créer de nouvelles instances. Cela réinitialiserait l'état de l'instance Matcher, le rendant utilisable pour la prochaine opération regex. En fait, c'est l'état maintenu dans l'instance Matcher qui est responsable de sa non-sécurité pour l'accès simultané.

Sécurité des threads avec des expressions régulières en Java

RÉSUMÉ:

L'API d'expression régulière Java a été conçue pour permettre à un seul modèle compilé d'être partagé entre plusieurs opérations de correspondance.

Vous pouvez appeler Pattern.matcher () en toute sécurité sur le même modèle à partir de différents threads et utiliser en toute sécurité les correspondants simultanément. Pattern.matcher () est sûr de construire des matchers sans synchronisation. Bien que la méthode ne soit pas synchronisée, interne à la classe Pattern, une variable volatile appelée compiled est toujours définie après la construction d'un pattern et lue au début de l'appel à matcher (). Cela force tout thread faisant référence au modèle à "voir" correctement le contenu de cet objet.

D'un autre côté, vous ne devriez pas partager un Matcher entre différents threads. Ou du moins, si jamais vous l'avez fait, vous devriez utiliser la synchronisation explicite.

Même si vous devez vous rappeler que la sécurité des threads doit également prendre en compte le code environnant, vous semblez avoir de la chance. Le fait que les Matchers soient créés à l'aide de la méthode de fabrique matcher du Pattern et qu'ils manquent de constructeurs publics est un signe positif. De même, vous utilisez la méthode statique de compilation pour créer le modèle englobant .

Donc, en bref, si vous faites quelque chose comme l'exemple:

Pattern p = Pattern.compile("a*b");
Matcher m = p.matcher("aaaaab");
boolean b = m.matches();

vous devriez vous débrouiller plutôt bien.

Suivi de l'exemple de code pour plus de clarté: notez que cet exemple implique fortement que le Matcher ainsi créé est thread-local avec le Pattern et le test. Par exemple, vous ne devez pas exposer le Matcher ainsi créé à d'autres threads.

Franchement, c'est le risque de toute question de sécurité des threads. La réalité est que tout code peut être rendu non sûr pour les threads si vous essayez assez fort. Heureusement, il existe de merveilleux livres qui nous apprennent tout un tas de façons de ruiner notre code. Si nous restons à l'écart de ces erreurs, nous réduisons considérablement notre propre probabilité de problèmes de threading.

Un rapide coup d'œil au code pour Matcher.javamontre un tas de variables membres, y compris le texte qui est mis en correspondance, des tableaux pour les groupes, quelques index pour maintenir l'emplacement et quelques booleans pour un autre état. Tout cela pointe vers un état Matcherqui ne se comporterait pas bien s'il était accédé par plusieurs Threads. Tout comme le JavaDoc :

Les instances de cette classe ne sont pas sûres pour une utilisation par plusieurs threads simultanés.

Ce n'est un problème que si, comme le souligne @Bob Cross, vous faites tout votre possible pour autoriser l'utilisation de votre Matcherdans des Threads séparés . Si vous devez faire cela et que vous pensez que la synchronisation sera un problème pour votre code, une option que vous avez est d'utiliser un ThreadLocalobjet de stockage pour maintenir un Matcherthread de travail par thread.

Pour résumer, vous pouvez réutiliser (conserver dans des variables statiques) le (s) Pattern (s) compilé (s) et leur dire de vous donner de nouveaux Matchers en cas de besoin pour valider ces motifs regex par rapport à une chaîne

import java.util.regex.Matcher;
import java.util.regex.Pattern;

/**
 * Validation helpers
 */
public final class Validators {

private static final String EMAIL_PATTERN = "^[_A-Za-z0-9-]+(\\.[_A-Za-z0-9-]+)*@[A-Za-z0-9-]+(\\.[A-Za-z0-9-]+)*(\\.[A-Za-z]{2,})$";

private static Pattern email_pattern;

  static {
    email_pattern = Pattern.compile(EMAIL_PATTERN);
  }

  /**
   * Check if e-mail is valid
   */
  public static boolean isValidEmail(String email) { 
    Matcher matcher = email_pattern.matcher(email);
    return matcher.matches();
  }

}

voir http://zoomicon.wordpress.com/2012/06/01/validating-e-mails-using-regular-expressions-in-java/ (vers la fin) concernant le modèle RegEx utilisé ci-dessus pour valider les e-mails ( au cas où cela ne correspond pas à vos besoins de validation par e-mail tel qu'il est affiché ici)