在并发编程中，多个线程访问同一个共享资源时，我们必须考虑如何维护数据的原子性。
在 JDK1.5 之前，Java 是依靠 Synchronized 关键字实现锁功能来做到这点的。 Synchronized 是 JVM 实现的一种内置锁，锁的获取和释放是由 JVM 隐式实现。
到了 JDK1.5 版本，并发包中新增了 Lock 接口来实现锁功能，它提供了与 Synchronized 关键字类似的同步功能，只是在使用时需要显示获取和释放锁。
Lock 同步锁是基于 Java 实现的，而 Synchronized 是基于底层操作系统的 Mutex Lock 实现的，每次获取和释放锁操作都会带来用户态和内核态的切换，从而增加系统性能开销。因此，在锁竞争激烈的情况下Synchronized 同步锁在性能上就表现得非常糟糕，它也常被大家称为重量级锁。
特别是在单个线程重复申请锁的情况下，JDK1.5 版本的 Synchronized 锁性能要比 Lock 的性能差很多。
例如，在 Dubbo 基于 Netty 实现的通信中，消费端向服务端通信之后，由于接收返回消息是异步，所以需要一个线程轮询监听返回信息。而在接收消息时，就需要用到锁来确保 request session 的原子性。如果我们这里使用 Synchronized 同步锁，那么每当同一个线程请求锁资源时，都会发生一次用户态和内核态的切换。
到了 JDK1.6 版本之后，Java 对 Sy