编辑

哈喽，大家好~我是保护小周ღ，本期为大家带来的是多线程开发中为了保证线程安全而设计锁策略， synchronized 锁—— 1. 既是乐观锁，也是悲观锁 2. 既是轻量级锁，也是重量级锁 3. 轻量级锁是基于自旋锁实现，重量级锁是基于挂起等待锁实现 4. 不是读写锁，是互斥锁 5. 是可重入锁 6. 是非公平锁，确定不来看看嘛~更多精彩敬请期待：保护小周ღ *★,°*:.☆(￣▽￣)/$:*.°★* ‘

编辑

一、锁策略

说到锁，Java 里面常用的锁有 synchronized ，锁的意义在于在多线程并发执行的时候保证线程安全，防止出现 BUG, 造成线程不安全的原因本质上是因为线程的调度是无序的，Java本身不负责调度，是由操作系统按照一定的规则来调度线程，CPU 并发执行，但是由于其他应用程序无法干预系统线程的调度，所以可以认为任务线程的调度是无序的。

锁策略就是设计一种解决线程安全问题的办法，在程序设计中根据业务需求需要去实现一个锁，基本上就是参考常见的锁策略。

1.1 乐观锁和悲观锁

顾名思义：

乐观锁，用来预测接下来的锁冲突概率不大，所谓锁冲突就是多线程针对同一对象加锁，同一时间内只有一个线程可以获取到锁并执行，其他线程阻塞等待锁释放。

悲观锁，用来预测接下来的锁冲突概率很大，这就涉及到程序需要不断的加锁、解锁，所以通常来讲悲观锁纯纯的打工仔，乐观锁工作的机会是比较少的，但是也不绝对。

悲观者总是喜欢将一件事往最坏的情况下预测，并且已经做好了最坏的打算，所以啊即使当那一刻真的来临，可能也会庆幸意料之中吧。

乐观者也许是珍惜当下的心态，每一天开开心心的就好了，即使遇到很不好的事情也能很快释然吧

1.2 轻量级锁和重量级锁

轻量级锁，即：加锁解锁的过程更快更高效。

常常使用在不同的线程交替的执行同步块中的代码（同步代码块指在代码块前加上 synchronized关键字的代码块），这种情况下，用重量级锁是没必要的。轻量级锁所适应的场景是线程交替执行同步块的场合，锁冲突较少的情况，如果出现多线程同时竞争同一把锁，锁冲突严重，那么就会导致轻量级锁膨胀为重量级锁。锁的强度对线程的状态的影响也是不同的。

重量级锁，即：加锁解锁的过程更慢更低效

运用的场景那必然是多线程同时竞争同一对象锁，锁冲突严重，其他线程阻塞等待锁释放，当对象锁释放的时候，因锁竞争而阻塞等待的线程就会被唤醒，继续竞争锁，没有抢到的线程又会继续阻塞等待，如此以往，对资源还是有一定的消耗的。

线程阻塞等待即：该线程暂时不参与系统的调度，也就不会被 CPU 执行了。

1.3 自旋锁和挂起等待锁

轻量级锁是基于自旋锁的一种实现，当多线程对同一对象锁进行竞争的时候，就会造成锁冲突，但是如果这种冲突并不严重的话，比如两个线程竞争，不是你就是我的，那没竞争到锁的另一个线程此时不会 “阻塞等待 ”，而是不断的循环尝试获取锁，当然这也会浪费CPU 的执行资源（也就是忙等状态），但是当锁释放的时候，自旋等待的线程能够第一时间获取到锁。

重量级锁是基于挂起等待锁的一种实现，也就是锁冲突比较严重的状态，例如：有10 个线程竞争同一把对象锁，同一单位时间内只有一个线程能拿到锁并执行，那如果 10 个线程都自旋等待那就是得不偿失的，CPU 还得是并发的执行他们，让他们一直保持随时获取锁的状态，这消耗是得不偿失的，所以当锁冲突比较严重的时候直接让等待获取锁状态的线程进入阻塞等待，暂时不参与CPU的调度执行, 虽然会有唤醒线程，带来的开销，但是相较于一直并发执行这些线程，就大大降低了CPU 的开销。CPU 每秒钟可执行几十亿条指令。

