Pourquoi utiliser un ReentrantLock si on peut utiliser synchronized(this) ?

Question

J’essaie de comprendre ce qui rend la serrure d’accès concurrentiel si important si on peut utiliser `` . Dans le code factice ci-dessous, je peux faire soit :

1. synchroniser l’ensemble de la méthode ou de synchroniser la zone vulnérable (synchronized(this){...})
2. OU verrouiller la zone code vulnérable avec une ReentrantLock.

Code :

Answer 1

Je crois qu'une meilleure comparaison entre ReentrantLock et synchronized. ReadWriteLock sert un but différent et n'est donc pas directement analogue synchronized. Dans ce code, il semble y avoir aucune raison d'être à l'aide d'un ReadWriteLock, mais c'est peut être juste l'absence de code.

---

Un ReentrantLock est non structurées, à la différence de synchronized des constructions -- c'est à dire que vous n'avez pas besoin d'utiliser une structure de bloc de verrouillage et peut même placer un verrou sur les méthodes. Un exemple:

private ReentrantLock lock;

public void foo() {
  ...
  lock.lock();
  ...
}

public void bar() {
  ...
  lock.unlock();
  ...
}

Ces flux est impossible de représenter par un seul moniteur en synchronized construire.

---

A côté de cela, ReentrantLock prend en charge de verrouillage d'interrogation et interruptible de verrouillage attend que le soutien de délai. ReentrantLock également en charge configurable à l'équité de la politique, en permettant plus flexible de planification de thread.

Le constructeur de cette classe accepte une option de l'équité paramètre. Lorsque réglé true, en vertu de la prétention, de serrures faveur de l'octroi de l'accès à la plus longue-thread en attente. Sinon ce verrou ne garantissent pas un accès particulier de l'ordre. Les programmes utilisant juste les verrous consulté par de nombreux threads peut afficher plus faible débit global (c'est à dire, sont plus lents; souvent beaucoup plus lent) que ceux utilisant le paramètre par défaut, mais ont de plus petits écarts dans les temps à obtenir des verrous et de garantir l'absence de faim. Notez cependant, que l'équité de serrures ne garantit pas l'équité de la planification de thread. Ainsi, l'un des nombreux fils à l'aide d'un juste serrure peut obtenir plusieurs fois de suite, tandis que d'autres threads actifs ne progressent pas et qui ne détiennent pas de la serrure. Notez également que l'intemporel tryLock méthode ne fait pas honneur à l'équité de réglage. Elle réussit si le verrou est disponible, même si d'autres threads sont en attente.

---

ReentrantLock peut également être plus évolutif, d'effectuer beaucoup mieux en plus conflictuel. Vous pouvez lire plus à ce sujet ici.

Cette affirmation a été contestée, cependant; voir le commentaire suivant:

Dans le réentrant de verrouillage de test, une nouvelle serrure est créé à chaque fois, donc il n'est pas exclusif de verrouillage et les données qui en résulte n'est pas valide. Aussi, l'IBM lien propose pas de code source pour le sous-jacent de référence, donc il est impossible de caractériser si le test a même été réalisés correctement.

---

Quand devez-vous utiliser ReentrantLocks? Selon que developerWorks article...

La réponse est assez simple, l'utiliser lorsque vous avez réellement besoin de quelque chose, il prévoit que l' synchronized n'est pas, comme chronométré attente de verrouillage, interruptible attente de verrouillage, non-structurées par bloc de serrures, de multiples variables de condition, ou d'un lock de l'interrogation. ReentrantLock a également l'évolutivité des avantages, et vous devez les utiliser si vous avez une situation qui présente une grande contention, mais n'oubliez pas que la grande majorité des synchronized blocs presque jamais présenter de contention, sans parler de haute lice. Je vous conseille de développement avec synchronisation jusqu'à ce que la synchronisation s'est avérée insuffisante, plutôt que de simplement en supposant que "le rendement sera meilleur" si vous utilisez ReentrantLock. Rappelez-vous, ce sont des outils avancés pour les utilisateurs avancés. (Et vraiment les utilisateurs avancés ont tendance à préférer le plus simple des outils dont ils peuvent se trouver jusqu'à ce qu'ils sont convaincus les outils simples sont insuffisantes.) Comme toujours, le faire d'abord, et puis vous soucier de savoir si ou non vous avez pour le rendre plus rapide.

Answer 2

Réentrante serrure permettre le verrouillage de l'entrée du titulaire des blocs de code même après qu'il a déjà obtenu le verrouillage en entrant dans d'autres blocs de code. Non réentrant de verrouillage aurait la serrure de bloc porte sur lui-même, comme elle l'aurait pour la libérer, il a obtenu à partir d'un autre bloc de code de retrouver la même serrure pour entrer dans le sous-verrouillage nécessitant bloc de code

 public synchronized void functionOne() {

 // do something

 functionTwo();

 // do something else

 // redundant, but permitted...
 synchronized(this) {
 // do more stuff
 } 
 }

 public synchronized void functionTwo() {
 // do even more stuff!
 }

Capacités étendues de réentrant de verrouillage comprennent :-

1) La possibilité d'avoir plus d'une variable de condition par moniteur. Les moniteurs d'utiliser le mot-clé synchronized ne peut avoir qu'un. Cela signifie réentrant serrures en charge plus d'un wait () et notify() de la file d'attente. 2) La capacité de faire de la serrure "juste". "[juste] verrous faveur de l'octroi de l'accès à la plus longue-thread en attente. Sinon ce verrou ne garantissent pas un accès particulier de l'ordre." Synchronisé blocs sont injustes. 3) La possibilité de vérifier si le verrou est détenu. 4) La possibilité d'obtenir la liste des threads en attente sur la serrure.

