Reputation: 10923
I'm trying to understand what makes the lock in concurrency so important if one can use synchronized (this)
. In the dummy code below, I can do either:
synchronized(this){...}
)Code:
private final ReentrantLock lock = new ReentrantLock();
private static List<Integer> ints;
public Integer getResult(String name) {
lock.lock();
try {
if (ints.size()==3) {
ints=null;
return -9;
}
for (int x=0; x<ints.size(); x++) {
System.out.println("["+name+"] "+x+"/"+ints.size()+". values >>>>"+ints.get(x));
}
} finally {
lock.unlock();
}
return random;
}
Upvotes: 402
Views: 201596
Reputation: 29656
A ReentrantLock is unstructured, unlike synchronized
constructs -- i.e. you don't need to use a block structure for locking and can even hold a lock across methods. An example:
private ReentrantLock lock;
public void foo() {
...
lock.lock();
...
}
public void bar() {
...
lock.unlock();
...
}
Such flow is impossible to represent via a single monitor in a synchronized
construct.
Aside from that, ReentrantLock
supports lock polling and interruptible lock waits that support time-out. ReentrantLock
also has support for configurable fairness policy, allowing more flexible thread scheduling.
The constructor for this class accepts an optional fairness parameter. When set
true
, under contention, locks favor granting access to the longest-waiting thread. Otherwise this lock does not guarantee any particular access order. Programs using fair locks accessed by many threads may display lower overall throughput (i.e., are slower; often much slower) than those using the default setting, but have smaller variances in times to obtain locks and guarantee lack of starvation. Note however, that fairness of locks does not guarantee fairness of thread scheduling. Thus, one of many threads using a fair lock may obtain it multiple times in succession while other active threads are not progressing and not currently holding the lock. Also note that the untimedtryLock
method does not honor the fairness setting. It will succeed if the lock is available even if other threads are waiting.
ReentrantLock
may also be more scalable, performing much better under higher contention. You can read more about this here.
This claim has been contested, however; see the following comment:
In the reentrant lock test, a new lock is created each time, thus there is no exclusive locking and the resulting data is invalid. Also, the IBM link offers no source code for the underlying benchmark so its impossible to characterize whether the test was even conducted correctly.
When should you use ReentrantLock
s? According to that developerWorks article...
The answer is pretty simple -- use it when you actually need something it provides that
synchronized
doesn't, like timed lock waits, interruptible lock waits, non-block-structured locks, multiple condition variables, or lock polling.ReentrantLock
also has scalability benefits, and you should use it if you actually have a situation that exhibits high contention, but remember that the vast majority ofsynchronized
blocks hardly ever exhibit any contention, let alone high contention. I would advise developing with synchronization until synchronization has proven to be inadequate, rather than simply assuming "the performance will be better" if you useReentrantLock
. Remember, these are advanced tools for advanced users. (And truly advanced users tend to prefer the simplest tools they can find until they're convinced the simple tools are inadequate.) As always, make it right first, and then worry about whether or not you have to make it faster.
One final aspect that's gonna become more relevant in the near future has to do with Java 15 and Project Loom. In the (new) world of virtual threads, the underlying scheduler would be able to work much better with ReentrantLock
than it's able to do with synchronized
, that's true at least in the initial Java 15 release but may be optimized later.
In the current Loom implementation, a virtual thread can be pinned in two situations: when there is a native frame on the stack — when Java code calls into native code (JNI) that then calls back into Java — and when inside a
synchronized
block or method. In those cases, blocking the virtual thread will block the physical thread that carries it. Once the native call completes or the monitor released (thesynchronized
block/method is exited) the thread is unpinned.
If you have a common I/O operation guarded by a
synchronized
, replace the monitor with aReentrantLock
to let your application benefit fully from Loom’s scalability boost even before we fix pinning by monitors (or, better yet, use the higher-performanceStampedLock
if you can).
JEP 491: Synchronize Virtual Threads without Pinning
Improve the scalability of Java code that uses synchronized methods and statements by arranging for virtual threads that block in such constructs to release their underlying platform threads for use by other virtual threads. This will eliminate nearly all cases of virtual threads being pinned to platform threads, which severely restricts the number of virtual threads available to handle an application's workload.
Goals
- Enable existing Java libraries to scale well with virtual threads without having to change them not to use synchronized methods and statements.
Upvotes: 570
Reputation: 340350
One special case: In Java 21, 22, and 23, lengthy or frequent code using synchronized
with virtual threads would result in pinning. Pinning can defeat the performance gains expected from use of virtual threads.
In such cases, synchronized
could be replaced easily with a ReentrantLock
to avoid pinning.
The pinning-due-to-synchronized
issue goes away in Java 24+.
Upvotes: 0
Reputation: 38950
A simple example using ReentrantLock
import java.util.concurrent.locks.ReentrantLock;
class ReentrantLockDemo {
private final ReentrantLock lock = new ReentrantLock();
public void safeMethod1() {
try {
lock.lock();
/* your business logic goes here */
} finally {
lock.unlock();
}
}
}
From oracle documentation page about ReentrantLock:
A reentrant mutual exclusion Lock with the same basic behaviour and semantics as the implicit monitor lock accessed using synchronized methods and statements, but with extended capabilities.
The constructor for this class accepts an optional fairness parameter. When set true, under contention, locks favor granting access to the longest-waiting thread. Otherwise this lock does not guarantee any particular access order.
ReentrantLock key APIs, which are better over synchronized
lockInterruptibly()
: Acquires the lock unless the current thread is interrupted.tryLock()
: Acquires the lock only if it is not held by another thread at the time of invocationtryLock(long timeout, TimeUnit unit)
Acquires the lock if it is not held by another thread within the given waiting time and the current thread has not been interrupted. This API avoid thread starvation, which is a drawback with synchronized
public ReentrantLock(boolean fair)
: ReentrantLock with the fairness policy.Upvotes: 14
Reputation: 3763
I think the wait/notify/notifyAll methods don't belong on the Object class as it pollutes all objects with methods that are rarely used. They make much more sense on a dedicated Lock class. So from this point of view, perhaps it's better to use a tool that is explicitly designed for the job at hand - ie ReentrantLock.
Upvotes: 1
Reputation: 1515
One thing to keep in mind is :
The name 'ReentrantLock' gives out a wrong message about other locking mechanism that they are not re-entrant. This is not true. Lock acquired via 'synchronized' is also re-entrant in Java.
Key difference is that 'synchronized' uses intrinsic lock ( one that every Object has ) while Lock API doesn't.
Upvotes: 4
Reputation: 55760
ReentrantReadWriteLock
is a specialized lock whereas synchronized(this)
is a general purpose lock. They are similar but not quite the same.
You are right in that you could use synchronized(this)
instead of ReentrantReadWriteLock
but the opposite is not always true.
If you'd like to better understand what makes ReentrantReadWriteLock
special look up some information about producer-consumer thread synchronization.
In general you can remember that whole-method synchronization and general purpose synchronization (using the synchronized
keyword) can be used in most applications without thinking too much about the semantics of the synchronization but if you need to squeeze performance out of your code you may need to explore other more fine-grained, or special-purpose synchronization mechanisms.
By the way, using synchronized(this)
- and in general locking using a public class instance - can be problematic because it opens up your code to potential dead-locks because somebody else not knowingly might try to lock against your object somewhere else in the program.
Upvotes: 16
Reputation: 2576
Lets assume this code is running in a thread:
private static ReentrantLock lock = new ReentrantLock();
void accessResource() {
lock.lock();
if( checkSomeCondition() ) {
accessResource();
}
lock.unlock();
}
Because the thread owns the lock it will allow multiple calls to lock(), so it re-enter the lock. This can be achieved with a reference count so it doesn't has to acquire lock again.
Upvotes: -2
Reputation: 1119
Synchronized locks does not offer any mechanism of waiting queue in which after the execution of one thread any thread running in parallel can acquire the lock. Due to which the thread which is there in the system and running for a longer period of time never gets chance to access the shared resource thus leading to starvation.
Reentrant locks are very much flexible and has a fairness policy in which if a thread is waiting for a longer time and after the completion of the currently executing thread we can make sure that the longer waiting thread gets the chance of accessing the shared resource hereby decreasing the throughput of the system and making it more time consuming.
Upvotes: 6
Reputation: 62559
You can use reentrant locks with a fairness policy or timeout to avoid thread starvation. You can apply a thread fairness policy. it will help avoid a thread waiting forever to get to your resources.
private final ReentrantLock lock = new ReentrantLock(true);
//the param true turns on the fairness policy.
The "fairness policy" picks the next runnable thread to execute. It is based on priority, time since last run, blah blah
also, Synchronize can block indefinitely if it cant escape the block. Reentrantlock can have timeout set.
Upvotes: 5