编辑

基准速度：1 GHz 等于一秒10 亿条指令。

针对以上三种锁策略： synchronized 这把锁具有那些属性呢？

synchronized 既是悲观锁，也是乐观锁，既是轻量级锁，也是重量级锁，轻量级锁基于自旋锁实现，重量级锁基于挂起等待锁实现。

synchronized 会根据当前锁竞争的程度，自适应的转化锁属性，如果锁冲突不激烈，是以乐观锁或乐观锁的状态运行，如果锁冲突激烈，以悲观锁或重量级锁的状态运行。

1.4 互斥锁和读写锁

互斥锁：

在多线程编程中，引入了对象互斥锁的概念，来保证共享数据操作的完整性。每个对象都对应于一个可称为" 互斥锁" 的标记，这个标记用来保证在任一时刻，只能有一个线程访问该对象。

多线程对同一对象（synchronized 修饰的代码块）进行操作就会发生锁竞争，竞争同一把对象锁，那么同一单位时间内只有一个线程能拿到锁并执行，此时其他线程就 “阻塞等待”，线程进入 synchronized 修饰的代码块就意味着获取到锁了，然后加锁，出代码块释放锁，解锁。实现一种互斥访问，不是你执行就是我执行，不管谁先进入，其他人都不能继续执行了。

读写锁：

顾名思义就是对读、写操作加锁。

在线程的环境下如果多个线程同时读数据不会有线程安全问题，如果多线程允许同时对一个变量的值进行修改，那完了，你改我也改（例如：对同一变量进行自增操作，两个线程同时读取的数据是一样的，但是如果写的时候线程1 先调度执行，修改完毕，写回内存，然后线程2 调度执行，修改完毕写回内存，那线程 2 修改后的值就会把线程 1 的值覆盖掉）很可能就对数据的有效性造成重大的影响。

所以读写锁的属性：

1. 读锁和读锁之间不会产生锁竞争

2. 写锁和写锁之间有锁竞争，同一单位时间内只有一个线程能拿到锁并执行写操作

3. 读锁和写锁之间也会有锁竞争，同一单位时间内只有一个线程能拿到锁并执行读操作，然后执行写操作

Java 标准库中提供了两个专门的读写锁，读写锁是使用 ReentrantReadWriteLock 类来实现的

ReentrantReadWriteLock.ReadLock 表示读锁，它提供了 lock 方法进行加锁、unlock 方法进行解锁。
ReentrantReadWriteLock.WriteLock 表示写锁，它提供了 lock 方法进行加锁、unlock 方法进行解锁。

1.5 可重入锁和不可重入锁

如果一个线程执行 synchronized 修饰的代码块，意味着该线程获取到了对象锁，其他线程因无法获取对象锁而进入阻塞等待，等待锁释放，此时，如果该线程又执行到了 synchronized 修饰的代码块，是两个代码块嵌套的情况，而且使用的是同一个对象锁，概念是，一个对象只有一把锁，那么线程刚进入 synchronized 的代码块就获取了这把锁，此时又遇到需要获取该对象锁的情况，那么线程就有两种情况：

1. 骂骂咧咧的说谁把锁抢走了，气死我了，进入阻塞等待（死锁），因为谁拿到锁，就由谁释放锁，线程进入 synchronized 修饰的代码块获取锁，出 synchronized 修饰的代码块就会释放锁，这个时候别的线程就可以获取锁，现在这种情况是线程手里拿着锁，还没释放锁，又遇到需要获取该对象锁的情况，那他就会阻塞等待锁释放，产生了死锁问题，这就叫做不可重入锁。

2. 由于线程手上有该对象锁，所以再遇到需要获取该对象锁的情况就直接验证一下是否是该锁的拥有者，如果是则允许进入，不会产生死锁问题，这就是是可重入锁。

Object locker = new Object(); // 使用第三方对象锁
synchronized(locker) {  //线程获取 locker 对象锁
   //线程再次获取 locker 对象锁，此时锁已经被线程获取了还未释放，就会有两种结果
   synchronized(locker) {
   }
}