Les inconvénients de réentrant serrures sont :-

Besoin d'ajouter instruction import. Besoin d'envelopper de verrouillage acquisitions dans un try/finally bloc. De ce fait, il est plus laid que le mot-clé synchronized. La synchronisation de mot-clé peut être mis dans les définitions de méthode qui évite la nécessité d'un bloc, ce qui réduit la nidification.

Lors de l'utilisation :-de

1. ReentrantLock peut-être plus apte à utiliser si vous avez besoin de mettre en œuvre un fil qui traverse une liste liée, le verrouillage du nœud suivant et puis déverrouillage du nœud actuel.
2. Synchronisé mot-clé est pertinent à la situation telle que verrouillage de grossissement, fournit adaptative de la filature,biaisée de verrouillage et le potentiel de verrouillage de l'élision via échapper à l'analyse. Ces optimisations ne sont pas actuellement mis en œuvre pour ReentrantLock.

Pour plus d'informations, visitez: http://www.ibm.com/developerworks/java/library/j-jtp10264/

Answer 3

ReentrantReadWriteLock est une institution spécialisée de verrouillage alors que synchornized(ce) est un objectif général de verrouillage. Ils sont similaires mais pas tout à fait la même.

Vous êtes en droit de vous permettre de l'utiliser synchronisée(ce) au lieu de ReentrantReadWriteLock mais l'inverse n'est pas toujours vrai.

Si vous souhaitez mieux comprendre ce qui rend ReentrantReadWriteLock spéciale de trouver des informations sur les producteurs et les consommateurs, la synchronisation des threads.

En général, on peut rappeler que l'ensemble de la méthode de synchronisation et à des fins générales de synchronisation (en utilisant le mot-clé synchronized) peut être utilisé dans la plupart des applications sans penser trop à propos de la sémantique de la synchronisation, mais si vous avez besoin de serrer les performances de votre code, vous devrez peut-être explorer d'autres, plus fine ou à des fins spéciales de mécanismes de synchronisation.

Par la façon dont, à l'aide de la synchronisation(ce) - et, en général, verrouillage à l'aide d'une classe publique peut être problématique, car il ouvre votre code de potentiel dead-locks parce que quelqu'un d'autre pas sciemment pourrait essayer de verrouiller à l'encontre de votre objet quelque part ailleurs dans le programme.