When I run the example class at http://javarevisited.blogspot.in/2013/03/reentrantlock-example-in-java-synchronized-difference-vs-lock.html, I'm seeing the same behavior as with synchronized
.
Here are three ways, methods, of a thread accessing a lock and one for letting go of the lock. You might want to try implementing these using the synchronized
keyword. The extended capabilities and advantages of using ReentrantLock
will become apparent.
public class DoorLockUsingLock {
private int counter= 0;
private Thread owner= null;
private Lock l = new ReentrantLock();
private Condition notLocked= l.newCondition();
public void lockItDown() throws InterruptedException {
l.lockInterruptibly();
try {
while ((counter> 0) && (owner!= Thread.currentThread())) {
notLocked.await();
}
counter++;
owner = Thread.currentThread();
} finally {
l.unlock();
}
}
public void lockItDownUninterruptibly() {
l.lock();
try {
while ((counter > 0) && (owner != Thread.currentThread())) {
notLocked.awaitUninterruptibly();
}
counter++;
owner= Thread.currentThread();
} finally {
l.unlock();
}
}
public boolean tryLockItDown(long timeout, TimeUnit unit) throws InterruptedException {
long time = unit.toNanos(timeout);
long end = System.nanoTime() + time;
boolean success = l.tryLock(timeout, unit);
if (!success) {
return false;
}
try {
time = end- System.nanoTime();
while ((counter> 0) && (owner != Thread.currentThread()) && (time > 0)) {
notLocked.await(time, TimeUnit.NANOSECONDS);
time = end - System.nanoTime();
}
if (time > 0) {
counter++;
owner = Thread.currentThread();
return true;
}
return false;
} finally {
l.unlock();
}
}
public void unlockIt() throws IllegalMonitorStateException {
l.lock();
try {
if (counter== 0) {
throw new IllegalMonitorStateException();
}
if (owner!= Thread.currentThread()) {
throw new IllegalMonitorStateException();
}
counter--;
if (counter == 0) {
owner = null;
notLocked.signal();
}
} finally {
l.unlock();
}
}
}
ReentrantLock
also allows for unconditional, polled, timed, or interruptible lock acquisition. It is not possible too exit intrinsic locks that are deadlocked short from restarting the JVM. –
Alnico From the JavaDoc of the ReetrantLock class:
A reentrant mutual exclusion
Lock
with the same basic behavior and semantics as the implicit monitor lock accessed usingsynchronized
methods and statements, but with extended capabilities.
In your example, you do not use the "extended capabilities"; you use the ReentrantLock
as an equivalent alternative to the synchronized
method (except that with the synchronized
statement, you use this
as the lock). So the two methods must behave the same.
ReentrantReadWriteLock
that's can be useful. That would be annoying to implement with synchronized
. –
Mcdonough No, you generally won't see a difference in behavior. But as the website says, there are a couple cases you'll want to use a ReentrantLock
instead of synchronized
.
- You want waiting threads to be fairly selected.
- You want to use the tryLock() method.
- You want to interrupt a waiting thread and have it do something else.
- The performance of ReentrantLock is better than synchronized, and you care about that.
If you don't need any of those improvements, using synchronized
is just fine, and you may not be able to tell the difference.
© 2022 - 2024 — McMap. All rights reserved.
synchronized
,wait
, andnotify
behavior.ReentrantLock
andCondition
cleaned up the semantics and allow for fairness, but are otherwise mostly the same. – Mcdonough