JDK 1.6 synchronized 锁优化

在进行并发操作时为保证线程安全会使用各种锁，此文初步介绍各种锁的概念。

1. 悲观锁 (阻塞同步)

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞（非旋转）直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized（JDK 1.6 以前）和ReentrantLock等独占锁就是悲观锁思想的实现。

读/写锁属于悲观锁：

• 排它锁（Exclusive），简写为 X 锁，又称写锁。
• 共享锁（Shared），简写为 S 锁，又称读锁。
• 一个事务对数据对象 A 加了 X 锁，就可以对 A 进行读取和更新。加锁期间其它事务不能对 A 加任何锁。
• 一个事务对数据对象 A 加了 S 锁，可以对 A 进行读取操作，但是不能进行更新操作。加锁期间其它事务能对 A 加 S 锁，但是不能加 X 锁。

2. 乐观锁 （非阻塞同步）

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制或CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

CAS（Compare and swap）（比较并交换）

• CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。
• CAS可以用一条CPU指令来完成，从最低层上实现CAS操作的原子性。
• CAS不能避免ABA问题（被其他线程两次操作重新变回原值），如果需求依赖过程值则可以用版本号机制来解决此问题。

两种锁的使用场景

从上面对两种锁的介绍，我们知道两种锁各有优缺点&#x