Quelles sont les différences entre les verrous Java ?

Verrouillage équitable/verrouillage injuste

Le verrouillage équitable signifie que plusieurs threads acquièrent le verrou dans l'ordre pour lequel ils demandent il se verrouille.

Un verrouillage injuste signifie que l'ordre dans lequel plusieurs threads acquièrent des verrous n'est pas dans l'ordre dans lequel ils demandent des verrous. Il est possible que le thread qui a appliqué plus tard acquière le verrou avant le thread qui a appliqué en premier. Il est possible que cela provoque une inversion des priorités ou une famine.

Pour Java ReentrantLock, spécifiez si le verrou est un verrou équitable via le constructeur, et la valeur par défaut est un verrou injuste. L’avantage des verrous injustes est que le débit est supérieur à celui des verrous équitables.

Pour Synchronized, c'est aussi un verrouillage injuste. Puisqu'il n'implémente pas la planification des threads via AQS comme ReentrantLock, il n'y a aucun moyen de le transformer en un verrou équitable.

Verrouillage réentrant

Le verrouillage réentrant, également appelé verrouillage récursif, signifie que lorsque le même thread acquiert le verrou dans la méthode externe, il entre dans la méthode interne Le verrou sera acquis automatiquement. C'est un peu abstrait, mais il y a un exemple de code ci-dessous.

Pour Java ReentrantLock, son nom peut être vu comme un verrou réentrant, et son nom est Reentrant Lock.

Pour Synchronisé, c'est aussi un verrou réentrant. L’un des avantages des verrous réentrants est que les blocages peuvent être évités dans une certaine mesure.

synchronized void setA() throws Exception{
    Thread.sleep(1000);
    setB();
}
synchronized void setB() throws Exception{
    Thread.sleep(1000);
}

Le code ci-dessus est une fonctionnalité d'un verrou réentrant. S'il ne s'agit pas d'un verrou réentrant, setB peut ne pas être exécuté par le thread actuel, ce qui peut provoquer un blocage.

Verrouillage exclusif/verrouillage partagé

Le verrouillage exclusif signifie que le verrou ne peut être détenu que par un seul thread à la fois.

Le verrouillage partagé signifie que le verrou peut être détenu par plusieurs threads.

Pour Java ReentrantLock, c'est un verrou exclusif. Mais pour une autre classe d'implémentation de Lock, ReadWriteLock, son verrou en lecture est un verrou partagé et son verrou en écriture est un verrou exclusif.

Le verrou partagé du verrou de lecture garantit que la lecture simultanée est très efficace et que les processus de lecture, d'écriture, d'écriture et d'écriture s'excluent mutuellement.

Les verrous exclusifs et partagés sont également implémentés via AQS, et différentes méthodes sont mises en œuvre pour obtenir des verrous exclusifs ou partagés.

Pour Synchronized, il s'agit bien sûr d'un verrou exclusif.

Verrouillage mutex/verrouillage en lecture-écriture

Le verrouillage exclusif/verrouillage partagé mentionné ci-dessus est un terme large, et le verrouillage mutex/verrouillage en lecture-écriture est une réalisation spécifique .

L'implémentation spécifique du verrouillage mutex en Java est ReentrantLock.

L'implémentation spécifique du verrouillage en lecture-écriture en Java est ReadWriteLock.

Verrouillage optimiste/verrouillage pessimiste

Le verrouillage optimiste et le verrouillage pessimiste ne font pas référence à des types spécifiques de verrous, mais à la perspective de visualisation de la concurrence et de la synchronisation.

Le verrouillage pessimiste estime que les opérations simultanées sur les mêmes données seront définitivement modifiées. Même s'il n'y a pas de modification, elles seront considérées comme modifiées. Ainsi, pour les opérations concurrentes sur les mêmes données, le verrouillage pessimiste prend la forme d'un verrouillage. Pessimiste, je pense que les opérations simultanées sans verrouillage poseront certainement des problèmes.

