Voulez-vous dire Synchronisé par Atomic ? Mon opinion personnelle est :
Synchronized est entré dans le standard Java avant ReentrantLock, donc tout le monde l'a utilisé au début. C'est l'équivalent de Java fournissant un mécanisme de verrouillage mutex encapsulé. Pour les utilisateurs, le déclarer comme synchronisé peut obtenir la capacité de verrouillage, quelle que soit la manière dont le verrou est déverrouillé
.
Facile à utiliser, c'est également une arme à double tranchant. Synchronisé a une granularité plus grossière et une mauvaise contrôlabilité. Par exemple, vous ne pouvez pas interrompre un thread qui attend d'obtenir un verrou, ni obtenir un verrou en votant, etc. De nombreux scénarios ne peuvent pas être résolus avec un verrou mutex.
Java a donc développé une interface java.util.concurrent.locks.Lock et implémenté différents types de verrous. Son but est de s'adapter aux exigences de verrouillage dans divers scénarios, ReenTrantLock en fait partie. .
ReenTrantLock est également un verrou mutex, mais il est plus petit que Synchronized
Fournit plus de fonctions, telles que tryLock, retour immédiat si le verrou ne peut pas être obtenu, etc.
Plus évolutif. L'évolutivité signifie que vous pouvez consacrer moins de temps à la planification en cas de conflit de verrouillage, améliorer le débit et utiliser le processeur plus efficacement
Il est hautement programmable. C'est un objet de verrouillage qui peut être transmis dans le code, ce qui est plus flexible
Cependant, ReenTrantLock n'est certainement pas aussi pratique à utiliser que Synchronisé. Il doit être déverrouillé explicitement, et ce sera gênant si vous l'oubliez
Atomic signifie AtomicInteger, n'est-ce pas ? Cela peut garantir que des fonctions telles que i++ peuvent être implémentées sous multi-threading. Cela devrait être le plus utilisé, car le type int traditionnel i++ n'est pas une opération atomique.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Voulez-vous dire Synchronisé par Atomic ? Mon opinion personnelle est :
Synchronized est entré dans le standard Java avant ReentrantLock, donc tout le monde l'a utilisé au début. C'est l'équivalent de Java fournissant un mécanisme de verrouillage mutex encapsulé. Pour les utilisateurs, le déclarer comme synchronisé peut obtenir la capacité de verrouillage, quelle que soit la manière dont le verrou est déverrouillé
Facile à utiliser, c'est également une arme à double tranchant. Synchronisé a une granularité plus grossière et une mauvaise contrôlabilité. Par exemple, vous ne pouvez pas interrompre un thread qui attend d'obtenir un verrou, ni obtenir un verrou en votant, etc. De nombreux scénarios ne peuvent pas être résolus avec un verrou mutex.
Java a donc développé une interface java.util.concurrent.locks.Lock et implémenté différents types de verrous. Son but est de s'adapter aux exigences de verrouillage dans divers scénarios, ReenTrantLock en fait partie. .
ReenTrantLock est également un verrou mutex, mais il est plus petit que Synchronized
Fournit plus de fonctions, telles que tryLock, retour immédiat si le verrou ne peut pas être obtenu, etc.
Plus évolutif. L'évolutivité signifie que vous pouvez consacrer moins de temps à la planification en cas de conflit de verrouillage, améliorer le débit et utiliser le processeur plus efficacement
Il est hautement programmable. C'est un objet de verrouillage qui peut être transmis dans le code, ce qui est plus flexible
Cependant, ReenTrantLock n'est certainement pas aussi pratique à utiliser que Synchronisé. Il doit être déverrouillé explicitement, et ce sera gênant si vous l'oubliez
AtomicsignifieAtomicInteger, n'est-ce pas ? Cela peut garantir que des fonctions telles quei++peuvent être implémentées sous multi-threading. Cela devrait être le plus utilisé, car le typeinttraditionneli++n'est pas une opération atomique.