6 Réponses :
En réalité, un verrou sur une méthode statique de classe FOO code> est identique à la mise en place d'un verrouillage sur
foo.class code> (qui est la seule instance):
public static void doSomething()
{
synchronized(Foo.class)
{
// ...
}
}
Vous avez raison - la serrure réelle figure sur l'instance code> code> elle-même, pas sur une instance de la classe (sans parler tous les cas em>) - mais je pense que vous " Référence de la page liée trop littéralement. Il utilise lui-même la phrase "une serrure statique (une serrure de classe)", donc clairement que son auteur est conscient de la façon dont le verrouillage fonctionne. Mais si vous avez de nombreux cas dans différents threads qui utilisent toutes les méthodes statiques synchronisées, ces instances se verrouillent tous. Les méthodes statiques synchronisées ne doivent pas em> provoquer le blocage de méthodes synchronisées em> instance em>, mais le problème est là indépendamment. P>
Pour comprendre cela, le moyen le plus simple consiste à comparer comment les travaux de verrouillage contre la méthode d'instance et la méthode statique. Disons que vous avez des tests de classe.java, qui a deux méthodes telles que suivez.
public class Test{ public synchronized void instanceMethod(){ } public synchronized static void staticMethod(){ } }
Très bonne explication de la différence de mécanismes de verrouillage.
Enfin eu l'idée de la méthode statique synchronisée. Belle explication.
Oui, il s'agit d'un assez bon résumé de l'instance de verrouillage VS Méthodes statiques.
Je ne suis pas sûr que j'aime cette explication. Vous dites "Ta obtient la serrure sur l'InstanceCemethod de Testa" qui n'est pas fidèle à ma connaissance. Ne devrait-il pas s'agir que TA obtient la serrure sur le test de l'instance. Il ne verrouille pas une méthode d'instance.
Semblant que les 2 méthodes sont les mêmes, alors je voudrais probablement modifier la dernière phrase du dernier paragraphe. J'écrirais: "Ce qui signifie que la tuberculose ne peut pas accéder à aucune méthode b> jusqu'à la libération de la serrure"
Voici mon code de test qui montre que vous avez raison et que l'article est un peu trop prudent: impressions: p> bien sûr si statique synchronisé code> n'a aucune incidence sur les méthodes code> synchronisées > sur les instances ... p>
statique synchronisé Code> Les méthodes sont utilisées dans tout le système, vous pouvez vous attendre à ce qu'ils ont le plus d'impact sur le débit d'un système multithread. Utilisez-les donc à votre péril ... p> p>
Merci pour le code de test! Même être trop prudent ne devrait pas faire ce que l'auteur dit correctement. Les serrures d'instance et de classe sont séparées. L'article m'a fait douter du SCJP hallowed, d'autant plus que l'auteur, de son CV, est un expert.
Cela ne dit pas «verrouille toutes les instances de la classe». Il est écrit 'Lock sur em> toutes les instances de la classe. C'est mal formulé, effectivement incorrect, mais ce n'est pas dit ce que vous avez dit. P>
Une méthode synchronisée acquiert un moniteur (§17.1) avant son exécution. Pour une méthode de classe (statique), le moniteur associé à l'objet de classe pour la classe de la méthode est utilisé. Pour une méthode d'instance, le moniteur associé à cela (l'objet pour lequel la méthode a été appelé) est utilisé. P> blockQuote>
http: // docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.3.6 P>
Étant donné que des méthodes statiques sont disponibles pour toutes les instances, il verrouille toutes les instances.
Bien que des méthodes statiques soient disponibles sur des cas, elles ne doivent pas être consultées via des instances. Ils ne devraient être consultés que statiquement. Donc, ce que l'auteur dit n'est toujours pas raison.
@duffymo non, il ne verrouille pas aucun cas i>. 'Synchronisé (ceci)' procéderait pendant cette serrure.
Les dangers de citer du contexte. Lecture de tout le texte Il devient très clair que l'auteur parle de ce qui se passe lorsque plusieurs threads tentent d'accéder à la même méthode synchronisée statique. Le POV n'est pas les instances d'objet, ses threads i> b>.
@duffymo Une méthode synchronisée acquiert un moniteur (§17.1) avant son exécution. Pour une méthode de classe (statique), le moniteur associé à l'objet de classe pour la classe i> i> i> est utilisé. Pour une méthode d'instance, le moniteur associé à cette i> b> (l'objet pour lequel la méthode a été invoquée) est utilisée.
@Robertchristian. Super. Vaut bien l'attente de trois ans.