一、常用的加锁手段
1. 对不可变（Immutable）的对象进行共享
不可变（Immutable）的对象一定是线程安全的，不需要再采取任何的线程安全保障措施。只要一个不可变的对象被正确地构建出来，永远也不会看到它在多个线程之中处于不一致的状态。多线程环境下，应当尽量使对象成为不可变，来满足线程安全。
不可变的类型：
- final 关键字修饰的基本数据类型
- String
- 枚举类型
- Number 部分子类，如 Integer、Long 和 Double 等数值包装类型，BigInteger 和 BigDecimal 等大数据类型。但同为 Number 的原子类 AtomicInteger 和 AtomicLong 则是可变的。
对于集合类型，可以使用 Collections.unmodifiableXXX() 方法来获取一个不可变的集合，集合一旦初始化，就不能被修改，否则抛出异常。
2. 非阻塞乐观锁
即volatile+CAS实现。
- volatile原理
源于多线程环境下，线程执行过程中会将需要的数据从主存读取到CPU的高速缓存中，而不是直接去读取缓存，修改该数据也是经过高速缓存回写，这就容易造成多线程读取数据版本的不一致，回写途中其他线程访问的话就会得到脏数据。
使用volatile可以避免以上情况，即线程修改并回写共享变量至主存时，通过缓存一致性协议通知其他CPU该变量在缓存当中已失效，其他线程工作时会重新从内存中读取该变量，确保读到的是新版本，此为内存的可见性。
使用volatile可以告通过告诉编译器，通过内存屏障防止对其指令重排，确保取值尽可能的准确。但是，以上不能保证对变量的更改是原子操作，必须通过锁机制来实现。 - CAS（compare and swap）
比较并交换，CAS 指令需要有 3 个操作数，分别是内存地址 V、旧的预期值 A 和新值 B。当执行操作时，只有当 V 的值等于 A，才将 V 的值更新为 B，以一种乐观锁的形式保证原子性和一致性，它也叫非阻塞锁。类似于数据库按照版本号更新记录。
ABA问题，即多个线程在处理时，线程1由A改为B，再改回A，线程2读取第一个A，然后阻塞，恢复后欲将A改成C，这个时候是成功的，它无法识别实际操作的是第二个A。解决的方法是对每一步都加上版本号或者时间戳。
最典型的应用就是atomic包中的类，通常是借助于sun.misc.Unsafe类来完成读取并且加加减减的原子操作，这是一个全部使用native方法实现的类，底层是C语言，而C语言中又嵌套了部分汇编代码，对指定的内存区域进行加锁而实现原子操作，因此效率会优于JVM的加锁。
CAS已演变为一种程序设计思想，意义大于Java中的具体实现，通过Redis实现分布式锁即参考了该思想。
3. 互斥锁
3.1 synchronized
加锁方式：修饰代码块，静态方法，实例方法
作用域：
(1) 修饰代码块时，作用于括号内的对象，见于ConcurrentHashMap；
(2) 修饰静态方法时，作用于所属的类（xx.class）,见于双检锁的单例模式；
(3) 修饰实例方法时，作用于this，即当前的实例，见于HashTable。
原理：JVM实现，由重量级锁逐渐优化为偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减少锁操作的开销。
加锁过程：当多个线程(A/B/C)同时访问一段同步代码时，首先会进入_EntryList队列中，当某个线程A获取到对象的monitor后进入_Owner区域并把monitor中的_owner变量设置为当前线程，同时monitor中的计数器_count加1，即(该线程A)获得锁。线程B/C都进入了_EntryList里面，线程A进入了_Owner。
释放锁过程：
若持有monitor的线程A调用wait()方法，将释放它当前持有的monitor，_owner变量恢复为null，_count自减1，同时线程A进入_WaitSet集合中等待被唤醒。
此时在_EntryList的线程B/C会竞争获取monitor，假设结果是B线程竞争成功并进入了_Owner。线程C留在了_EntryList里面，线程A进入了_WaitSet。
若当前线程B执行完毕也将释放monitor(锁)并复位变量的值，以便其他线程进入获取monitor(锁)。线程B可以通过notify/notifyAll 来唤醒 _WaitSet 的线程A，此时_WaitSet 的线程A 与 _EntryList 的线程C会同时进行锁资源竞争。
注意：1、由于notify唤醒线程具有随机性，甚至导致死锁发生；因此一般建议使用notifyAll。2、不管唤醒一个线程，还是唤醒多个线程，最终获得对象锁的，只有一个线程。如果_EntryList同时存在竞争锁资源的线程，那么被唤醒的线程还需要和_EntryList中的线程一起竞争锁资源。但是JVM保证最终只会让一个线程获取到锁。
3.2 ReentrantLock
实现Lock接口，有以下方法
- lock()：获取锁，如果取不到则当前线程一直阻塞
- tryLock()：获取到锁就立刻返回true，取不到则返回false
- lockInterruptibly()：
如果当前线程未被中断，则获取锁。
如果该锁没有被另一个线程保持，则获取该锁并立即返回，将锁的保持计数设置为 1。
如果当前线程已经保持此锁，则将保持计数加 1，并且该方法立即返回。
如果锁被另一个线程保持，则出于线程调度目的，禁用当前线程，并且在发生以下两种情况之一以前，该线程将一直处于休眠状态：
1）锁由当前线程获得；或者
2）其他某个线程中断当前线程。
如果当前线程获得该锁，则将锁保持计数设置为 1。
如果当前线程：
1）在进入此方法时已经设置了该线程的中断状态；或者
2）在等待获取锁的同时被中断。
则抛出 InterruptedException，并且清除当前线程的已中断状态。
在此实现中，因为此方法是一个显式中断点，所以要优先考虑响应中断，而不是响应锁的普通获取或重入获取。
3.3 区别
- 锁的实现
synchronized 是 JVM 实现的，而 ReentrantLock 是 JDK 实现的。
- 性能
新版本 Java 对 synchronized 进行了很多优化，例如自旋锁等，synchronized 与 ReentrantLock 大致相同。
- 等待可中断
当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情。
ReentrantLock 可使用lock.lockInterruptibly()中断，而 synchronized 不行。
- 公平锁
公平锁是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序FIFO来依次获得锁。
synchronized 中的锁是非公平的，ReentrantLock 默认情况下也是非公平的，但是也可以是公平的，通过初始化的fair参数来设置。
- 锁绑定多个条件
一个 ReentrantLock 可以同时绑定多个 Condition 对象，synchronized相当于只绑定一个 Condition 对象，wait和notifyAll操作针对全局的线程有效，ReentrantLock粒度可以做到更细。
