Dans la bibliothèque Json-Java ( org.json.jsonarray ) j'ai trouvé cet extrait de code avec un Je ne comprends pas la nécessité de la synchronisation ici, en tant que Synchronisé Block autour d'une méthode - une variable locale StringWriter < / code> est uniquement local à la méthode donnée (et pourquoi la synchronisation est sur le tampon). La synchronisation est-elle vraiment nécessaire ici, et si, pourquoi?
4 Réponses :
Le constructeur vide pour rien n'est partagé, le bloc StringWriter est synchronisé est inutile. < p> Sauf ... écrire délégués à un autre fil, mais je doute sérieusement cela.
Cela peut être une optimisation des performances. Dans l'Oracle JVM, ré-acquérir une serrure déjà tenue est très rapide. Vraisemblablement, l'appel écrire fait de nombreux appels dans Stringbuffer. En verrouillant avant d'appeler écrire , le verrou sera organisé par tous ces appels au lieu d'être publié et ré-acquis pour chaque appel.
À partir de Java 6, le biais de verrouillage signifie que l'acquisition d'un verrou non compris est rapide de toute façon.
@ Chrisjest-Young - Oui, je ne sais pas dans quelle mesure cette optimisation de la performance est toujours (ou jamais).
Je ne suis pas sous-estimé étant libéré et ré-acquis pour chaque appel . Le écrire () appel n'essaye pas et synchroniser sur le écrivain du tout. La serrure est acquise et libérée une seule fois, à l'intérieur de la méthode Tostring (int) dans la question de l'OP.
@Sotiriosdelimanolis - Toutes les méthodes de Stringbuffer (qui sous-tendent le Stringwriter) sont synchronisées.
@jtahlborn très intéressant, +1.
Les tampons à cordes sont sans danger pour une utilisation par plusieurs threads. Les méthodes sont synchronisées si nécessaire pour que toutes les opérations de n'importe quelle instance particulière se comportent comme si elles se produisent dans un ordre de série correspondant à l'ordre des appels de méthode effectués par chacun des threads individuels impliqués.
Cela signifie que la synchronisation à nouveau sur le Étant donné que l'instance stritter est locale à l'appel de la méthode, il est impossible d'avoir plusieurs threads accéder à la même instance simultanément, ce qui rend également la synchronisation inutile. getbuffer () renvoie un stringbuffer , et selon la documentation A "code> stringbuffer est déjà synchronisé:
Stringbuffer est totalement surchargée. Les modifications apportées au StringWriter seront automatiquement synchronisées car il utilise le fichier Stringbuffer interne.
C'est un bug. Chaque thread crée sa propre variable locale dans la méthode et la synchronise sur elle.Chaque du temps entrant dans les threads de la méthode créant son propre moniteur d'objet qui ne peut pas être maintenu par un autre fil car il est local et ne vit que sur la pile de fil!
Il est inutile. Avec le constructeur par défaut, le tampon est un objet nouvellement instancié.
buf = nouvelle Stringbuffer (); à l'intérieur du constructeur.Notez que l'auteur de la bibliothèque Org.json est un programmeur JavaScript et non un programmeur Java, et ce fait est démontré dans tout le code. Pour un traitement sérieux JSON, envisagez d'utiliser la bibliothèque GSON de Google.