Inside the JDK "lock" optimization strategy
1. lock bias
Lock is biased locking means for optimizing the operation, the core idea is: If a thread to get the lock, then the lock to enter bias mode, when the thread again requesting a lock, do not need any synchronization operations, thus saving a lot about the application operation of the lock, thereby improving the performance of the program. Almost no lock contention occasions, biased locking good optimization results for the fierce competition lock occasions, ineffective, because every time a different thread in the application lock, biased mode will fail, might as well not enabled biased locking. The use of the Java virtual machine parameters -XX: + UseBiasedLocking can turn biased locking.
2. Lightweight lock
If you tend to lock fails, the virtual machine does not immediately suspend the thread, the means will be used to optimize a lightweight lock. It is simply a pointer to an object head as internal thread holding the lock stack to determine whether a thread holds the object lock. If a thread get a lightweight lock, you can smoothly enter the critical region. If the lightweight lock fails, the other thread has grabbed the lock, the lock request for the current thread expands heavyweight lock.
3. spin locks
After the lock expansion, in order to avoid the real thread hangs in the operating system level, the virtual machine will make a final effort - spin locks. The current thread is temporarily unable to acquire a lock, but when you can get the lock is unknown, perhaps in a few CPU clock cycles can be locked. The system will assume the near future thread can get the lock, therefore, the current thread virtual opportunity to do a few empty cycles, after after several cycles, if you can get a lock, then successfully enter the critical region. If you can not get a lock, is really going to thread hangs the operating system level.
4. Lock elimination
A more thorough lock optimization, Java virtual machine JIT compiler at the time, by scanning the running context, there can be no lock to remove shared resource competition, by eliminating the lock, you can save time lock requests meaningless. For example, in the case of a concurrent competition Vector not exist, but the use of the internal Vector Synchronized requests a lock, such as the following codes:
public String[] createStrings(){ Vector<String> v = new Vector<String>(); for(int i=0;i<100;i++){ v.add(Integer.toString(i)); } return v.toArray(new String[0]); }
The above code Vector, since the only variable v in createStrings function, he just a simple local variable. Local variables are allocated on the thread stack, belonging to the thread private data, and therefore can not be accessed by other threads. Under such circumstances, all of the internal Vector lock synchronization is not necessary. If this virtual machine is detected, these will be unnecessary to remove the lock operation.
A key technology for the analysis involved the elimination of lock escape. Escape analysis is to see if one will escape a variable scope. In the present embodiment, the variable v apparently did not escape createStrings (outside) function. This can be bold and internal variables v remove the lock operation is based on a virtual machine. If createStrings () return is not an array, but v itself, then that variable v escape out of the current function, that variable v likely to be accessed by other threads. If so, the virtual machine can not eliminate the lock operation in the variable v.
Escape analysis must be performed in -server mode, may be used -XX: + DoEscapeAnalysis open the escape analysis parameters. Use -XX: + EliminateLocks parameters can open the lock eliminated.