Que signifie réellement le verrouillage intrinsèque pour une classe Java?

Il semble que vous ayez un malentendu (je ne sais pas si cela a causé la mauvaise conclusion) que personne n'a souligné. Quoi qu'il en soit, une brève réponse:

Verrou intrinsèque: Il suffit de penser comme, chaque objet dans JVM a en interne un verrou. synchronized mots clés essaie d'acquérir le verrou de l'objet cible. Chaque fois que vous synchronized (a) { doSomething; }, ce qui se passe réellement est

1. la serrure dans a est acquis
2. le code dans le bloc synchronisé est exécuté (doSomething)
3. relâchez le verrou a

Et je souhaite que vous sachiez

public synchronized void foo() {
  doSomething;
}

Est conceptuellement le même que

public void foo() {
    synchronized(this) {
        doSomething;
    }
}

Ok, revenez à votre question, le plus gros problème, à mon humble avis, est:

Pour moi, cela signifie qu'une fois que j'appelle une méthode synchronisée à partir de l'un des threads, j'aurai le verrou intrinsèque du thread et depuis...

, Il est mal. Lorsque vous appelez une méthode synchronisée, vous êtes pas mettre la main sur le verrou du fil .

Au lieu de cela, ce threadpossédera le verrou intrinsèque de l'objet qui "possède" la méthode.

Par exemple dans thread1, vous avez appelé a.foo() et supposez que foo() est synchronisé. thread1 va acquérir le verrou intrinsèque de l'objet a se référant.

De même, si AClass.bar() est appelé (et bar est synchronisé et une méthode statique), le verrou intrinsèque de l'objet de classe AClass sera acquis.

Un verrou peut être tenu par un seul thread à la fois. Cela ne défait pas le but; que est le but.

Les threadsmut uallyex s'excluent mutuellement de l'action simultanée dans les sections critiques en acquérant un verrou, ou mutex. Cela fournit une atomicité efficace autour d'une série d'actions distinctes, de sorte que les autres threads ne voient jamais d'états intermédiaires qui pourraient violer les garanties de cohérence.

Oui, vous ne pourrez pas appeler une autre méthode synchronisée sur le même objet, à cause du verrou intrinsèque. Ce qui est au niveau de l'objet, seulement 1 thread l'acquerra.

Peu importe que la méthode synchronized appartienne à la même classe ou non, ce qui compte, c'est que le thread appelant de la méthode acquiert le verrou ou non, si c'est le cas, il sera autorisé à entrer dans la section critique car le verrou est reentrant.

Si ce n'était pas le cas, alors un appel récursif provoquerait une impasse,

fn(){
 synchronized(mutex){ // the current thread has already acquired the mutex
   fn();
 }
}

Fn ici ne bloquera pas car le verrou est ré-entrant, c'est-à-dire ( le thread qui acquiert déjà le verrou peut entrer et louer la section critique encore tant qu'il est encore acquis).

Serais-je incapable d'appeler une autre méthode synchronisée de la même classe? Si oui, alors tout le but d'avoir des méthodes synchronisées est vaincu. N'est-ce pas?

Non. Vous ne pouvez pas appeler une autre méthode synchronized sur le même objet pour le verrouillage au niveau de l'objet et vous ne pouvez pas appeler une autre méthode static sysnchronized sur la même classe.

Mais cela ne va pas à l'encontre du but d'avoir la synchronisation.

Si vous suivez l'autre page de documentation sur méthodes synchronisées:

Faire ces méthodes synchronized a deux effets:

1. Premièrement, il n'est pas possible pour deux invocations de méthodes synchronisées sur le même objet de s'entrelacer. Lorsqu'un thread exécute une méthode synchronisée pour un objet, tous les autres threads qui invoquent des méthodes synchronisées pour le même bloc d'objet (suspendent l'exécution) jusqu'à ce que le premier thread soit terminé avec l'objet.
2. Deuxièmement, lorsqu'une méthode synchronisée sorties, il établit automatiquement un passe-avant relation avec toute invocation ultérieure d'une méthode synchronisée pour le même objet. Cela garantit que les modifications de l'état de l'objet sont visibles par tous les threads.

Si vous autorisez deux méthodes synchronized à s'exécuter en parallèle. vous aurez forcément des erreurs d'incohérence de mémoire sur les données partagées.

Sur une note différente, Verrou fournit la meilleure alternative synchronized construire.

Question SE connexe:

La Synchronisation vs Verrouillage

Verrous peuvent être divisés en deux classes - 'réentrant" et "non réentrant'. En Java 'synchronisé', l'implémentation de base de l'interface Lock( classe ReentrantLock), interface ReadWriteLock (classe ReentrantReadWriteLock) - sont réentrantes. Réentrance signifie - un fil peut encore et encore tenir le verrou.