我试图理解什么使得锁在并发如此重要，如果一个人可以使用同步(这)。在下面的虚拟代码中，我可以这样做:
同步整个方法或同步脆弱区域(Synchronized (this){…})
或者使用ReentrantLock锁定易受攻击的代码区域。
代码:
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;
}
ReentrantReadWriteLock是一个专用锁，而synchronized(this)是一个通用锁。它们很相似，但不完全相同。
你是对的，你可以使用synchronized(this)来代替ReentrantReadWriteLock，但相反的情况并不总是正确的。
如果您想更好地理解ReentrantReadWriteLock的特殊之处，请查阅一些关于生产者-消费者线程同步的信息。
一般来说，您可以记住，在大多数应用程序中都可以使用全方法同步和通用同步(使用synchronized关键字)，而无需过多考虑同步的语义，但如果您需要从代码中挤出性能，则可能需要探索其他更细粒度的或特殊用途的同步机制。
顺便说一下，使用synchronized(this)——以及使用公共类实例的一般锁定——可能会有问题，因为它会导致代码出现潜在的死锁，因为其他人可能会在不知情的情况下尝试锁定程序中的其他地方的对象。
从oracle文档页关于ReentrantLock:
一个可重入互斥锁，其基本行为和语义与使用同步方法和语句访问的隐式监视锁相同，但具有扩展功能。
A ReentrantLock is owned by the thread last successfully locking, but not yet unlocking it. A thread invoking lock will return, successfully acquiring the lock, when the lock is not owned by another thread. The method will return immediately if the current thread already owns the lock.
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键的特性如本文所述
能够可中断地锁定。
能力超时，而等待锁定。
创造公平锁的权力。
API来获取等待锁的线程列表。
灵活地尝试锁定而不阻塞。
你可以使用ReentrantReadWriteLock。ReadLock ReentrantReadWriteLock。WriteLock以进一步获得对读写操作的粒度锁的控制。
看看Benjamen关于不同类型ReentrantLocks使用的文章吧
