L'interface ReadWriteLock de JAVA et son implémentation de la méthode ReentrantReadWriteLock

L'éditeur suivant vous proposera un article sur l'interface ReadWriteLock et son implémentation de la méthode ReentrantReadWriteLock. L'éditeur pense que c'est plutôt bien, alors je vais le partager avec vous maintenant et le donner comme référence. Suivons l'éditeur pour y jeter un œil.

Les verrous du package locks du package de concurrence Java ont été essentiellement introduits. Après avoir clairement compris le mécanisme de fonctionnement du synchroniseur AQS, ReentrantLock est la clé. il sera beaucoup plus facile d'analyser ces verrous. Ce chapitre se concentre sur un autre verrou de lecture-écriture important, ReentrantReadWriteLock.

ReentrantLock est un verrou exclusif, ce qui signifie qu'un seul thread peut acquérir le verrou. Mais que se passe-t-il si le scénario est que le thread n'effectue que des opérations de lecture ? De cette façon, ReentrantLock n'est pas très adapté. Le thread de lecture n'a pas besoin d'assurer la sécurité de son thread. Ce n'est qu'ainsi que les performances et l'efficacité peuvent être garanties. possible. ReentrantReadWriteLock est un tel verrou.Il est divisé en un verrou de lecture et un verrou d'écriture.N threads d'opération de lecture peuvent obtenir le verrou d'écriture, mais un seul thread d'opération d'écriture peut obtenir le verrou d'écriture. le verrou est un verrou partagé (mode partagé dans AQS) et le verrou de lecture est un verrou exclusif (mode exclusif dans AQS). Tout d'abord, regardons la classe d'interface du verrou en lecture-écriture :

public interface ReadWriteLock { 
  Lock readLock();  //获取读锁
  Lock writeLock();  //获取写锁
 }

Vous pouvez voir que l'interface ReadWriteLock ne définit que deux méthodes, la méthode d'acquisition du verrou en lecture et la méthode d'acquisition du verrou en écriture. verrouillage. Voici la classe d'implémentation de ReadWriteLock - ReentrantReadWriteLock.

Semblable à ReentrantLock, ReentrantReadWriteLock implémente également le synchroniseur AQS via une classe interne Sync. Il implémente également Sync pour implémenter des verrous équitables et injustes. Cette idée est similaire à ReentrantLock. Comment les verrous en lecture et en écriture obtenus dans l'interface ReadWriteLock sont-ils implémentés ?

//ReentrantReadWriteLock
private final ReentrantReadWriteLock.ReadLock readerLock;
private final ReentrantReadWriteLock.WriteLock writerLock;
final Sync sync;
public ReentrantReadWriteLock(){
 this(false); //默认非公平锁
}
public ReentrantReadWriteLock(boolean fair) {
 sync = fair ? new FairSync() : new NonfairSync(); //锁类型（公平/非公平）
 readerLock = new ReadLock(this); //构造读锁
 writerLock = new WriteLock(this); //构造写锁
}
……
public ReentrantReadWriteLock.WriteLock writeLock0{return writerLock;}
public ReentrantReadWriteLock.ReadLock readLock0{return ReaderLock;}

//ReentrantReadWriteLock$ReadLock
public static class ReadLock implements Lock {
 protected ReadLock(ReentrantReadwritLock lock) {
  sync = lock.sync;  //最后还是通过Sync内部类实现锁
　　}
 …… //它实现的是Lock接口，其余的实现可以和ReentrantLock作对比，获取锁、释放锁等等
}

//ReentrantReadWriteLock$WriteLock
public static class WriteLock implemnts Lock {
 protected WriteLock(ReentrantReadWriteLock lock) {
  sync = lock.sync;
　　}
…… //它实现的是Lock接口，其余的实现可以和ReentrantLock作对比，获取锁、释放锁等等
}

Ce qui précède est une introduction générale à ReentrantReadWriteLock. Vous pouvez voir qu'il contient plusieurs classes internes. Il y a deux verrous dans le verrou d'écriture - ReadLock et WriteLock. Ces deux verrous implémentent l'interface Self-Lock et peuvent être comparés à ReentrantLock. L'implémentation interne de ces deux verrous est implémentée via Sync, qui est le synchroniseur AQS. par rapport à Sync dans ReentrantLock.
En regardant AQS, il contient deux structures de données importantes - l'une est la file d'attente de synchronisation et l'autre est le statut de synchronisation . Verrouillage en lecture-écriture. C'est-à-dire l'état de lecture et d'écriture, mais il n'y a qu'un seul état entier dans AQS pour représenter l'état de synchronisation. Dans le verrouillage en lecture-écriture, il y a deux états de synchronisation de lecture et d'écriture qui doivent être enregistrés. . Par conséquent, le verrou de lecture-écriture traite l'entier d'état dans AQS. Il s'agit d'une variable int avec un total de 4 octets et 32 ​​bits. Ensuite, les états de lecture et d'écriture peuvent occuper 16 bits chacun - les 16 bits supérieurs représentent la lecture. 16 bits indiquent l'écriture.

　

