Lorsqu'un mot-clé de langue Java est utilisé pour modifier une méthode ou un bloc de code, il peut s'assurer qu'au plus un thread exécute le code en même temps.
1. Lorsque deux threads simultanés accèdent à ce bloc de code synchronisé synchronisé (ce) dans le même objet d'objet, un seul thread peut être exécuté dans un temps. Un autre thread doit attendre que le thread actuel exécute ce bloc de code avant de pouvoir exécuter le bloc de code.
2. Cependant, lorsqu'un thread accède à un bloc de code de synchronisation synchronisé (this) d'un objet, un autre thread peut toujours accéder au bloc de code de synchronisation non synchronisé (this) dans cet objet.
3. Il est particulièrement essentiel que lorsqu'un thread accède à un bloc de code de synchronisation synchronisé (cette) de synchronisation d'un objet, d'autres threads bloqueront l'accès à tous les autres blocs de code de synchronisation synchronisés (this) dans l'objet.
4. Le troisième exemple s'applique également à d'autres blocs de code synchrones. Autrement dit, lorsqu'un thread accède à un bloc de code de synchronisation synchronisé (ce) synchronisation d'un objet, il obtient le verrouillage de l'objet de cet objet. En conséquence, d'autres threads accès à toutes les parties de code synchrones de l'objet objet sont temporairement bloqués.
5. Les règles ci-dessus s'appliquent également aux autres verrous d'objets.
Donnez un exemple:
1. Lorsque deux threads simultanés accèdent à ce bloc de code synchronisé synchronisé (ce) dans le même objet d'objet, un seul thread peut être exécuté dans un temps. Un autre thread doit attendre que le thread actuel exécute ce bloc de code avant de pouvoir exécuter le bloc de code.
package ths; public class thread1 implémente runnable {public void run () {synchronisé (this) {for (int i = 0; i <5; i ++) {System.out.println (thread.currentThread (). getName () + "synchronisé Loop" + i); }}} public static void main (String [] args) {Thread1 t1 = new Thread1 (); Thread ta = nouveau thread (t1, "a"); Thread tb = nouveau thread (t1, "b"); ta.start (); tb.start (); }}résultat:
Une boucle synchronisée 0
Une boucle synchronisée 1
Une boucle synchronisée 2
Une boucle synchronisée 3
Une boucle synchronisée 4
B Boucle synchronisée 0
B Boucle synchronisée 1
B Boucle synchronisée 2
B Boucle synchronisée 3
B Boucle synchronisée 4
2. Cependant, lorsqu'un thread accède à un bloc de code de synchronisation synchronisé (this) d'un objet, un autre thread peut toujours accéder au bloc de code de synchronisation non synchronisé (this) dans cet objet.
package ths; public class thread2 {public void m4t1 () {synchronisé (this) {int i = 5; while (i--> 0) {System.out.println (thread.currentThread (). getName () + ":" + i); essayez {thread.sleep (500); } catch (InterruptedException ie) {}}}} public void m4t2 () {int i = 5; while (i--> 0) {System.out.println (thread.currentThread (). getName () + ":" + i); essayez {thread.sleep (500); } catch (InterruptedException ie) {}}} public static void main (String [] args) {final Thread2 myt2 = new Thread2 (); Thread t1 = new thread (new Runnable () {public void run () {myt2.m4t1 ();}}, "t1"); Thread t2 = new thread (new Runnable () {public void run () {myt2.m4t2 ();}}, "t2"); t1.start (); t2.start (); }} résultat:
T1: 4
T2: 4
T1: 3
T2: 3
T1: 2
T2: 2
T1: 1
T2: 1
T1: 0
T2: 0
3. Il est particulièrement essentiel que lorsqu'un thread accède à un bloc de code de synchronisation synchronisé (cette) de synchronisation d'un objet, d'autres threads bloqueront l'accès à tous les autres blocs de code de synchronisation synchronisés (this) dans l'objet.
// modifier thread2.m4t2 () Méthode: public void M4T2 () {synchronisé (this) {int i = 5; while (i--> 0) {System.out.println (thread.currentThread (). getName () + ":" + i); essayez {thread.sleep (500); } catch (InterruptedException ie) {}}}}résultat:
T1: 4
T1: 3
T1: 2
T1: 1
T1: 0
T2: 4
T2: 3
T2: 2
T2: 1
T2: 0
4. Le troisième exemple s'applique également à d'autres blocs de code synchrones. Autrement dit, lorsqu'un thread accède à un bloc de code de synchronisation synchronisé (ce) synchronisation d'un objet, il obtient le verrouillage de l'objet de cet objet. En conséquence, d'autres threads accès à toutes les parties de code synchrones de l'objet objet sont temporairement bloqués.
// Modifiez la méthode thread2.m4t2 () comme suit: public synchronisé void M4T2 () {int i = 5; while (i--> 0) {System.out.println (thread.currentThread (). getName () + ":" + i); essayez {thread.sleep (500); } catch (InterruptedException ie) {}}} résultat:
T1: 4
T1: 3
T1: 2
T1: 1
T1: 0
T2: 4
T2: 3
T2: 2
T2: 1
T2: 0
5. Les règles ci-dessus s'appliquent également aux autres verrous d'objets:
package ths; public class thread3 {class inner {private void m4t1 () {int i = 5; while (i--> 0) {System.out.println (thread.currentThread (). getName () + ": inner.m4t1 () =" + i); essayez {thread.sleep (500); } catch (InterruptedException ie) {}}} private void m4t2 () {int i = 5; while (i--> 0) {System.out.println (thread.currentThread (). getName () + ": inner.m4t2 () =" + i); essayez {thread.sleep (500); } catch (InterruptedException ie) {}}}} private void m4t1 (inner inner) {synchronisé (inner) {// Utilisez le verrouillage d'objet inner.m4t1 (); } private void m4t2 (inner intérieur) {inner.m4t2 (); } public static void main (String [] args) {final thread3 myt3 = new Thread3 (); intérieur intérieur final = myt3.new inner (); Thread t1 = new thread (new Runnable () {public void run () {myt3.m4t1 (inner);}}, "t1"); Thread t2 = new thread (new Runnable () {public void run () {myt3.m4t2 (inner);}}, "t2"); t1.start (); t2.start (); }}résultat:
Bien que Thread T1 obtient un verrouillage d'objet à l'intérieur, car le thread T2 accède à la partie asynchrone dans le même interne. Par conséquent, les deux threads n'interfèrent pas entre eux.
t1: inner.m4t1 () = 4
t2: inner.m4t2 () = 4
t1: inner.m4t1 () = 3
t2: inner.m4t2 () = 3
t1: inner.m4t1 () = 2
t2: inner.m4t2 () = 2
t1: inner.m4t1 () = 1
t2: inner.m4t2 () = 1
t1: inner.m4t1 () = 0
t2: inner.m4t2 () = 0
Maintenant, mettez-vous synchronisé devant Inner.M4T2 ():
VOID privé synchronisé M4T2 () {int i = 5; while (i--> 0) {System.out.println (thread.currentThread (). getName () + ": inner.m4t2 () =" + i); essayez {thread.sleep (500); } catch (InterruptedException ie) {}}}résultat:
Bien que les threads T1 et T2 accèdent à deux parties non liées du même objet intérieur, car T1 obtient d'abord le verrouillage de l'objet à l'intérieur, l'accès de T2 à Inner.M4T2 () est également bloqué car M4T2 () est une méthode de synchronisation à l'intérieur.
t1: inner.m4t1 () = 4
t1: inner.m4t1 () = 3
t1: inner.m4t1 () = 2
t1: inner.m4t1 () = 1
t1: inner.m4t1 () = 0
t2: inner.m4t2 () = 4
t2: inner.m4t2 () = 3
t2: inner.m4t2 () = 2
t2: inner.m4t2 () = 1
t2: inner.m4t2 () = 0
Article 2:
Mot-clé synchronisé, qui comprend deux usages: la méthode synchronisée et le bloc synchronisé.
1. Méthode synchronisée: Déclarez la méthode synchronisée en ajoutant le mot-clé synchronisé à la déclaration de la méthode. comme:
public synchronisé void AccessVal (int newval);
La méthode synchronisée contrôle l'accès aux variables des membres de la classe: chaque instance de classe correspond à un verrou et chaque méthode synchronisée doit obtenir le verrouillage de l'instance de classe qui appelle la méthode avant de pouvoir être exécutée. Sinon, le fil auquel il appartient est bloqué. Une fois la méthode exécutée, elle occupera exclusivement la serrure. Le verrou ne sera pas libéré avant son retour de la méthode. Le fil bloqué peut obtenir le verrou et rentrer à l'état exécutable. Ce mécanisme garantit qu'en même temps, pour chaque instance de classe, tout au plus une de toutes les fonctions membres déclarées synchronisées se trouve dans un état exécutable (car tout le plus peut obtenir le verrou correspondant à l'instance de classe), évitant ainsi efficacement les conflits d'accès des variables des membres de la classe (tant que toutes les méthodes possibles pour accéder aux variables des membres de la classe sont déclarées synchronisées).
En Java, non seulement les instances de classe, mais chaque classe correspond également à un verrou, nous pouvons donc déclarer la fonction membre statique de la classe comme synchronisé pour contrôler son accès aux variables membre statiques de la classe.
L'inconvénient de la méthode synchronisée: déclarer une grande méthode comme synchronisée affectera grandement l'efficacité. En règle générale, si la méthode de la classe de thread est exécutée () est déclarée synchronisée, car elle fonctionne tout au long de la vie du fil, elle ne réussira jamais à aucune méthode synchronisée de cette classe. Bien sûr, nous pouvons résoudre ce problème en mettant le code qui accède aux variables des membres de la classe dans une méthode spéciale, en la déclarant synchronisée et en l'appelant dans la méthode principale, mais Java nous fournit une meilleure solution, c'est-à-dire le bloc synchronisé.
2. Bloc synchronisé: Déclarez le bloc synchronisé via le mot-clé synchronisé. La syntaxe est la suivante:
synchronisé (syncobject) {// code qui permet le contrôle d'accès} Le bloc synchronisé est un bloc de code dans lequel le code doit obtenir un verrou du Syncobject d'objet (comme mentionné précédemment, il peut être une instance de classe ou une classe) avant de pouvoir être exécuté. Le mécanisme spécifique est le même que celui décrit ci-dessus. Puisqu'il peut être ciblé sur n'importe quel bloc de code et que les objets verrouillés peuvent être spécifiés à tout moment, il est plus flexible.
Quelques compréhensions de synchronisés (ceci) <r /> 1. Lorsque deux threads simultanés accèdent à ce bloc de code synchronisé synchronisé (ce) dans le même objet, un seul thread peut être exécuté dans un temps. Un autre thread doit attendre que le thread actuel exécute ce bloc de code avant de pouvoir exécuter le bloc de code.
2. Cependant, lorsqu'un thread accède à un bloc de code de synchronisation synchronisé (this) d'un objet, un autre thread peut toujours accéder au bloc de code de synchronisation non synchronisé (this) dans cet objet.
3. Il est particulièrement essentiel que lorsqu'un thread accède à un bloc de code de synchronisation synchronisé (cette) de synchronisation d'un objet, d'autres threads bloqueront l'accès à tous les autres blocs de code de synchronisation synchronisés (this) dans l'objet.
4. Le troisième exemple s'applique également à d'autres blocs de code synchrones. Autrement dit, lorsqu'un thread accède à un bloc de code de synchronisation synchronisé (ce) synchronisation d'un objet, il obtient le verrouillage de l'objet de cet objet. En conséquence, d'autres threads accès à toutes les parties de code synchrones de l'objet objet sont temporairement bloqués.
5. Les règles ci-dessus s'appliquent également aux autres verrous d'objets.
Comment utiliser synchronisé en java
Par exemple: un objet est comme une grande maison, la porte est toujours ouverte. Il y a beaucoup de pièces dans la maison (c'est-à-dire la méthode).
Ces pièces ont verrouillé (méthode synchronisée) et ne sont pas verrouillées (méthode normale). Il y a une clé à la porte, qui peut ouvrir toutes les chambres verrouillées.
De plus, je compare tous les fils qui souhaitent appeler la méthode de l'objet aux personnes qui souhaitent entrer dans une pièce de cette maison. Il n'y a que tellement de choses, voyons comment ces choses fonctionnent.
Ici, nous clarifions d'abord nos conditions préalables. L'objet a au moins une méthode synchronisée, sinon quel est le point de cette clé? Bien sûr, il n'y aura pas un tel sujet pour nous.
Un homme voulait entrer dans une pièce verrouillée. Il est venu à la porte de la maison et a vu la clé là-bas (cela signifie que personne d'autre ne veut encore utiliser la salle verrouillée). Alors il s'est approché et a obtenu les clés et a utilisé les chambres comme il l'a prévu. Sachez qu'il renverra la clé immédiatement après avoir utilisé la salle verrouillée à chaque fois. Même s'il veut utiliser deux chambres verrouillées d'affilée, il retournera les clés pour les récupérer. Par conséquent, le principe d'utilisation d'une clé dans les cas ordinaires est: "Emprunter comme vous utilisez et le retourner dès que vous l'utilisez."
À l'heure actuelle, d'autres personnes peuvent utiliser ces chambres déverrouillées sans restrictions. Une personne peut utiliser une pièce et deux personnes peuvent utiliser une pièce, sans restrictions. Mais si quelqu'un veut entrer dans une pièce verrouillée, il doit courir à la porte pour jeter un œil. Bien sûr, si vous avez la clé, vous partirez. Si vous ne l’avez pas, vous ne pouvez attendre que. Si beaucoup de gens attendent cette clé, qui obtiendra la clé en premier après son retour? Pas garanti. Comme le gars dans l'exemple précédent qui voulait utiliser deux salles verrouillées d'affilée, s'il y avait d'autres personnes qui attendaient les clés au milieu, il n'y avait aucune garantie que ce gars le récupérerait. (La spécification Java indique clairement qu'elle n'est pas garantie dans de nombreux endroits, comme le temps qu'il faut pour que Thread.Sleep () revienne à l'exécution après le repos, le fil avec la même priorité est exécuté en premier, et quel thread dans le pool d'attente sera donné la priorité après le verrou pour accéder à l'objet, etc. Je pense que la décision finale est dans la décision ci-dessus. Une condition, mais basée sur de nombreux articles.
Parce qu'il y a trop de conditions de jugement, si vous le dites, cela peut affecter la promotion de Java, ou cela peut être dû à la protection de la propriété intellectuelle. Sun m'a donné une promesse et l'a traversée. Il n'y a rien de mal à cela. Mais je crois que ces incertitudes ne sont pas entièrement incertaines. Parce que l'ordinateur lui-même s'exécute en fonction des instructions. Même si le phénomène semble aléatoire, il est en fait régulier. Quiconque a étudié les ordinateurs sait que le nom scientifique des nombres aléatoires dans les ordinateurs est des nombres pseudo-aléatoires, qui sont écrits par des personnes utilisant certaines méthodes, et ils semblent simplement aléatoires. De plus, c'est peut-être parce qu'il est trop difficile de s'assurer et pas très significatif, donc si vous n'êtes pas sûr, vous n'êtes pas sûr. )
Jetons un coup d'œil au bloc de code de synchronisation. Il y a une légère différence par rapport à la méthode de synchronisation.
1. En termes de taille, le bloc de code de synchronisation est plus petit que la méthode de synchronisation. Vous pouvez considérer le bloc de code de synchronisation comme un espace dans une pièce déverrouillée séparée par un écran verrouillé.
2. Le bloc de code de synchronisation peut également spécifier artificiellement la clé de l'obtention d'un certain autre objet. Tout comme spécifiant la clé pour déverrouiller l'écran, vous pouvez utiliser la clé de cette pièce; Vous pouvez également spécifier que la clé d'une autre maison peut l'ouvrir. De cette façon, vous devez courir dans une autre maison pour apporter cette clé et utiliser la clé de cette maison pour ouvrir l'écran verrouillé de cette maison.
N'oubliez pas que la clé de cette autre maison que vous avez obtenue n'affecte pas les autres personnes entrant dans la pièce sans verrouillage dans cette maison.
Pourquoi utiliser des blocs de code synchrones? Je pense que cela devrait être comme ceci: tout d'abord, la partie de synchronisation du programme a beaucoup d'impact sur l'efficacité de l'opération, et une méthode consiste généralement à créer des variables locales d'abord, puis à faire des opérations sur ces variables, telles que les opérations, l'affichage, etc. Et plus il y a de code couvert par la synchronisation, plus l'impact sur l'efficacité est grave. Par conséquent, nous essayons généralement de réduire son impact.
Comment faire? Synchroniser les blocs de code. Nous synchronisons uniquement les lieux de synchronisation dans une méthode, tels que les opérations.
De plus, la fonctionnalité des blocs de code synchrones qui peuvent spécifier les touches a un avantage supplémentaire, à savoir qu'il peut occuper les clés d'un objet dans un certain délai. Vous souvenez-vous des principes d'utilisation des clés dans des situations ordinaires mentionnées précédemment? Ce n'est pas la situation ordinaire maintenant. La clé que vous avez obtenue n'est pas renvoyée, mais n'est renvoyée que lorsque vous quittez le bloc de code synchrone.
J'ai également utilisé le gars à l'avant qui voulait utiliser deux chambres verrouillées d'affilée pour faire un exemple. Comment puis-je continuer à en utiliser un autre après l'avoir utilisé? Utilisez des blocs de code synchrone. Créez d'abord un autre thread, créez un bloc de code synchrone et pointez le verrou de ce bloc de code sur la clé de la maison. Puis démarrez ce fil. Tant que vous pouvez saisir la clé de la maison lors de la saisie de ce bloc de code, vous pouvez le garder jusqu'à ce que vous quittez ce bloc de code. En d'autres termes, vous pouvez même traverser toutes les chambres verrouillées de cette pièce, ou même dormir (10 * 60 * 1000), et il y a encore 1 000 fils en attente de cette clé à la porte. Très agréable.
Ici, nous parlerons de la corrélation entre la méthode Sleep () et la clé. Si un fil est obligé de dormir () après avoir obtenu la clé et n'a pas terminé le contenu synchrone, la clé est toujours là. La clé ne sera pas renvoyée avant son exécution et termine tout le contenu synchrone. Rappelez-vous, ce type était juste fatigué de travailler, alors il est allé faire une pause, et il n'a pas fini ce qu'il allait faire. Afin d'éviter que les autres entrent dans la pièce et faisaient un gâchis, il doit porter la seule clé de son corps même lorsqu'il dort.
Enfin, certaines personnes peuvent demander, pourquoi avez-vous besoin d'une clé pour ouvrir au lieu d'une clé et d'une porte? Je pense que c'est purement à cause de la complexité. Bien sûr, une clé et une porte sont plus sûres, mais cela impliquera de nombreux problèmes. La génération, le stockage, l'acquisition, le retour, etc. des clés. Sa complexité peut augmenter des séquences géométriques avec l'augmentation de la méthode de synchronisation, qui affecte sérieusement l'efficacité. Il s'agit également d'un compromis. À quel point est indésirable d'augmenter un peu la sécurité, entraînant une réduction significative de l'efficacité.
Un exemple simple de synchronisé
classe publique textThread {public static void main (string [] args) {txtthread tt = new txtthread (); nouveau thread (tt) .start (); nouveau thread (tt) .start (); nouveau thread (tt) .start (); nouveau thread (tt) .start (); }} class txtthread implémente runnable {int num = 100; String str = new String (); public void run () {synchronisé (str) {while (num> 0) {try {thread.sleep (1); } catch (exception e) {e.getMessage (); } System.out.println (thread.currentThread (). GetName () + "This is" + num--); }}}}Dans l'exemple ci-dessus, afin de créer un décalage horaire, c'est-à-dire l'opportunité de faire une erreur, Thread.Sleep (10) est utilisé.
Le mécanisme de support et de synchronisation de Java pour le multithreading est très populaire. Il semble que l'utilisation du mot-clé synchronisé peut facilement résoudre le problème de la synchronisation des données partagées multithread. Quoi exactement? Il est également nécessaire d'avoir une compréhension approfondie du rôle des mots clés synchronisés avant de pouvoir conclure.
En général, le mot-clé synchronisé peut être utilisé comme modificateur de la fonction ou comme instruction dans la fonction, qui est la méthode de synchronisation et le bloc d'instruction de synchronisation qui sont généralement mentionnés. Si vous le classez plus attentivement, Synchronisé peut agir sur les variables d'instance, les références d'objets, les fonctions statiques et les littéraux de classe (noms de classe CONSTANTS LITÉRIELS).
Avant d'élaborer davantage, nous devons clarifier quelques points:
A. Que le mot-clé synchronisé soit ajouté à une méthode ou à un objet, le verrouillage qu'il acquiert est un objet, plutôt que de traiter un morceau de code ou de fonction comme un verrou, et la méthode de synchronisation est probablement encore plus susceptible d'être
Accès d'objet à son fil.
B. Chaque objet n'a qu'une seule serrure qui lui est associée.
C. La mise en œuvre de la synchronisation nécessite beaucoup de frais généraux du système comme coût et peut même provoquer des blocs de blocage, alors essayez d'éviter le contrôle de synchronisation inutile.
Ensuite, discutons de l'impact du synchronisé à l'aide de différents endroits sur le code:
En supposant que P1 et P2 sont différents objets de la même classe, cette classe définit les blocs de synchronisation ou les méthodes de synchronisation dans les situations suivantes, et P1 et P2 peuvent les appeler.
1. Lorsque la synchronisation est utilisée comme modificateur de fonction, l'exemple de code est le suivant:
Public synchronisé void methodaaa () {//…}Il s'agit de la méthode de synchronisation. Alors, quel objet est synchronisé verrouillé à ce moment? Ce qu'il verrouille, c'est appeler cet objet de méthode synchrone. C'est-à-dire que lorsqu'un objet P1 exécute cette méthode de synchronisation dans différents threads, une exclusion mutuelle sera formée entre elles pour obtenir l'effet de la synchronisation. Cependant, un autre objet P2 généré par la classe à laquelle appartient cet objet peut appeler arbitrairement cette méthode avec le mot-clé synchronisé ajouté.
L'exemple de code ci-dessus équivaut au code suivant:
public void methodaaa () {synchronisé (this) // (1) {//… ..}}(1) Qu'est-ce que cela signifie au point? Il fait référence à l'objet qui appelle cette méthode, comme P1. On peut voir que la méthode de synchronisation est essentiellement pour s'appliquer synchronisée à la référence de l'objet. Seul le thread qui a obtenu le verrouillage de l'objet P1 peut appeler la méthode de synchronisation P1. Pour P2, la serrure P1 n'a rien à voir avec cela. Le programme peut également se débarrasser du contrôle du mécanisme de synchronisation dans cette situation, provoquant la confusion des données: (
2. Synchroniser les blocs, l'exemple de code est le suivant:
Méthode publique de void3 (SomeObject SO) {synchronisé (so) {//… ..}}À l'heure actuelle, la serrure est l'objet de SO. Celui qui obtient le verrou peut exécuter le code qu'il contrôle. Lorsqu'il y a un objet clair comme verrouillage, vous pouvez écrire le programme comme celui-ci, mais lorsqu'il n'y a pas d'objet clair comme verrou et vous voulez simplement une pièce de code à synchroniser, vous pouvez créer une variable d'instance spéciale (elle doit être un objet) pour agir comme un verrou:
Class Foo implémente Runnable {private byte [] lock = new octet [0]; // Instance spéciale variable public void methoda () {synchronisé (lock) {//…}} //… ..}Remarque: les objets du tableau d'octets de longueur zéro sont plus économiques que n'importe quel objet pour créer un code d'octet compilé: seuls 3 opcodes sont nécessaires pour générer un objet d'octet de longueur zéro, tandis que l'objet Lock = New Object () nécessite 7 opcodes.
3. Utilisez la fonction synchronisée à la fonction statique, l'exemple de code est le suivant:
Classe foo {public synchronisé statique void méthodaaa () // fonction statique synchronisée {//…. } public void methodbbb () {synchronisé (foo.class) // class littéral (nom de classe constant littéral)}}La méthode méthodebbb () dans le code utilise la classe littérale comme verrouillage. Il a le même effet que la fonction statique synchronisée. La serrure obtenue est très spéciale. Il s'agit de la classe à laquelle appartient l'objet actuellement appelé cette méthode (classe, pas un objet spécifique généré par cette classe).
Je me souviens que dans le livre "Effective Java", j'ai vu que l'utilisation de foo.class et p1.getClass () comme verrous synchrones est différent, et p1.getClass () ne peut pas être utilisé pour atteindre le but de verrouiller cette classe. P1 fait référence à un objet généré par la classe FOO.
On peut en déduire que si une classe définit une fonction statique synchronisée A et une fonction d'instance synchronisée B, le même objet Obj de cette classe ne constituera pas une synchronisation lors de l'accès à deux méthodes A et B dans plusieurs threads, car leurs verrous sont différents. Le verrouillage de la méthode A est l'objet obj, tandis que le verrou de B est la classe à laquelle appartient OBJ.
Le résumé est le suivant:
Découvrir quels verrous synchronisés d'objets peuvent nous aider à concevoir des programmes multithreads plus sûrs. Il existe également quelques conseils pour rendre l'accès synchrone aux ressources partagées plus sécurisée:
1. Définissez la variable d'instance de privé + sa méthode GET, au lieu de la variable d'instance de public / protégé. Si une variable est définie comme publique, l'objet peut contourner le contrôle de la méthode de synchronisation et l'obtenir directement et le modifier. Il s'agit également de l'une des méthodes de mise en œuvre standard de Javabean.
2. Si la variable d'instance est un objet, tel qu'un tableau ou une liste Array, la méthode ci-dessus est toujours dangereuse, car lorsqu'un objet externe obtient la référence à l'objet d'instance via la méthode GET et le pointe vers un autre objet, alors la variable privée changera, ce qui n'est pas très dangereux. À l'heure
Ce qui précède est tout le contenu de cet article. J'espère que cela sera utile à l'apprentissage de tous et j'espère que tout le monde soutiendra davantage Wulin.com.