¿Por qué el objeto de bloqueo tiene que ser estático?

Es muy común utilizar un objeto de solo lectura estático privado para bloquear en subprocesos múltiples. Entiendo que privado reduce los puntos de entrada al objeto de bloqueo al apretar la encapsulación y por lo tanto el acceso a lo más esencial.

¿Pero por qué estática?

private static readonly object Locker = new object();

Al final, el campo solo se usa dentro de mi clase, y también podría usar esto en su lugar:

private readonly object Locker = new object();

¿Algún comentario?

ACTUALIZAR:

Como ejemplo, he pegado este código (solo un ejemplo). Podría usar un casillero estático o no estático en esto y ambos funcionarían bien. Teniendo en cuenta la respuesta a continuación, ¿debería definir mi casillero de esta manera? (Lo siento, tengo una entrevista la próxima semana y necesito conocer todos los detalles :)

private readonly object Locker = new object();

Y aquí está el código:

    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();
        }

Gracias

No es "muy común usar un objeto de solo lectura estático privado para bloquear en subprocesos múltiples"; más bien, es común usar un bloqueo en la granularidad apropiada / elegida . A veces eso es static. Más a menudo, en mi opinión, no lo es, pero se basa en instancias .

La principal vez que ve un staticbloqueo es para un caché global o para la carga diferida de datos globales / singletons. Y en este último, hay mejores formas de hacerlo de todos modos .

Entonces realmente depende: ¿cómo se Lockerusa en su escenario? ¿Está protegiendo algo que en sí mismo es estático? Si es así, la cerradura debe ser estática. Si está protegiendo algo que está basado en instancias , entonces, en mi opinión, el bloqueo también debe basarse en instancias.

No tiene por qué ser estática, de hecho, a veces se debe no ser estática.

La variable debe vivir en el mismo ámbito que los métodos donde la usa para bloquear. Si los métodos son estáticos, la variable debe ser estática, y si los métodos son métodos de instancia, la variable debe ser una variable de instancia.

Una variable estática seguirá funcionando cuando se use para bloquear un método de instancia, pero entonces bloqueará demasiado. Bloqueará todos los métodos en todas las instancias, no solo los métodos en la misma instancia.

El alcance y la vida útil de un candado pueden / deben depender de la "cosa" que desee bloquear. Los bloqueos estáticos se utilizan principalmente para bloquear elementos estáticos.