Maintenant, il y a une question si la valeur de l'état est 5, le binaire est (0000000000000000000000000000101). lire et écrire ? Cela nécessite le recours à des opérations de déplacement. La méthode de calcul est la suivante : état d'écriture & 0x0000FFFF, état de lecture >>> Augmenter l'état d'écriture de 1 est égal à l'état + 1, et augmenter l'état de lecture de 1 est égal à l'état + (1 << 16). Pour l'opération de décalage bit , veuillez vous référer à "<<, >>, >>> Opération de décalage ".

Acquisition et libération des verrous en écriture

Sur la base de notre expérience précédente, nous pouvons savoir qu'AQS a déjà mis en place le squelette de l'algorithme pour l'acquisition des verrous, et n'a besoin que de être implémenté par les sous-classes tryAcquire (verrouillage exclusif), il suffit donc de vérifier tryAcquire.

//ReentrantReadWriteLock$Sync
protected final boolean tryAcquire(int acquires) {
 Thread current = Thread.currentThread;
 int c = getState(); //获取state状态
 int w = exclusiveCount(c); //获取写状态,即 state & 0x00001111
 if (c != 0) { //存在同步状态（读或写），作下一步判断
  if (w == 0 || current != getExclusiveOwnerThread())  //写状态为0，但同步状态不为0表示有读状态，此时获取锁失败，或者当前已经有其他写线程获取了锁此时也获取锁失败
   return false;
  if (w + exclusiveCount(acquire) > MAX_COUNT) //锁重入是否超过限制
   throw new Error(“Maxium lock count exceeded”)；
  setState(c + acquire); //记录锁状态
  return true;
　　}
　　if (writerShouldBlock() || !compareAndSetState(c, c + acquires))
 　　return false;  //writerShouldBlock对于非公平锁总是返回false，对于公平锁则判断同步队列中是否有前驱节点
　　setExclusiveOwnerThread(current);
　　return true;
}

Ce qui précède est l'acquisition de l'état du verrou en écriture. Ce qui est difficile à comprendre, c'est la méthodewriterShouldBlock. Cette méthode est décrite ci-dessus et renvoie directement false, tandis que pour les verrous équitables, la méthode hasQueuedPredecessors. s'appelle ainsi :

 //ReentrantReadWriteLock$FairSync
 final boolean writerShouldBlock() {
  return hasQueuedPredecessors();
 }

Quelle est la raison ? Cela revient à la différence entre les verrous injustes et les verrous équitables. Pour un aperçu bref, veuillez vous référer à « 5.Interface de verrouillage et son implémentation ReentrantLock » pour plus de détails. Pour les verrous injustes, chaque fois qu'un thread acquiert un verrou, il forcera d'abord l'opération d'acquisition du verrou, qu'il y ait ou non des threads dans la file d'attente de synchronisation. Lorsque l'acquisition ne peut pas être obtenue, le thread sera construit jusqu'à la fin de la file d'attente ; pour les verrous équitables, tant que la file d'attente de synchronisation S'il y a des threads dans la file d'attente, le verrou ne sera pas acquis, mais la structure du thread sera ajoutée à la fin de la file d'attente. Revenons donc à l'acquisition du statut d'écriture, dans la méthode tryAcquire, il a été constaté qu'aucun thread ne détient le verrou, mais à ce moment, les opérations correspondantes seront effectuées en fonction des différents verrous. Pour les verrous injustes - capture de verrou, pour les verrous équitables. - file d'attente de synchronisation Il y a des threads dans le thread, pas de capture de verrou et ajoutés à la fin de la file d'attente.

Le processus de libération du verrou en écriture est fondamentalement similaire au processus de libération de ReentrantLock. Après tout, ce sont tous des verrous exclusifs. Chaque version réduit l'état d'écriture jusqu'à ce qu'il soit réduit à 0, ce qui signifie que le verrou en écriture a. été complètement libéré.

Acquisition et libération du verrou de lecture

De même, sur la base de notre expérience précédente, nous pouvons savoir qu'AQS a déjà configuré le squelette de l'algorithme pour acquérir des verrous. Seules les sous-classes doivent implémenter tryAcquireShared (verrou partagé), il nous suffit donc de vérifier tryAcquireShared. Nous savons que pour les verrous en mode partagé, il peut être acquis par plusieurs threads en même temps. Maintenant, le problème survient. Le thread T1 acquiert le verrou, et l'état de synchronisation est state=1. À ce moment, T2 acquiert également le verrou. lock, state=2, puis l'état de réentrée du thread T1 = 3, ce qui signifie que l'état de lecture est la somme du nombre de verrous de lecture pour tous les threads, et le nombre de fois que chaque thread a acquis le verrou de lecture peut ne doit être enregistré que dans ThreadLock et maintenu par le thread lui-même, donc certaines choses doivent être faites ici Traitement complexe, le code source est un peu long, mais la complexité réside dans le fait que chaque thread enregistre le nombre de fois qu'il acquiert un. verrou de lecture.Pour plus de détails, reportez-vous à tryAcquireShared dans le code source. Lisez-le attentivement et combinez-le avec l'analyse ci-dessus de l'acquisition du verrou d'écriture.

Ce qui est remarquable à propos de la libération du verrou de lecture, c'est le nombre de fois où il maintient l'acquisition du verrou et la réduction de l'état via l'opération de décalage - (1 << 16).

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!