Pourquoi l’object verrou doit-il être statique?

Il est très courant d’utiliser un object readonly statique privé pour verrouiller les threads multiples. Je comprends que privé réduit les points d’entrée à l’object de locking en resserrant l’encapsulation et donc l’access aux plus essentiels.

Mais pourquoi statique?

private static readonly object Locker = new object(); 

A la fin, le champ est utilisé uniquement dans ma classe uniquement, et je pourrais aussi simplement utiliser ceci:

 private readonly object Locker = new object(); 

Des commentaires?

METTRE À JOUR:

Par exemple, j’ai collé ce code (juste un exemple). Je pourrais utiliser des casiers statiques ou non statiques là-dessus et les deux fonctionneraient bien. Compte tenu de la réponse ci-dessous, je devrais plutôt définir mon casier comme ceci? (Désolé, j’ai un entretien la semaine prochaine et j’ai besoin de connaître tous les détails 🙂

 private readonly object Locker = new object(); 

Et voici le code:

  private int _priceA; private int _priceB; private EventWaitHandle[] _waithandle; private readonly IService _service; //ctor public ModuleAViewModel(IService service) { _service = service; _modelA = new ModelA(); _waithandle = new ManualResetEvent[2]; _waithandle[0] = new ManualResetEvent(false); _waithandle[1] = new ManualResetEvent(false); LoadDataByThread(); } private void LoadDataByThread() { new Thread(() => { new Thread(() => { lock (Locker) { _priceA = _service.GetPriceA(); } _waithandle[0].Set(); }).Start(); new Thread(() => { lock (Locker) { _priceB = _service.GetPriceB(); } _waithandle[1].Set(); }).Start(); WaitHandle.WaitAll(_waithandle); PriceA = _priceA; PriceB = _priceB; }).Start(); } 

Merci

Il n’est pas “très courant d’utiliser un object readonly statique privé pour le locking en multi threading” – il est plutôt courant d’utiliser un verrou à la granularité appropriée / choisie . Parfois, c’est static . Plus souvent, IMO, ce n’est pas le cas – mais c’est une instance basée.

Le principal moment où vous voyez un verrou static concerne un cache global ou un chargement différé de données / singletons globaux. Et dans ce dernier cas, il existe de meilleures façons de le faire.

Donc ça dépend vraiment: comment Locker est-il utilisé dans votre scénario? Protège-t-il quelque chose qui est luimême statique? Si c’est le cas, le verrou doit être statique. S’il protège quelque chose qui est basé sur l’ instance , IMO le verrou doit également être basé sur l’instance.

Il n’est pas nécessaire que ce soit statique, en fait, parfois, il ne devrait pas être statique.

La variable doit vivre dans la même scope que les méthodes que vous utilisez pour le locking. Si les méthodes sont statiques, la variable doit être statique et si les méthodes sont des méthodes d’instance, la variable doit être une instance variable.

Une variable statique fonctionnera quand elle sera utilisée pour verrouiller une méthode d’instance, mais vous serez alors trop bloqué. Vous allez verrouiller toutes les méthodes dans toutes les instances, pas seulement les méthodes de la même instance.

La scope et la durée de vie d’un verrou peuvent / doivent dépendre de la “chose” que vous voulez verrouiller. Les verrous statiques sont principalement utilisés pour verrouiller des objects statiques.