Est-ce que Java Regex est Thread Safe?

Question

J'ai une fonction qui utilise Pattern#compile et un Matcher pour rechercher un motif dans une liste de chaînes de caractères.

Cette fonction est utilisée dans plusieurs threads. Chaque thread aura un motif unique passé à Pattern#compile lors de sa création. Le nombre de threads et de motifs est dynamique, ce qui signifie que je peux ajouter plus de Pattern et de threads pendant la configuration.

Est-ce que je dois mettre un synchronize sur cette fonction s'il utilise des regex? Regex en java est-il thread-safe?

Answer 1

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 concurrents. Les instances de la classe Matcher ne sont pas sûres pour une telle utilisation.

Si vous cherchez du code centré sur les performances, essayez de réinitialiser l'instance Matcher en utilisant la méthode reset(), au lieu de créer de nouvelles instances. Cela réinitialiserait l'état de l'instance Matcher, la rendant utilisable pour la prochaine opération regex. En fait, c'est l'état maintenu dans l'instance Matcher qui est responsable de son insécurité pour un accès concurrent.

Answer 2

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

RÉSUMÉ :

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

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

En revanche, vous ne devriez pas partager un Matcher entre différents threads. Ou tout au moins, si vous le faisiez un jour, vous devriez utiliser une synchronisation explicite.

Answer 3

Alors, 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 être 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. Autrement dit, vous ne devez pas exposer le Matcher ainsi créé à d'autres threads.

Honnêtement, c'est le risque de n'importe quelle question de sécurité des threads. La réalité est que n'importe quel code peut être rendu non sûr pour les threads si vous vous en donnez la peine. Heureusement, il existe des merveilleux livres qui nous enseignent une multitude de façons dont nous pourrions ruiner notre code. Si nous évitons ces erreurs, nous réduisons grandement notre propre probabilité de problèmes de threading.

Answer 4

Un rapide coup d'œil au code de Matcher.java montre un tas de variables membres incluant le texte qui est en cours d'appariement, des tableaux pour les groupes, quelques index pour maintenir la localisation et quelques boolean pour d'autres états. Tout cela pointe vers un Matcher étatique qui ne se comporterait pas bien s'il était accédé par plusieurs Threads. C'est ce que dit aussi la JavaDoc:

Les instances de cette classe ne sont pas sécurisées pour une utilisation par plusieurs threads concurrents.

Ce n'est un problème que si, comme le souligne @Bob Cross, vous faites en sorte de permettre l'utilisation de votre Matcher dans des Threads séparés. Si vous avez besoin de le faire, et que vous pensez que la synchronisation posera problème pour votre code, une option que vous avez est d'utiliser un objet de stockage ThreadLocal pour maintenir un Matcher par thread de travail.

Answer 5

En résumé, vous pouvez réutiliser (conserver dans des variables statiques) les motifs Pattern compilés et leur demander de vous fournir de nouveaux Matchers lorsque nécessaire pour valider ces motifs regex contre une chaîne de caractères

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

/**
 * Aide à la validation
 */
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);
  }

  /**
   * Vérifie si l'e-mail est valide
   */
  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/ (près de la fin) concernant le motif RegEx utilisé ci-dessus pour valider les e-mails (au cas où il ne conviendrait pas aux besoins de validation des e-mails tels qu'ils sont présentés ici)