objet de verrouillage privé et verrouillage intrinsèque

Question 1

En utilisant explicite lock Les objets peuvent permettre à différentes méthodes de se synchroniser sur différentes serrures et d'éviter une affirmation inutile. Il rend également le verrouillage plus explicite et peut faciliter la recherche du code pour les blocs qui utilisent le verrouillage.

Cependant, vous ne voulez probablement pas faire non plus! Trouvez la classe appropriée dans java.util.concurrent et utilisez-le à la place. :)

Question 2

Un verrou privé peut être utile si vous faites une sorte de fragment de verrouillage, c'est-à-dire que vous devez uniquement verrouiller certaines parties de votre objet tandis que d'autres sont toujours accessibles par un autre client.

Un simple parallèle pour comprendre ce concept est un verrouillage de table dans une base de données: si vous modifiez une table, vous acquérez le verrou sur cette table unique, pas la base de données entière, de sorte que le reste des tables peut être modifié par d'autres clients. Si vous avez besoin d'implémenter une logique similaire, mais dans un POJO, vous utiliseriez autant de verrous privés que nécessaire.

L'un des inconvénients de cette approche est que votre classe est encombrée de beaucoup d'objets. Cela pourrait indiquer que vous devez le refacter dans un ensemble de classes plus granulaires avec une stratégie de verrouillage plus simple, mais tout dépend de votre conception et de votre implémentation.

Question 3

Ceux-ci utilisent tous deux des verrous intrinsèques. Votre premier exemple consiste à utiliser le verrou intrinsèque de lock, tandis que le second utilise le verrou intrinsèque de this. La question est de savoir si this est vraiment ce que vous voulez verrouiller, ce qui n'est souvent pas le cas.

Considérez le cas, lorsque vous utilisez synchronized(this) à l'intérieur de l'une de vos méthodes. Vous avez 2 objets de cette classe, et ces objets font référence à une ressource partagée. Si vous verrouillez this Ensuite, vous n'aurez pas d'exclusivité mutuelle à cette ressource. Vous devez verrouiller un objet auquel tout ce qui peut accéder à la ressource a accès.

Verrouiller this Seulement si la ressource importante fait partie de la classe elle-même. Même alors, dans certains cas, un objet de verrouillage est meilleur. De plus, s'il y a plusieurs ressources différentes dans votre classe, qui n'ont pas besoin d'être mutuellement exclusives dans son ensemble, mais individuellement, vous avez besoin de plusieurs objets de verrouillage.

La clé est de vraiment savoir comment synchronisé Fonctionne et soyez conscient de ce que fait réellement votre code

Question 4

En fait, en utilisant l'un ou l'autre ne fera aucune différence, il s'agit davantage de choix / style, les écrivains API verrouilleront l'objet -e ni par synchronisé (this), soit synchronisé explicite sur n'importe quelle méthode d'objet-, ou utiliser un moniteur interne dépend du partage d'une ressource, vous ne voudrez peut-être pas que les utilisateurs d'API accédent à votre verrouillage interne ou vous voudrez peut-être donner le choix aux utilisateurs d'API pour partager le verrou intrinsèque de l'objet.

Quoi qu'il en soit, aucun de ces choix n'est faux, il s'agit davantage de l'intention d'une telle verrouillage.

Lis Concurrence de Java dans la pratique, cela fera de vous un maître de la concurrence et clarifiera bon nombre de ces concepts, qui sont parfois plus liés au choix que vous faites plutôt qu'à l'exactitude.

Question 5

Chaque objet n'a qu'un seul verrou intrinsèque.

Avec le mot-clé synchronisé: Si vous appelez deux méthodes synchronisées du même objet à partir de deux threads différents, un thread uniforme pourrait exécuter la méthode l'un et l'autre thread pourrait exécuter la méthode deux, cela ne se produira pas parce que les deux méthodes partagent le même verrou intrinsèque (qui appartient à la objet). Et selon ce fil, il faudra attendre que l'autre fil se termine avant de pouvoir acquérir le verrou intrinsèque pour exécuter l'autre méthode.

Mais si vous utilisez plusieurs serrures, vous vous assurerez qu'un seul thread peut accéder à la méthode un à la fois et qu'un seul thread peut accéder à la méthode deux à la fois. Mais vous autoriserez cette méthode une et la méthode deux accessibles par un thread chacune en même temps, puis en réduisant le temps requis pour l'opération.