Qu'est-ce que l'on entend par vecteur en Java est le fil sûr et synchronisé, comment est-ce que cela fait du fil sûr. Je regarde les détails internes de la mise en œuvre
4 Réponses :
Les méthodes sont marquées comme synchronisée . Découvrez le Tutoriel de la méthode synchronisée .
vecteur est considéré comme "thread-coffre-fort" car accédez aux internaux du vecteur est synchronisé. Méthodes telles que ajouter () , get () , taille () , etc., sont tous synchronisés de manière à modifier la structure interne de la vecteur et l'accès à cette structure interne ne peut pas être traité simultanément par des threads distincts.
Il est fait "thread-coffre-fort" par mérite de toutes ses méthodes synchronisées (via le mot-clé synchronisé), voir le code source OpenJDK .
Quel est le mot clé synchronisé qu'il empêche plus d'un thread d'exécuter l'une des méthodes synchronisées en même temps. Il utilise une serrure en interne, qu'un fil doit obtenir lorsqu'il entrait de ces méthodes et que le thread libère quand il laisse la méthode.
Notez que cela n'en aime pas vraiment beaucoup, car empêche l'état interne incohérent du vecteur, cela ne garantit en aucun cas un niveau de cohérence à un niveau supérieur (niveau utile pour une application).
considère cet exemple qui montre que vous devez toujours utiliser la synchronisation Dans votre code d'application (afin que vous puissiez aussi bien utiliser l'arraylist non synchronisé):
+1 Mais vous devez corriger "ce que le mot clé synchronisé est qu'il empêche plus d'un thread d'exécuter la méthode en même temps". Il n'est pas simplement d'accéder à la méthode spécifique bloquée.
@Fredrik: Merci. J'ai essayé de réparer la phrase sans qu'il devienne trop complexe. Je suppose qu'un lien avec une explication plus longue serait en ordre.
Ai-je bien compris, que dans le code, que vous avez fourni, le aurait pu être modifié (ne pas être vide) avant vecteur.add (antérieur); ?
@soshial: C'est vrai. Quelqu'un aurait pu ajouter un élément juste après isempty a été vérifié (de sorte que vous ajoutez une autre parce que vous êtes déjà dans ce bloc si bloque).
Ensuite, je suppose que, il n'a aucun sens en utilisant des analogues de collections de fil-sécurité. Nous venons d'utiliser le fil-danger dans des blocs de synchronisation, non? N'est-ce pas un peu bizarre?
@Soshial: C'est probablement la perspicacité que les développeurs Java ont eu lorsqu'ils ont ajouté une arraylist à Vector et StressBuilder à Stringbuffer (abandonnant «la sécurité du fil intégré» dans le processus). Vous n'êtes pas obligé d'accéder à des blocs de synchronisation dans votre code d'application, cependant, il existe également des constructions plus simples / plus sûres / pratiques / évolutives dans le package Util.Concurrency.
Veuillez trouver les extraits ci-dessous de Java API
Premièrement, il n'est pas possible pour deux invocations de méthodes synchronisées sur le même objet à interlacer. Lorsqu'un thread exécute une méthode synchronisée pour un objet, tous les autres threads invoqués des méthodes synchronisées pour le même bloc d'objet (suspension d'exécution) jusqu'à ce que le premier thread soit effectué avec l'objet.
Deuxièmement, lorsqu'une méthode synchronisée sort, elle établit automatiquement une relation avant la relation avec une invocation ultérieure d'une méthode synchronisée pour le même objet. Cela garantit que les modifications apportées à l'état de l'objet sont visibles pour tous les threads.