Cours dans les collections Java sur la sécurité des threads

Classes Thread-safe dans les collections Java

Classes Thread-safe

Dans le framework de collection, certaines classes sont thread-safe, elles sont toutes apparues dans jdk1.1. Après jdk1.2, de nombreuses classes non thread-safe sont apparues. Voici ces classes de synchronisation thread-safe :

vecteur : Il possède un mécanisme de synchronisation de plus (sécurité des threads) que arraylist. En raison de sa faible efficacité, son utilisation n'est plus recommandée. Dans les applications Web, en particulier les pages frontales, l'efficacité (vitesse de réponse des pages) est souvent une priorité.

statck : classe de pile, premier entré, dernier sorti

hashtable : plus thread-safe que hashmap

énumération : énumération, équivalente à l'itérateur

Sauf ceux-ci, tout le reste est constitué de classes et d'interfaces non thread-safe.

Les méthodes des classes thread-safe sont synchronisées et ne sont accessibles qu'une à la fois. C’est un objet lourd et peu efficace.

Autres :

1. La différence entre hashtable et hashmap

hashtable est thread-safe, c'est-à-dire que les méthodes hashtable fournissent un mécanisme de synchronisation qui n'est pas thread-safe ; , c'est-à-dire qu'aucun mécanisme de synchronisation n'est fourni ; la table de hachage ne permet pas d'insérer des valeurs nulles, contrairement à hashmap !

2 Que faire si plusieurs threads modifient une collection simultanément

Utilisez l'ancien vecteur/table de hachage. class

StringBuffer est thread-safe, tandis que StringBuilder n'est pas thread-safe. Sans une compréhension approfondie de la sécurité et de l'insécurité, il est facile de créer l'illusion que toutes les opérations sur StringBuffer sont thread-safe. Cependant, la sécurité des threads garantie par Java signifie que l'exécution de sa méthode est exclusive. plusieurs appels à l'objet lui-même, il est toujours en sécurité. Regardez l'exemple ci-dessous. Il existe un contenu de membre de données dans StringBufferTest, qui est utilisé pour l'expansion. Chaque ajout est thread-safe, mais la combinaison de plusieurs ajouts n'est pas thread-safe. mais si vous ajoutez le mot-clé synchronisé aux méthodes log et getContest, les résultats deviendront très organisés. Si vous passez à StringBuider ou même ajoutez à mi-chemin, cela cédera également la place à d'autres threads fonctionnant sur cette base :

public class StringBufferTest {
  private StringBuffer contents = new StringBuffer();
  public void log(String message){
   contents.append(System.currentTimeMillis());
   contents.append("; ");
   contents.append(Thread.currentThread().getName());
   for(int i=0;i<10000;i++){
    contents.append(i);  
     contents.append(message);  //append本身是线程安全的，修改contents时，其它线程无法访问。
     contents.append("\n");
   }
   contents.append("\n\n");
  }
  public void getContents(){
   System.out.println(contents);
  }
}
 
class RunThread extends Thread{
  String message;
  StringBufferTest buffer;
  public RunThread(StringBufferTest buffer, String message){
   this.buffer = buffer;
   this.message = message;
  }
  public void run(){
   while(true){
     buffer.log(message);
     buffer.getContents();
   }
  }
  public static void main(String[] args) {
   StringBufferTest ss = new StringBufferTest();
   new RunThread(ss, "you").start();
   new RunThread(ss, "me").start();
   new RunThread(ss, "she").start();
  }
}

Les méthodes de StringBuilder et StringBuffer sont exactement les mêmes, c'est un problème multi-thread et mono-thread. Lorsqu'un thread appelle la méthode append du même StringBuffer, cela n'a rien à voir avec le fait qu'il soit thread-safe. À moins que votre résultat ne soit que la série de chaînes ajoutée est gâchée, cela signifie qu'elle n'est pas sécurisée pour les threads. La sécurité des threads signifie qu’un seul thread peut accéder aux ressources critiques à tout moment. La sécurité des threads ne signifie pas que ses séries d'opérations sont synchronisées, mais que les autres threads ne sont pas autorisés à changer lorsqu'il exécute une certaine méthode. Le fait qu'une classe soit thread-safe en dépend. Plusieurs threads s'exécutent en même temps, et ces threads peuvent exécuter une certaine méthode en même temps. Mais le résultat de chaque opération est le même que celui d'une exécution monothread, on peut donc dire qu'elle est thread-safe. Étant donné que la méthode de journalisation n'est pas verrouillée, tout le monde peut obtenir des fragments d'exécution du processeur une fois le verrou d'ajout libéré.

Mais ne vous méprenez pas sur la sécurité multithread :

public String toString(){
  StringBuffer buffer = new StringBuffer();
  buffer.append(&#39;<&#39;);
  buffer.append(this.name);
  buffer.append(&#39;>&#39;);
  return buffer.toString();
 }

Ce code est entièrement thread-safe. Les variables définies à l'intérieur de la méthode seront créées lors de l'entrée de chaque thread ! Il n’y a aucun problème de sécurité des threads. Généralement, les variables liées à la sécurité du système sont généralement des variables membres. L'implémentation interne de stringBuffer elle-même est sécurisée pour le site ! La sécurité des threads signifie que les fonctions fournies par la classe elle-même sont sûres. Autrement dit, si vous insérez une chaîne, alors cette insertion de chaîne est sûre, mais vous devez insérer deux chaînes et vous décidez de l'ordre des deux chaînes. S'il y a d'autres erreurs d'insertion entre-temps, la classe n'aura pas d'importance. . Oui Problème avec votre propre code.

Merci d'avoir lu, j'espère que cela pourra vous aider, merci pour votre soutien à ce site !

Pour plus d'articles sur la sécurité des threads sur les classes dans les collections Java, veuillez prêter attention au site Web PHP chinois !