


Explication détaillée de l'utilisation de synchronisé pour implémenter un code de verrouillage
Cet article présente comment utiliser synchronisé pour implémenter un code de verrouillage. Ce qui suit est un cas pratique. Les amis dans le besoin peuvent s'y référer.
Méthode 1 :
public synchronized void a(){ //TODO }
Méthode 2 :
public void b(){ synchronized(this){ //TODO } }
D'ici Dans les deux cas, le verrou est ajouté entre {}. Voyons comment le verrouillage est effectué :
public void c() { lock.lock(); try { // TODO } finally { lock.unlock(); } }
De cette façon, le verrou est ajouté entre lock(). et unlock(), donc si vous souhaitez implémenter une fonction de verrouillage, vous devez réfléchir à la façon d'implémenter ces deux méthodes, les méthodes lock() et unlock(). Définissez d'abord un frameworkComme indiqué ci-dessous :
public void lock(){ } public void unlock(){ }
Ensuite, vous souhaitez utiliser synchronisé pour implémenter ces deux méthodes.
Maintenant, j'ai en fait une idée un peu plus claire, mais je ne sais toujours pas comment remplir ces deux méthodes. J'analyserai les caractéristiques de Lock plus tard et jetterai un œil à ce code :
public void c() { lock.lock(); //When current thread get the lock, other thread has to wait try { //current thread get in the lock, other thread can not get in // TODO } finally { lock.unlock(); //current thread release the lock } }
Je viens d'ajouter un petit commentaire à ce code et je n'ai rien fait d'autre. Cela aide-t-il à comprendre ce code ? mot fréquent ? Il s'agit de currentthread. Alors, lorsque nous remplissons les méthodes lock() et unlock(), devons-nous faire attention au mot-clé currentthread pour trouver la solution ? La réponse est oui.
Ensuite, analysez, comment faire attendre le fil lors d'une utilisation synchronisée ? Utilisez la méthode wait(). Comment réveiller le thread ? Utilisez la méthode notify(). Utilisez ensuite la méthode wait() dans la méthode lock() et la méthode notify() dans la méthode unlock(). Il y a donc une condition lorsque nous utilisons wait() et notify(). Pensez à ce que nous devrions utiliser comme condition ?
Nous devrions utiliser si le verrou actuel est occupé comme condition de jugement. Si le verrou est occupé, currentthread attend. Demandez-vous si nous avons toujours utilisé cette condition lors de l'utilisation de synchronisé, la réponse est oui.
Analysons quand libérer le verrou et quelles conditions sont utilisées. Pensez-y. Si le thread A obtient le verrou, le thread B peut-il le libérer ? Bien sûr que non. Si B pouvait être libéré, cela violerait le principe. Il faut que le verrou du thread A ne puisse être libéré que par le thread A. La condition de jugement est donc de juger si le thread qui détient le verrou est le thread actuel. Si c'est le cas, il peut être libéré. Sinon, bien sûr, il ne peut pas.
Jetons maintenant un œil au code complet :
package test.lock; import java.util.Random; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.ThreadFactory; public class NaiveLock { private static final long NONE = -1; private long owner = NONE; private Boolean isLooked() { return owner != NONE; } public synchronized void lock() { long currentThreadId = Thread.currentThread().getId(); if (owner == currentThreadId) { throw new IllegalStateException("Lock has been acquired by current thread"); } while (this.isLooked()) { System.out.println(String.format("thread %s is waitting lock", currentThreadId)); try { wait(); } catch (InterruptedException e) { e.printStackTrace(); } } owner = currentThreadId; System.out.println(String.format("Lock is acquired by thread %s", owner)); } public synchronized void unlock() { if (!this.isLooked() || owner != Thread.currentThread().getId()) { throw new IllegalStateException("Only Lock owner can unlock the lock"); } System.out.println(String.format("thread %s is unlocking", owner)); System.out.println(); owner = NONE; notify(); } public static void main(String[] args) { final NaiveLock lock = new NaiveLock(); ExecutorService executor = Executors.newFixedThreadPool(20, new ThreadFactory() { private ThreadGroup group = new ThreadGroup("test thread group"); { group.setDaemon(true); } @Override public Thread newThread(Runnable r) { return new Thread(group, r); } } ); for (int i = 0; i < 20; i++) { executor.submit(new Runnable() { @Override public void run() { lock.lock(); System.out.println(String.format("thread %s is running...", Thread.currentThread().getId())); try { Thread.sleep(new Random().nextint(1000)); } catch (InterruptedException e) { e.printStackTrace(); } lock.unlock(); } } ); } } }
Exécutez-le et voyez le résultat :
Lock is acquired by thread 8 thread 8 is running... thread 27 is waitting lock thread 26 is waitting lock thread 25 is waitting lock thread 24 is waitting lock thread 23 is waitting lock thread 22 is waitting lock thread 21 is waitting lock thread 20 is waitting lock thread 19 is waitting lock thread 18 is waitting lock thread 17 is waitting lock thread 16 is waitting lock thread 15 is waitting lock thread 14 is waitting lock thread 13 is waitting lock thread 12 is waitting lock thread 11 is waitting lock thread 10 is waitting lock thread 9 is waitting lock thread 8 is unlocking Lock is acquired by thread 27 thread 27 is running... thread 27 is unlocking Lock is acquired by thread 26 thread 26 is running... thread 26 is unlocking Lock is acquired by thread 25 thread 25 is running... thread 25 is unlocking Lock is acquired by thread 24 thread 24 is running... thread 24 is unlocking Lock is acquired by thread 23 thread 23 is running... thread 23 is unlocking Lock is acquired by thread 22 thread 22 is running... thread 22 is unlocking Lock is acquired by thread 21 thread 21 is running... thread 21 is unlocking Lock is acquired by thread 20 thread 20 is running... thread 20 is unlocking Lock is acquired by thread 19 thread 19 is running... thread 19 is unlocking Lock is acquired by thread 18 thread 18 is running... thread 18 is unlocking Lock is acquired by thread 17 thread 17 is running... thread 17 is unlocking Lock is acquired by thread 16 thread 16 is running... thread 16 is unlocking Lock is acquired by thread 15 thread 15 is running... thread 15 is unlocking Lock is acquired by thread 14 thread 14 is running... thread 14 is unlocking Lock is acquired by thread 13 thread 13 is running... thread 13 is unlocking Lock is acquired by thread 12 thread 12 is running... thread 12 is unlocking Lock is acquired by thread 11 thread 11 is running... thread 11 is unlocking Lock is acquired by thread 10 thread 10 is running... thread 10 is unlocking Lock is acquired by thread 9 thread 9 is running... thread 9 is unlocking
Si vous modifiez la boucle for à 30 fois, regardez à nouveau le résultat :
Lock is acquired by thread 8 thread 8 is running... thread 27 is waitting lock thread 26 is waitting lock thread 25 is waitting lock thread 24 is waitting lock thread 23 is waitting lock thread 22 is waitting lock thread 21 is waitting lock thread 20 is waitting lock thread 19 is waitting lock thread 18 is waitting lock thread 17 is waitting lock thread 16 is waitting lock thread 15 is waitting lock thread 14 is waitting lock thread 13 is waitting lock thread 12 is waitting lock thread 11 is waitting lock thread 10 is waitting lock thread 9 is waitting lock thread 8 is unlocking Lock is acquired by thread 27 thread 27 is running... thread 8 is waitting lock thread 27 is unlocking Lock is acquired by thread 27 thread 27 is running... thread 26 is waitting lock thread 27 is unlocking Lock is acquired by thread 27 thread 27 is running... thread 25 is waitting lock thread 27 is unlocking Lock is acquired by thread 24 thread 24 is running... thread 27 is waitting lock thread 24 is unlocking Lock is acquired by thread 23 thread 23 is running... thread 24 is waitting lock thread 23 is unlocking Lock is acquired by thread 22 thread 22 is running... thread 23 is waitting lock thread 22 is unlocking Lock is acquired by thread 22 thread 22 is running... thread 21 is waitting lock thread 22 is unlocking Lock is acquired by thread 22 thread 22 is running... thread 20 is waitting lock thread 22 is unlocking Lock is acquired by thread 22 thread 22 is running... thread 19 is waitting lock thread 22 is unlocking Lock is acquired by thread 22 thread 22 is running... thread 18 is waitting lock thread 22 is unlocking Lock is acquired by thread 17 thread 17 is running... thread 17 is unlocking Lock is acquired by thread 16 thread 16 is running... thread 16 is unlocking Lock is acquired by thread 15 thread 15 is running... thread 15 is unlocking Lock is acquired by thread 14 thread 14 is running... thread 14 is unlocking Lock is acquired by thread 13 thread 13 is running... thread 13 is unlocking Lock is acquired by thread 12 thread 12 is running... thread 12 is unlocking Lock is acquired by thread 11 thread 11 is running... thread 11 is unlocking Lock is acquired by thread 10 thread 10 is running... thread 10 is unlocking Lock is acquired by thread 9 thread 9 is running... thread 9 is unlocking Lock is acquired by thread 8 thread 8 is running... thread 8 is unlocking Lock is acquired by thread 26 thread 26 is running... thread 26 is unlocking Lock is acquired by thread 25 thread 25 is running... thread 25 is unlocking Lock is acquired by thread 27 thread 27 is running... thread 27 is unlocking Lock is acquired by thread 24 thread 24 is running... thread 24 is unlocking Lock is acquired by thread 23 thread 23 is running... thread 23 is unlocking Lock is acquired by thread 21 thread 21 is running... thread 21 is unlocking Lock is acquired by thread 20 thread 20 is running... thread 20 is unlocking Lock is acquired by thread 19 thread 19 is running... thread 19 is unlocking Lock is acquired by thread 18 thread 18 is running... thread 18 is unlocking
Je pense que vous maîtrisez les méthodes après avoir lu ces cas. Pour des informations plus intéressantes, veuillez prêter attention aux autres articles connexes sur le site Web chinois de php !
Lecture connexe :
Le tutoriel d'algorithme de correspondance de chaînes le plus simple en php
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!

Outils d'IA chauds

Undresser.AI Undress
Application basée sur l'IA pour créer des photos de nu réalistes

AI Clothes Remover
Outil d'IA en ligne pour supprimer les vêtements des photos.

Undress AI Tool
Images de déshabillage gratuites

Clothoff.io
Dissolvant de vêtements AI

AI Hentai Generator
Générez AI Hentai gratuitement.

Article chaud

Outils chauds

Bloc-notes++7.3.1
Éditeur de code facile à utiliser et gratuit

SublimeText3 version chinoise
Version chinoise, très simple à utiliser

Envoyer Studio 13.0.1
Puissant environnement de développement intégré PHP

Dreamweaver CS6
Outils de développement Web visuel

SublimeText3 version Mac
Logiciel d'édition de code au niveau de Dieu (SublimeText3)

Après Jdk1.5, sous le package java.util.concurrent.locks, il existe un ensemble d'interfaces et de classes qui implémentent la synchronisation des threads. En matière de synchronisation des threads, tout le monde peut penser au mot-clé synchronisé, qui est un mot-clé intégré. mot-clé en Java. Il gère la synchronisation des threads, mais ce mot-clé présente de nombreux défauts et n'est pas très pratique et intuitif à utiliser, donc Lock apparaît ci-dessous, nous allons comparer et expliquer Lock. Habituellement, lorsque nous utilisons le mot-clé synchronisé, nous rencontrerons les problèmes suivants : (1) Incontrôlabilité, impossible de verrouiller et de déverrouiller les verrous à volonté. (2) L'efficacité est relativement faible. Par exemple, nous lisons actuellement deux fichiers simultanément.

1. Fonctionnalités de base 1. Cela commence par un verrou optimiste, et si les conflits de verrouillage sont fréquents, il est converti en verrou pessimiste. 2. Cela commence par une implémentation de verrouillage légère, et si le verrou est maintenu pendant une longue période, il est activé. est converti en un verrou lourd. 3. La stratégie de verrouillage tournant qui est la plus probablement utilisée lors de l'implémentation de verrous légers 4. C'est un verrou injuste 5. C'est un verrou réentrant 6. Ce n'est pas un verrou en lecture-écriture 2. La JVM synchronisera le processus de verrouillage. Les verrous sont divisés en états sans verrouillage, verrouillage biaisé, verrouillage léger et verrouillage lourd. Il sera mis à niveau séquentiellement en fonction de la situation. Le verrouillage biaisé suppose que le protagoniste masculin est un verrou et que le protagoniste féminin est un fil. Si seulement ce fil utilise ce verrou, alors le protagoniste masculin et le protagoniste féminin peuvent vivre heureux pour toujours même s'ils n'obtiennent pas d'acte de mariage (en évitant les hauts). (opérations de coûts). Mais le second rôle féminin apparaît.

1. Fonction (1) La méthode Lock pour acquérir des verrous prend en charge l'interruption, aucune acquisition après un délai d'attente et n'est pas bloquante (2) Elle améliore la sémantique. L'endroit où verrouiller et déverrouiller doit être écrit (3) Le verrouillage explicite du verrou peut nous apporter. Livré avec une bonne flexibilité, mais en même temps, nous devons libérer manuellement le verrou (4) Objet de condition de condition de support (5) Autoriser plusieurs threads de lecture à accéder aux ressources partagées en même temps 2. Utilisation du verrouillage //Obtenir le verrou voidlock() //Si le thread actuel n'a pas été interrompu, acquérir le verrou voidlockInterruptably()//Renvoyer une nouvelle instance de Condition liée à cette instance de Lock ConditionnewCondition()//Lock uniquement lorsqu'il est appelé

Remarque 1. Lock est une interface du package java.util.concurent, qui définit une série de méthodes d'opération de verrouillage. 2. L'interface Lock comprend principalement les classes d'implémentation ReentrantLock, ReentrantReadWriteLock, ReentrantReadWriteLock et WriteLock. Différent de Synchronized, Lock fournit des interfaces associées telles que l'acquisition et la libération de verrous, ce qui le rend plus flexible à utiliser et plus complexe à utiliser. InstanceReentrantReadWriteLocklock=newReentrantReadWriteLock();Lockread

1. Le concept de verrou dans Java Spin lock : Lorsqu'un thread acquiert un verrou, si le verrou a été acquis par un autre thread, alors le thread attendra en boucle, puis continuera à juger si le verrou peut être acquis avec succès jusqu'à ce que il est acquis. Le verrou sortira de la boucle. Verrouillage optimiste : en supposant qu'il n'y ait pas de conflit, si les données s'avèrent incohérentes avec les données précédemment acquises lors de la modification des données, les dernières données seront lues et la modification sera réessayée. Verrouillage pessimiste : supposez que des conflits de concurrence se produiront, synchroniserez toutes les opérations liées aux données et commencerez le verrouillage à partir du moment où les données sont lues. Verrou exclusif (écriture) : ajoutez un verrou en écriture à la ressource. Le thread peut modifier la ressource, mais les autres threads ne peuvent pas la verrouiller à nouveau (écriture unique). Verrou partagé (lecture) : après avoir ajouté un verrou en lecture à une ressource, celui-ci peut uniquement être lu mais pas modifié. Les autres threads ne peuvent ajouter que des verrous en lecture et ne peuvent pas ajouter de verrous en écriture (plusieurs). Voir comme S

Résumé de l'utilisation de synchronisé en Java 1. Lorsque synchronisé est utilisé comme modificateur de fonction, l'exemple de code est le suivant : Publicsynchronizedvoidmethod(){//….} Il s'agit de la méthode de synchronisation. Alors, quel objet est synchronisé verrouillé à ce moment ? Ce qu'il verrouille appelle cet objet méthode synchronisée. En d'autres termes, lorsqu'un objet P1 exécute cette méthode de synchronisation dans différents threads, ils formeront une exclusion mutuelle pour obtenir un effet de synchronisation. Cependant, un autre objet P2 généré par la Classe à laquelle appartient cet objet peut arbitrairement appeler cette méthode en ajoutant le mot-clé synchronisé. L'exemple de code ci-dessus, etc.

1. Expliquez que synchronisé est notre méthode de synchronisation la plus couramment utilisée et qu'il existe trois manières principales de l'utiliser. 2. Exemple//Synchronisation de méthode de classe générale synchroniséepublidvoidinvoke(){}//Synchronisation de méthode statique de classe synchroniséepublicstaticvoidinvoke(){}//Synchronisation de bloc de code synchronisé(objet){}La différence entre ces trois méthodes est que les objets synchronisés sont différents. Les classes ordinaires synchronisent l'objet lui-même, les méthodes statiques synchronisent la classe elle-même et les blocs de code synchronisent les objets que nous remplissons entre parenthèses. Quelles collections existe-t-il en Java ?

Préparation des outils Avant de parler formellement du principe de la synchronisation, parlons d'abord des verrous de rotation, car les verrous de rotation jouent un rôle important dans l'optimisation de la synchronisation. Pour comprendre les verrous de rotation, nous devons d’abord comprendre ce qu’est l’atomicité. Ce qu'on appelle l'atomicité signifie simplement que chaque opération n'est pas effectuée ou que tout faire signifie qu'elle ne peut pas être interrompue pendant l'opération. Par exemple, pour en ajouter une aux données variables, il y a les trois étapes suivantes : ajouter des données Charger. de la mémoire dans le registre. Ajoutez-en un à la valeur des données. Écrivez le résultat en mémoire. L'atomicité signifie que lorsqu'un thread effectue une opération d'incrémentation, il ne peut pas être interrompu par d'autres threads uniquement lorsque ce thread termine ces trois processus.
