synchronized和ReentrantLock区别

今天有一个任务要用到同步锁机制，偶然看到 ReentrantLock这个类，于是乎查看了ReentrantLock的作用与区别。

使用锁目的：不论什么时候，只要您将编写的变量接下来可能被另一个线程读取，或者您将读取的变量最后是被另一个线程写入的，那么您必须进行同步。

不论什么时候，只要您将编写的变量接下来可能被另一个线程读取，或者您将读取的变量最后是被另一个线程写入的，那么您必须进行同步。

 使用区别：

synchronized 功能性的限制 —— 它无法中断一个正在等候获得锁的线程，也无法通过投票得到锁，如果不想等下去，也就没法得到锁。同步还要求锁的释放只能在与获得锁所在的堆栈帧相同的堆栈帧中进行，多数情况下，这没问题（而且与异常处理交互得很好），但是，确实存在一些非块结构的锁定更合适的情况

一般使用在代码块中，先定义一个抽象对象lockObject，如

private static Map<Object,Object> smap = com.google.common.collect.Maps.newConcurrentMap();

synchronized (lockObject) { 
  // update object state
}

 

ReentrantLock 它拥有与 synchronized 相同的并发性和内存语义，但是添加了类似锁投票、定时锁等候和可中断锁等候的一些特性。此外，它还提供了在激烈争用情况下更佳的性能。（换句话说，当许多线程都想访问共享资源时，JVM 可以花更少的时候来调度线程，把更多时间用在执行线程上。）

一般也是代码块中，如，但是一定在 finally 中释放锁 lock.unlock(); 

Lock lock = new ReentrantLock();
lock.lock();
try { 
  // update object state
}
finally {
  lock.unlock(); 
}

 

除此之外，与目前的 synchronized 实现相比，争用下的 ReentrantLock 实现更具可伸缩性。（在未来的 JVM 版本中，synchronized 的争用性能很有可能会获得提高。）这意味着当许多线程都在争用同一个锁时，使用 ReentrantLock 的总体开支通常要比 synchronized 少得多。

 

synchronized关键字参数必须是Object类型，不能是简单数据类型，要包装类Integer等

synchronized关键字锁住对象时，静态方法中不能使用this，因为类不是静态的