The lock statement acquires the mutual-exclusion lock for a given object, executes a statement block, and then releases the lock. While a lock is held, the thread that holds the lock can acquire and release the lock multiple times. Any other thread is blocked from acquiring the lock and waits until the lock is released. The lock statement ensures that at most only one thread executes its body at any moment in time.

[!INCLUDEcsharp-version-note]

The lock statement takes the following form:

lock (x)
{
    // Your code...
}

The variable x is an expression of xref:System.Threading.Lock?displayProperty=fullName type, or a reference type. When the compiler knows that x is of the type xref:System.Threading.Lock?displayProperty=fullName, it's precisely equivalent to:

using (x.EnterScope())
{
    // Your code...
}

The object returned by xref:System.Threading.Lock.EnterScope?displayProperty=nameWithType is a ref struct that includes a Dispose() method. The generated using statement ensures the scope is released even if an exception is thrown within the body of the lock statement.

Otherwise, the lock statement is precisely equivalent to:

object __lockObj = x;
bool __lockWasTaken = false;
try
{
    System.Threading.Monitor.Enter(__lockObj, ref __lockWasTaken);
    // Your code...
}
finally
{
    if (__lockWasTaken) System.Threading.Monitor.Exit(__lockObj);
}

Since the code uses a try-finally statement, the lock is released even if an exception is thrown within the body of a lock statement.

You can't use the await expression in the body of a lock statement.

Starting with .NET 9 and C# 13, lock a dedicated object instance of the xref:System.Threading.Lock?displayProperty=nameWithType type for best performance. The compiler also issues a warning if you cast a known Lock object to another type and lock it. If you're using an older version of .NET and C#, lock on a dedicated object instance that isn't used for another purpose. Avoid using the same lock object instance for different shared resources, as it might result in deadlock or lock contention. In particular, avoid using the following instances as lock objects:

• this, as callers might also lock this.
• xref:System.Type instances, as they might be obtained by the typeof operator or reflection.
• string instances, including string literals, as they might be interned.

Hold a lock for as short time as possible to reduce lock contention.

The following example defines an Account class that synchronizes access to its private balance field by locking on a dedicated balanceLock instance. Using the same instance for locking ensures that two different threads can't update the balance field by calling the Debit or Credit methods simultaneously. The sample uses C# 13 and the new Lock object. If you're using an older version of C# or an older .NET library, lock an instance of object.

:::code language="csharp" source="snippets/lock/Program.cs":::

For more information, see The lock statement section of the C# language specification.

• xref:System.Threading.Monitor?displayProperty=nameWithType
• xref:System.Threading.SpinLock?displayProperty=nameWithType
• xref:System.Threading.Interlocked?displayProperty=nameWithType
• Overview of synchronization primitives
• Introduction to System.Threading.Channels