Le verrouillage optimiste estime que les opérations simultanées sur les mêmes données ne seront pas modifiées. Lors de la mise à jour des données, les données seront mises à jour en essayant de mettre à jour et de mettre à jour constamment les données. Avec un peu d'optimisme, il n'y aura aucun problème avec les opérations simultanées sans verrouillage.

D'après la description ci-dessus, nous pouvons voir que le verrouillage pessimiste convient aux scénarios avec de nombreuses opérations d'écriture, et le verrouillage optimiste convient aux scénarios avec de nombreuses opérations de lecture. Ne pas verrouiller apportera beaucoup de performances. améliorations.

L'utilisation du verrouillage pessimiste en Java consiste à utiliser différents verrous.

L'utilisation du verrouillage optimiste en Java est une programmation sans verrouillage, et l'algorithme CAS est souvent utilisé. Un exemple typique est la classe atomique, qui implémente la mise à jour des opérations atomiques via CAS spin.

Verrouillage segmenté

Le verrouillage segmenté est en fait une conception de verrouillage, pas un verrou spécifique. Pour ConcurrentHashMap, sa mise en œuvre simultanée est efficace. Les opérations simultanées sont réalisées grâce à des verrous segmentés.

Prenons ConcurrentHashMap pour parler de la signification et de l'idée de conception du verrouillage de segment. Le verrouillage de segment dans ConcurrentHashMap est appelé Segment, qui est similaire à la structure de HashMap (l'implémentation de HashMap dans JDK7 et JDK8). , c'est-à-dire que l'interne Il a un tableau Entry, et chaque élément du tableau est une liste chaînée, c'est aussi un ReentrantLock (le segment hérite de ReentrantLock).

Lorsque vous devez mettre un élément, il ne verrouille pas l'intégralité du hashmap, mais utilise d'abord le hashcode pour savoir dans quel segment il doit être placé, puis verrouille ce segment, donc quand quand multi-thread est mis , tant qu'il n'est pas placé dans un segment, une véritable insertion parallèle est obtenue.

Cependant, lors du comptage de la taille, lors de l'obtention des informations globales de hashmap, vous devez obtenir tous les verrous de segment pour compter.

Le but de la conception du verrouillage segmenté est d'affiner la granularité du verrouillage. Lorsque l'opération n'a pas besoin de mettre à jour l'intégralité du tableau, un seul élément du tableau est verrouillé.

Verrouillage biais/Verrouillage léger/Verrouillage lourd

Ces trois types de verrous font référence à l'état du verrou et sont destinés à être synchronisés. Dans Java 5, une synchronisation efficace est obtenue en introduisant un mécanisme de mise à niveau du verrouillage. L'état de ces trois verrous est indiqué par les champs dans l'en-tête d'objet du moniteur d'objets.

Le verrouillage biaisé signifie qu'un morceau de code de synchronisation est toujours accédé par un thread, puis le thread acquerra automatiquement le verrou. Réduisez le coût d’acquisition des serrures.

Le verrouillage léger signifie que lorsque le verrou est un verrou biaisé et qu'un autre thread y accède, le verrou biaisé sera mis à niveau vers un verrou léger. D'autres threads tenteront d'acquérir le verrou via la rotation sans bloquer, améliorant ainsi les performances.

Un verrou lourd signifie que lorsque le verrou est un verrou léger, même si un autre fil tourne, la rotation ne continuera pas éternellement. Lorsqu'il tourne un certain nombre de fois, il n'a pas encore été acquis. entrera en blocage et le verrou se développera en un verrou lourd. Les verrous lourds bloqueront d’autres threads d’application et réduiront les performances.

Spin lock

En Java, un spin lock signifie que le thread essayant d'acquérir le verrou ne se bloquera pas immédiatement, mais tentera d'acquérir le verrou en boucle , l'avantage est de réduire la consommation de changement de contexte de thread, mais l'inconvénient est que la boucle consomme du CPU.

Site Web php chinois, un grand nombre de Tutoriels d'introduction à Java gratuits, bienvenue pour apprendre en ligne !

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!