I had a heated discussion with my colleagues a few days ago. I recorded some gains.
First, the msdn definition is given:
LockKeyword can be used to ensureCodeThe block is running without being interrupted by other threads. This is achieved by obtaining mutex locks for a given object during the code block operation.
Let's take a look at the execution process. The sample code is as follows:
Assume that thread a is executed first, and thread B is a little slower. Thread a executes the lock statement to determine if OBJ has applied for a mutex lock,
The judgment is based on comparing object. referenceequals with the existing locks one by one (not confirmed here ).
Then, apply for a new mutex lock, and thread a enters the lock.
In this case, it is assumed that thread B is started, and thread A has not executed the code in the lock. Thread B executes the lock statement and checks the OBJ
After applying for a mutex lock, wait until thread a finishes executing the lock and releases the mutex lock. Thread B can apply for a new mutex lock and execute it.
The code in lock.
Next, let's talk about the lock object.
Why cannot I lock the value type, such as lock (1? Lock is essentially monitor. Enter, and monitor. Enter will pack the value type,
Each lock is a boxed object. The lock is similar to the syntax sugar of the compiler. Therefore, the compiler directly limits the lock value type.
Even if the compiler allows you to lock (1), but object. referenceequals (10 thousand) always returns false (because
Objects are different after each packing), that is to say, each time it is determined that no mutex lock is applied, so that at the same time, other threads can still
Access the code in it, and the synchronization effect cannot be reached. Similarly, lock (object) 1) does not work.
What about the lock ("XXX") string? The original words on msdn are:
Locking a string is especially dangerous because the string is "Temporarily" by the Common Language Runtime Library (CLR ". This means that the entireProgramAny given string in
There is only one instance, and the same object represents the text in all threads of all running application domains. Therefore, as long
If a lock is placed on a string with the same content at any location in the program process, all instances of the string in the application will be locked.
Generally, it is better to avoid locking the public type or locking an object instance that is not controlled by the application. For example, if the instance can be publicly accessed,
Lock (this) may cause problems because uncontrolled Code may also lock the object. This may lead to deadlocks, that is, two or more lines.
To release the same object. For the same reason, locking public data types (compared to objects) may also cause problems. And lock (this)
Only valid for the current object. If multiple objects cannot be synchronized.
Lock (typeof (class) is the same as locking a string and has a wide range.
Some system classes provide members dedicated for locking. For example, the array type provides syncroot. Many Collection types also provide syncroot.
For custom classes, private read-only static objects are recommended, for example:
Private Static readonly object OBJ = new object ();
Why should I set it to read-only? In this case, if you change the OBJ value in the lock code segment, other threads will be unobstructed, because the mutex lock
Object. referenceequals returns false if the object is changed.