java - method - ReentrantReadWriteLock, ¿cuál es la diferencia entre ReadLock y WriteLock?
reentrantlock java 8 (4)
Al usar ReadWriteLock, puede mejorar el rendimiento de una aplicación en la que se realizan más lecturas en un objeto compartido que escrituras.
ReadWriteLock mantiene dos bloqueos para las operaciones de lectura y escritura. Solo un bloqueo de lectura o escritura se puede adquirir al mismo tiempo. Pero varios subprocesos pueden adquirir simultáneamente el bloqueo de lectura siempre que el bloqueo de escritura no sea adquirido por ningún subproceso.
ReentrantReadWriteLock es una implementación de ReadWriteLock. Da bloqueo de escritura al hilo de espera más largo si varios subprocesos no esperan el bloqueo de lectura. Si varios subprocesos esperan el bloqueo de lectura, se les otorga el bloqueo de lectura.
Un lector que adquirió un bloqueo de lectura puede volver a adquirir un bloqueo de lectura, de manera similar, el escritor puede volver a adquirir un bloqueo de escritura y también puede adquirir un bloqueo de lectura.
Consulte http://www.zoftino.com/java-concurrency-lock-and-condition-examples
Lo que sé es que writelock es como sincronizado.
Readlock y writelock se afectan mutuamente de alguna manera.
ReadLock parece que no puede trabajar solo.
Cuando un hilo adquiere un WriteLock , ningún otro subproceso puede adquirir ReadLock ni WriteLock de la misma instancia de ReentrantReadWriteLock , a menos que ese hilo libere el bloqueo. Sin embargo, varios subprocesos pueden adquirir ReadLock al mismo tiempo.
La documentación para ReadWriteLock lo aclara:
Un ReadWriteLock mantiene un par de bloqueos asociados, uno para operaciones de solo lectura y otro para escritura. El bloqueo de lectura puede ser mantenido simultáneamente por varios hilos de lectura, siempre que no haya escritores. El bloqueo de escritura es exclusivo.
Por lo tanto, puede tener muchos lectores a la vez, pero solo un escritor, y el escritor evitará que los lectores también lean. Esto es útil si tiene algún recurso que es seguro para leer de varios subprocesos, y donde leer es mucho más común que escribir, pero cuando el recurso no es realmente de solo lectura. (Si no hay escritores y la lectura es segura, no hay necesidad de un bloqueo).
readLock.lock();
Esto significa que si cualquier otro hilo está escribiendo (es decir, mantiene un bloqueo de escritura), deténgase aquí hasta que no se escriba ningún otro hilo.
Una vez que se concede el bloqueo, ningún otro hilo podrá escribir (es decir, tomar un bloqueo de escritura) hasta que se libere el bloqueo.
writeLock.lock();
Esto significa que si cualquier otro hilo está leyendo o escribiendo , deténgase aquí y espere hasta que ningún otro hilo esté leyendo o escribiendo.
Una vez que se otorga el bloqueo, ningún otro hilo podrá leer o escribir (es decir, tomar un bloqueo de lectura o escritura) hasta que se libere el bloqueo.
Combinando estos, puede hacer que solo un hilo a la vez tenga acceso de escritura, pero todos los lectores que desee puedan leer al mismo tiempo, excepto cuando se está escribiendo un hilo.
Dicho de otra manera. Cada vez que quiera leer desde la estructura, tome un bloqueo de lectura . Cada vez que quieras escribir , toma un bloqueo de escritura . De esta manera, cuando se produce una escritura, nadie está leyendo (se puede imaginar que tiene acceso exclusivo), pero puede haber muchos lectores leyendo al mismo tiempo, siempre y cuando nadie esté escribiendo.