Java class object lock and lock comprehensive analysis (multi-threaded synchronized keyword)
http://www.importnew.com/20444.html
synchronized modification difference in static methods and non-static methods
https://www.cnblogs.com/wxgblogs/p/5505368.html
Do you really know Java multi-threaded programming?
https://blog.csdn.net/bntX2jSQfEHy7/article/details/78957667
Java multi-thread basis --Lock class
https://www.jb51.net/article/104421.htm
Java programming difference synchronized with the lock of [Recommended]
https://www.jb51.net/article/126658.htm
java in synchronized (sync code block and synchronization method), and the difference Detailed
https://www.jb51.net/article/106941.htm
Required for the sync code object monitor set, the overall process compared with synchronized modified to better ( greater range of synchronization, the more the performance difference )
Reentrant lock
If the lock is provided with reentrancy, called a reentrant lock. Like synchronized and ReentrantLock are reentrant locks, reentrancy in my opinion actually show the distribution mechanism locks: thread-based distribution, not based allocation method call. Here is a simple example, when a thread to perform a synchronized time method, for example, method1 , and in method1 will call another synchronized method method2 , this time without having to re-thread lock to apply, but the method can be performed directly method2 .
Look at the following code will understand :
classMyClass{
publicsynchronizedvoidmethod1(){
method2();
}
publicsynchronizedvoidmethod2(){
}
}
The method of the above two code method1 and method2 are used synchronized been modified, if at some point, thread A execution to the method1 , this time thread A acquires a lock for this object, and as method2 is synchronized method, if synchronized not be provided reentrant, then thread A need to reapply the lock. But this will cause a problem, because the thread A already holds the lock of the object, but the object in the application to obtain a lock, which would thread A waits never gets into the lock.
And because synchronized and Lock all have reentrancy, so the above phenomenon does not occur.
Interruptible lock
Interruptible lock: As the name suggests, is that you can lock the corresponding interrupt.
In Java in, the synchronized not interruptible locks, Lock is interruptible lock.
If a thread A code is being executed in the lock, another thread B is waiting to acquire the lock, may be due to wait too long, thread B does not want to wait, and would like to deal with other things, we can make it or break themselves in another thread interrupt it, this is interruptible lock.
In front of the demonstration lockInterruptibly () when usage is reflected Lock can interrupt sex
Fair locks
Fair as possible i.e. lock the lock request in order to acquire a lock. For example, with more than one thread is waiting for a lock, when the lock is released, wait the longest thread (first thread request) will get the Institute, which is fair locks.
Unfair lock that is no guarantee that the lock is acquired in the order requested the lock. This could lead to a thread or some never get less than a lock.
In Java in, the synchronized is unfair locked, it can not guarantee the order of the waiting threads acquire locks.
For ReentrantLock and ReentrantReadWriteLock , it is non-default fair locks the case, but can be set to lock fair.
Read-Write Lock
A read-write lock will access resources (such as files) into a 2 locks, a read lock and a write lock.
It is because of read-write locks, which makes the read operation between multiple threads do not conflict.
ReadWriteLock is read-write locks, it is an interface, ReentrantReadWriteLock implements this interface.
By () readLock acquire a read lock, by () writeLock acquire a write lock.
The difference between the lock and lockInterruptibly of ReentrantLock
https://blog.csdn.net/wojiushiwo945you/article/details/42387091
The difference is that: thread tries to acquire the lock operation fails, the waiting process, if the thread is interrupted by another thread, it is how to respond to an interrupt request. lock method ignores the interrupt request, continue to acquire the lock until it succeeds; and lockInterruptibly interrupt exception thrown directly respond immediately interrupted by the upper caller to handle interrupts.
Talk about a mistake from the double checking locks Code volatile keyword
Lock and synchronized selection
In conclusion, Lock and synchronized differently following:
1) Lock is an interface, and the synchronized keyword in Java, synchronized built-in language;
2) synchronized when an exception occurs, it will automatically release the thread owns the lock, it will not lead to a deadlock phenomenon; and Lock when an exception occurs, if there is no initiative by unLock () to release the lock, it is likely to result in deadlock, it is necessary to release the lock in a finally block the use of lock;
3) lock lets wait for the lock thread interrupt response, and synchronized but it's not, when using synchronized, waiting threads will wait forever, can not respond to interrupts;
4) by lock can know without success to obtain a lock, and synchronized it can not be done.
5) Lock multiple threads can improve the efficiency of the read operation.
In terms of performance, if not fierce competition for resources, the performance of both is similar, but when the competition is very fierce resource (ie a large number of threads simultaneously competition), this time the performance is much better than Lock synchronized. So, to select appropriate in accordance with the specific use.