Interface ReadWriteLock et son implémentation ReentrantReadWriteLock

Les verrous du package locks du package de concurrence Java ont été essentiellement introduits. ReentrantLock est la clé Après avoir clairement compris le mécanisme de fonctionnement du synchroniseur AQS, il sera en fait beaucoup plus facile d'analyser ces verrous, ce chapitre. se concentre sur un autre verrou important - le verrou en lecture-écriture 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 autant que 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 :

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

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. 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 ?

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

//ReentrantReadWriteLock$WriteLockpublic 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 son interne Il existe plusieurs classes internes. En fait, il y a deux verrous en lecture-écriture - ReadLock et WriteLock. Ces deux verrous implémentent l'interface Lock et peuvent être comparés à ReentrantLock. L'implémentation interne de ces deux verrous se fait via Sync. par le synchroniseur AQS, qui peut également être comparé à 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 l'état de synchronisation. Cet état de synchronisation est appliqué au verrou en lecture-écriture, qui est l'état de lecture-écriture. mais il n'y a qu'un seul état dans AQS Integer qui représente l'état de synchronisation. Dans le verrou 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 les opérations de changement de vitesse, veuillez vous référer à « <<, >>, >>>Opérations de changement de vitesse ».

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.

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

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. Fair Locks c'est Appelez la méthode hasQueuedPredecessors comme suit :

1 //ReentrantReadWriteLock$FairSync2 final boolean writerShouldBlock() {3     return hasQueuedPredecessors();4 }

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 des verrous de lecture

De même, 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. implémente 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 des verrous de lecture est le nombre d'acquisitions de verrous maintenu par lui-même et la réduction de l'état par le biais d'opérations 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!