java中synchronized与Lock的异同

本文转载自java中synchronized与Lock的异同

前言

synchronized和Lock通过互斥保障原子性，能够保护共享数据以实现线程安全，其作用包括保障原子性、可见性、有序性

常见问题

在平时聊天或者面试过程中，可能会被问到，既然已经有了synchronized了，为什么JSR166小组花这么多时间来开发j.u.c的Lock框架呢，换句话说就是内部锁和显示锁之前有什么区别？

分析

synchronized（内部锁）

java平台中的任何一个对象都有唯一一个与之关联的锁，这种锁称为监视器（Monitor)或者内部锁(Intrinsic Lock),内部锁是通过synchronized关键字实现的，可以用来修饰方法（同步方法、静态方法）、代码块（临界区）

Lock(显示锁)

JDK1.5开始引入的排他锁，默认实现是ReetrantLock，作为一种线程同步机制，其拥有和synchronized相同的语义，并且还提供了一些synchronized不具备的特性

差异

从本质上来讲

synchronized是在JVM层面实现的，

ReetrantLock是java API层面实现的排它锁，系统无法自动释放锁，需要在代码中的finally子句中显示释放，否则会出现锁泄漏

从安全上来讲

内部锁在退出临界出时，会自动释放锁，不会导致锁泄漏

外部锁如果未主动释放锁或者释放代码在finally子句中，容易导致锁泄漏

从使用上来讲

synchronized可以修饰方法，修饰代码块，但是内部锁的申请与释放只能在一个方法内进行，因为代码无法跨方法

Lock，只能修饰代码块，但是它可以发挥面向对象编程的灵活性，显示锁的申请在一个方法，在另一个方法里释放锁

在锁的调度方面

内部锁公平锁，显示锁即支持非公平也支持公平锁

在问题定位方面

线程转储可能无法包含显示锁的相关信息，从而导致问题定位困难。比如果在JDK1.5下线程转储中会包含内部锁的相关信息，不包含显示锁的信息

从性能方面方面

等待同一把内部锁的线程，都在同一个等待队列中，等待系统调度，而ReentrantLock锁，可以通过Condition条件变量，实现分组等待的效果，所以性能表现上更好一些

从其它特性方面

当一个线程在等待获取一个锁时，因为线程活性故障导致其永远无法获取得锁时，使用内部锁的线程会一直傻傻的等待一个无法获得的锁，换句话说，内部锁缺少可中断的特性，

显示锁它拥有与内部锁相同的并发性和内存主义，但是添加了轮询锁、定时锁等候、可中断锁等候一些新特性，使其在激烈争用情况下表现出更好的性能，因为当多线程访问共享资源时，JVM可以将更多的时间用于执行线程上，而不是浪费时间在线程调度上。

• 轮询锁意味着，ReentrantLock支持公平锁，可以通过轮询的方式依次获取锁
• 定时锁等候意味着，线程在N长时间之内无法获取到锁，就会返回false ,表示获取锁失败，tryLock方法，不会像内部锁一样痴痴的等待一个没有结果的未来
• 可中断锁等待，意味着ReentrantLock提供了一种能够中断等待锁的线程的机制，通过lock.lockInterruptibly()来实现这个机制。

如何选择

如果你使用的是JDK1.5的话，在争用不高的时候可以使用内部锁，在争用高的情况下，建议使用显示锁

如果你使用的是JDK1.5+的版本，随着对内部锁的优化（锁消除、锁粗化、偏向锁、自适应锁），两都之间的性能差异已经缩小了很多，如果后期内部锁的这些优化可以应用到显示锁的话，那性能可能就会有很大差距了。

总体上来说，在资源竞争不激烈的情形下，性能稍微比synchronized差点点。但是资源竞争非常激烈的时候，synchronized的性能会下降很多，而ReentrantLock的性能表现仍然比较稳定。

结束语

在工作中，为了保证线程安全我们不一定要使用锁，可以使用一些轻量级的同步工具或者无锁的框架和工具，来提升应用的性能。