Synchronized和Lock

两者的线程状态

让我们从Thread dump说起，在我们使用jstack将打印thread stack的时候，如果采用的是Synchronized进行并发控制的话会看到如下的日志：

如果采用的是ReentrantLock，会看到如下的日志：

我们会发现使用Synchronize内置锁使线程阻塞的状态是BLOCKED状态，而使用Lock显示锁使线程阻塞的状态是WAITING状态

BLOCKED 和 WAITING

从操作系统内核来看，线程都是在阻塞态，没有区别。区别在于由谁唤醒，是操作系统，还是另一个线程。那为什么还要区分成BLOCKED和WAITING两个状态呢，主要有以下原因：

1. JVM管理的需要，线程放两个队列里管理，如果别的线程运行出了synchronized这段代码，我只需要去blocked队列，放个出来。而某人调用了notify()，我只需要去waiting队列里取个出来。
2. BLOCKED状态的线程不会被挂起，而是会消耗一定的CPU资源去循环check是否可以执行，WAITING状态的线程则会被挂起
3. 不同的语义需要，一个是被动BLOCKED，一个是主动WATING

线程同步算法

堵塞算法（Blocking Algorithm）

上面提到的不管是Synchronized的BLOCKED，还是Lock的WAITING，对应到操作系统的线程状态都是堵塞，其本质上都是基于锁的堵塞算法。JVM实现堵塞有两种方式，一个是通过JVM的自旋（Spin-Waiting），另一个是使用操作系统中的挂起（Suspend）。在基于锁的算法中，如果一个线程在Spin或者Suspend的时候持有锁，那么其他线程都无法执行下去，也就是被阻塞了

1. 自旋（Spin-Waiting）：自旋也叫忙等（busy-wait），采用这种方式的线程不会被挂起，而是会消耗一定的CPU资源去循环check是否可以执行了。
2. 挂起（Suspend）：挂起是把该线程从CPU的使用中换出，当可用的时候再让其运行。这种换进换出叫着上下文切换，上下文是需要CPU调度开销的

如果自旋开销小于上下文切换开销，则推荐使用自旋，反之使用挂起。也就是说如果竞争不激励，自旋高效；竞争激励，线程等待时间长，挂起更高效。

总结

虽然Synchronized和Lock在同步机制和性能上无差，但是在使用上还是有些差别的，具体比较内容如下：

Synchronized

• 优点：实现简单，语义清晰，便于JVM堆栈跟踪；加锁解锁过程由JVM自动控制，提供了多种优化方案。
• 缺点：不能进行高级功能（定时，轮询和可中断等）。

Lock

• 优点：可定时的、可轮询的与可中断的锁获取操作，提供了读写锁、公平锁和非公平锁
• 缺点：需手动释放锁unlock，不适合JVM进行堆栈跟踪

在一些内置锁无法满足需求的情况下，ReentrantLock可以作为一种高级工具。当需要一些高级功能时才应该使用ReentrantLock，这些功能包括：可定时的，可轮询的与可中断的锁获取操作，公平队列，以及非块结构的锁。否则，还是应该优先使用Synchronized