Maison  >  Article  >  Java  >  Analyse des concepts de base de la sécurité des threads en Java

Analyse des concepts de base de la sécurité des threads en Java

黄舟
黄舟original
2017-09-18 09:36:111258parcourir

Cet article présente principalement l'analyse des concepts de base de la sécurité des threads Java. J'espère qu'il pourra vous donner une référence et que les amis qui en ont besoin pourront en savoir plus.

Compréhension initiale de la sécurité des threads Java. D'une manière générale, la sécurité des threads JAVA fait référence à une caractéristique des objets Java dans un environnement d'exécution multithread, ce qui signifie que chaque appel peut obtenir le résultat logique correct dans des conditions normales (différentes des situations d'appel spéciales). Essentiellement, la logique de contrôle de synchronisation est ajoutée au comportement de méthode de l'objet, et l'appelant peut utiliser l'objet en toute sécurité sans aucun contrôle de synchronisation supplémentaire.

1. Définition de la sécurité des threads

Lorsque plusieurs threads accèdent à un objet, si ces threads n'en ont pas besoin être pris en compte La planification et l'exécution alternative dans l'environnement d'exécution ne nécessitent pas de synchronisation supplémentaire ou toute autre opération de coordination sur l'appelant. Le comportement d'appel de cet objet peut obtenir le résultat correct, alors cet objet est thread-safe. Cette définition est très stricte. Elle exige que tous les codes thread-safe aient une caractéristique : le code lui-même encapsule tous les moyens de garantie d'exactitude nécessaires, de sorte que l'appelant n'a pas à se soucier des problèmes de multithread et qu'il n'est pas nécessaire de l'implémenter. Rehe prend des mesures pour garantir un appel multithread correct.

2. Sécurité des threads en langage Java

Afin d'avoir une compréhension plus approfondie de la sécurité des threads, suivez les sécurité des threads La « force de sécurité » est classée de forte à faible : immuable, absolument thread-safe, relativement thread-safe, compatible avec les threads et antagoniste des threads.

2.1 Immuable

Après jDK1.5, les objets immuables doivent être thread-safe, que ni l'un ni l'autre l'implémentation de la méthode de l'objet ni l'appelant de la méthode n'ont besoin d'implémenter de mesures de sécurité pour les threads. Pour les attributs, objets ou méthodes modifiés par le mot-clé final, leur état visible externe ne changera jamais. Si les données partagées sont un type de données de base, leur immuabilité peut être garantie en utilisant le mot-clé final lors de leur définition. Par exemple, l'objet de classe String est un objet immuable typique. Lorsque nous appelons substring(), replace() et concat(), ces méthodes n'affecteront pas sa valeur d'origine et renverront uniquement un objet chaîne nouvellement construit.

2.2 Sécurité relative des threads

La sécurité relative des threads est ce que nous appelons habituellement la sécurité des threads, elle nécessite de s'assurer que l'individu les opérations sur cet objet sont thread-safe. La plupart des classes thread-safe en Java appartiennent à ce type, comme Vector, HashTable, etc.

2.3 Compatibilité des threads

La compatibilité des threads signifie que l'objet lui-même n'est pas thread-safe, mais peut être transmis via l'appel Le client utilise correctement les méthodes de synchronisation pour garantir que les objets peuvent être utilisés en toute sécurité dans des environnements simultanés.

2.3 Opposition de thread

L'opposition de thread signifie que peu importe que l'extrémité appelante adopte ou non des mesures de synchronisation, elle ne peut pas coder utilisé simultanément dans un environnement threadé. Étant donné que le langage Java est intrinsèquement multithread, le code qui exclut le multithread, tel que l'opposition des threads, apparaît rarement. Les opérations courantes d'opposition de thread incluent les méthodes suspend() et curriculum vitae() de la classe Thread, System.setIn(), etc.

3. Méthode d'implémentation thread-safe

3.1 Synchronisation mutuellement exclusive

La synchronisation par exclusion mutuelle est le moyen le plus courant de garantir l'exactitude de la concurrence. La synchronisation consiste à garantir que lorsque plusieurs threads accèdent simultanément aux données partagées, les données partagées ne sont accessibles que par un seul thread en même temps. temps. Le mutex est un moyen de réaliser la synchronisation. Les sections critiques, les mutex et les sémaphores sont les principaux moyens de mettre en œuvre l'exclusion mutuelle. L'exclusion mutuelle est la cause, la synchronisation est l'effet, l'exclusion mutuelle est la méthode et la synchronisation est le but.

En Java, la méthode de synchronisation mutuellement exclusive la plus élémentaire est le mot-clé synchronisé. De plus, vous pouvez également utiliser le verrou réentrant (ReentrantLock) dans le package java.util.concurrent pour réaliser la synchronisation. Leur utilisation est très similaire, mais il existe quelques différences dans l'écriture du code. L'une est un verrouillage d'exclusion mutuelle au niveau de l'API (les méthodes lock() et unlock() sont complétées par des blocs d'instructions try/finally), et l'autre est. un verrou d'exclusion mutuelle au niveau de la syntaxe native. Cependant, le verrou réentrant a les trois éléments suivants plus que synchronisés :
L'attente peut être interrompue : signifie que lorsque le thread détenant le verrou ne libère pas le verrou pendant un long moment, le thread en attente peut choisir d'abandonner l'attente et gérer d'autres choses à la place. La fonction d'interruption est utile pour gérer les blocs synchronisés qui prennent des temps d'exécution très longs.

Un verrouillage équitable peut être obtenu : un verrouillage équitable signifie que lorsque plusieurs threads attendent le même verrou, ils doivent obtenir le verrou dans l'ordre selon l'ordre chronologique de la demande de verrouillage injuste ; Je ne le garantis pas. Le verrouillage synchronisé est injuste, et le verrouillage réentrant est également injuste par défaut, mais vous pouvez exiger l'utilisation d'un verrouillage équitable via le constructeur avec une valeur booléenne.

Les verrous peuvent être liés à plusieurs conditions : cela signifie qu'un objet verrou réentrant peut être lié à plusieurs objets Condition en même temps. En mode synchronisé, les méthodes wait() et notify() ou notifyAll() de l'objet verrou. peut implémenter un Si vous souhaitez associer une condition implicite à plusieurs conditions, vous devez ajouter un verrou supplémentaire. Cependant, vous n'avez pas besoin de le faire pour les verrous réentrants. Il vous suffit d'appeler la méthode newCondition() plusieurs. fois.

3.2 Synchronisation non bloquante

Le problème le plus important de la synchronisation mutuellement exclusive est causé par le blocage et le réveil des threads up Problèmes de performances, c'est une stratégie de concurrence pessimiste, pensant toujours que tant que des mesures de synchronisation correctes ne sont pas prises, des problèmes surviendront. Mais nous avons une autre option : une stratégie de concurrence optimiste basée sur la détection des conflits. En termes simples, l'opération est effectuée en premier si aucun autre thread n'est en compétition pour les données partagées, l'opération réussit s'il y a un conflit pour les données partagées. Un conflit se produit, puis prenez d'autres mesures de compensation. De nombreuses implémentations de cette stratégie de concurrence optimiste n'ont pas besoin de suspendre le thread, c'est ce qu'on appelle une synchronisation non bloquante.

Résumé

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn