005 - Java锁分类

悲观锁是就是悲观思想，即认为写多，

认为写多，每次拿数据的时候认为别人会修改，所以每次在读写数据时都会上锁，这样别人想读这个数据就会block，直到拿到锁为止。 

它总认为最坏的情况可能会出现，它认为数据很可能会被其他人所修改，

所以悲观锁在持有数据的时候总会把资源或者数据锁住，这样其他线程想要请求这个资源的时候就会阻塞，直到等到悲观锁把资源释放为止。

遇到并发写的可能性高，每次去拿数据时都认为别人会修改，所以每次在读写数据的时候都会上锁，这样别人想读写这个数据就会block，直到拿到锁。

比如行锁，表锁等，

读锁，写锁等

悲观锁因为对读写都加锁，所以它的性能比较低

悲观锁，不仅会对写操作加锁，还会对读操作加锁

select * from student where name="burt”for update

这条sql语句从Student表中选取name=burt的记录并对其加锁， 

那么其他写操作再这个事务提交之前，都不会对这条数据进行操作，起到了独占和排他的作用。

Synchronized

ReentrantLock等独占锁(排他锁) 

互斥锁

对于现在互联网提倡的三高(高性能、高可用、高井发)来说，悲观锁的实现用的越来越少了

但是一般多读的情况下还是需要使用悲观锁的

因为虽然加锁的性能比较低，但是也阻止了像乐观锁一样，遇到写不一致的情况下一直重试的时间。

它总认为资源和数据不会被别人所修改，所以读取不会上锁，

但是在进行写入操作时，会判断当前数据是否被修改过  

乐观锁是一种乐观思想，即认为读多写少

版本号机制

CAS算法实现

JUC

atomic包下面的原子变量类

因为虽然加锁的性能比较低，但是也阻止了像乐观锁一样，遇到写不一致的情况下一直重试的时间。

乐观锁多适用于多读的应用类型， 这样可以提高吞吐量。

典型的，比如说成本系统

任何事情都是有利也有弊，软件行业没有完美的解决方案，只有最优的解决方案，所以乐观锁也有它的弱点和缺陷

ABA问题

循环开销大

CAS，适用于写比较少的情况下(多读场景， 冲突一般较少) ，

synchronized，适用于写比较多的情况下(多写场景，冲突一般较多

对于资源竞争较少(线程冲突较轻) 的情况

对于资源竞争严重(线程冲突严重) 的情况，

由于在多处理器环境中某些资源的有限性， 有时需要互斥访问(mutual exclusion) ， 这时候就需要引入锁的概念，

只有获取了锁的线程才能够对资源进行访问， 由于多线程的核心是CPU的时间分片， 所以同一时刻只能有一个线程获取到锁，

那么就面临一个问题，那么没有获取到锁的线程应该怎么办?有两种处理方式

当一个线程尝试去获取某一把锁时，如果这个锁此时已经被别人获取(占用)，

那么此线程就无法获取到这把锁，该线程将会等待，间隔一段时间后会再次尝试获取。

这种采用循环加锁->等待的机制被称为自旋锁(spinlock) .

自旋锁获取示意图

比较简单，

如果持有锁的线程能在短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞状态，

它们只需要等一等(自旋)，等到持有锁的线程释放锁之后即可获取，这样就避免了用户进程和内核切换的消耗。

优点

缺点

自旋锁的代码实现

这种简单的自旋锁有一个问题：无法保证多线程竞争的公平性。

对于上面的Spinlock Test， 当多个线程想要获取锁时， 谁最先将available设为false谁就能最先获得锁，

这可能会造成某些线程一直都未获取到锁造成线程饥饿。

就像我们下课后蜂拥的跑向食堂，下班后蜂拥地挤向地铁，通常我们会采取排队的方式解决这样的问题

JDK1.6中

JDK1.7后

因为自旋锁避免了操作系统进程调度和线程切换

由于这个原因，操作系统的内核经常使用自旋锁。

但是，如果长时间上锁的话，自旋锁会非常耗费性能，它阻止了其他线程的运行和调度。

线程持有锁的时间越长， 则持有该锁的线程将被OS(Operating System) 调度程序中断的风险越大。

如果发生中断情况， 那么其他线程将保持旋转状态(反复尝试获取锁)，

而持有该锁的线程并不打算释放锁，这样导致的是结果是无限期推迟，直到持有锁的线程可以完成并释放它为止，

自旋锁的目的是为了占着CPU的资源不释放，等到获取到锁立即进行处理。但是如何去选择自旋的执行时间呢？如果自旋执行时间太长，会有大量的线程处于自旋状态占用CPU资源，进而会影响整体系统的性能。因此自旋的周期选的额外重要！

JVM对于自旋周期的选择，jdk1.5这个限度是一定的写死的，在1.6引入了适应性自旋锁，适应性自旋锁意味着自旋的时间不在是固定的了，而是由前一次在同一个锁上的自旋时间以及锁的拥有者的状态来决定，基本认为一个线程上下文切换的时间是最佳的一个时间，同时JVM还针对当前CPU的负荷情况做了较多的优化，如果平均负载小于CPUs则一直自旋，如果有超过(CPUs/2)个线程正在自旋，则后来线程直接阻塞，如果正在自旋的线程发现Owner发生了变化则延迟自旋时间（自旋计数）或进入阻塞，如果CPU处于节电模式则停止自旋，自旋时间的最坏情况是CPU的存储延迟（CPU A存储了一个数据，到CPU B得知这个数据直接的时间差），自旋时会适当放弃线程优先级之间的差异。

 线程自旋是需要消耗cup的，说白了就是让cup在做无用功，如果一直获取不到锁，那线程也不能一直占用cup自旋做无用功，所以需要设定一个自旋等待的最大时间。 如果持有锁的线程执行的时间超过自旋等待的最大时间扔没有释放锁，就会导致其它争用锁的线程在最大等待时间内还是获取不到锁，这时争用线程会停止自旋进入阻塞状态。

解决上面这种情况一个很好的方式是给自旋锁设定一个自旋时间，等时间一到立即释放自旋锁。

自旋锁的目的是占着CPU资源不进行释放， 等到获取锁立即进行处理。

意味着自旋时间不是固定的了，而是由前一次在同一个锁上的自旋时间以及锁拥有的状态来决定，

基本认为一个线程上下文切换的时间是最佳的一个时间。

TicketLock是什么？

底层结构

TicketLock实际应用场景

TicketLock的设计原则

下面来实现一下这个票据排队方案

但是上面这个设计是有问题的

TicketLock的优点

TicketLock的缺点

由来

是什么？

底层结构

代码

由来

是什么？

代码

都是基于链表， 不同的是， 

将获取锁的线程状态借助节点(node) 保存， 每个线程都有一份独立的节点， 这样就解决了Ticket Lock多处理器缓存同步的问题.

当多个线程同时访问同一个数据时，很容易出现问题。

为了避免这种情况出现，我们要保证线程同步互斥，就是指并发执行的多个线程，在同一时间内只允许一个线程访问共享数据。

Java中可以使用synchronized关键字来取得一个对象的同步锁。

在Java语言中，每一个对象有一把锁。

线程可以使用synchronized关键字来获取对象上的锁。

可以把任意一个非NULL的对象当作锁。

属于独占式的悲观锁，同时属于可重入锁。

监视器锁（monitor）是依赖于底层的操作系统的Mutex Lock来实现的，

而操作系统实现线程之间的切换时，需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高

重锁

作用于实例方法

作用于静态方法

作用于代码块

对象

锁膨胀

线程中断与synchronized

等待唤醒机制与synchronized

作用于方法(显式同步)

作用于代码块(隐式同步)

特性保证

Synchronized核心组件，ObjectMontior

Synchronized实现

参考：https://blog.csdn.net/zqz_zqz/article/details/70233767

synchronized是悲观锁， 在操作同步之前需要给资源加锁， 这把锁就是对象头里面的，

Java对象头是什么呢?

下面我们以32位虚拟机为例， 来看一下其Mark Word的字节具体是如何分配的

中文翻译版本：32位虚拟机对象头分配情况

关于为什么这么分配的内存， 我们可以从Open JDK中的markOop.hpp类中的枚举窥出端倪

synchronized是悲观锁， 在操作同步之前需要给资源加锁， 这把锁就是对象头里面的，

synchronized用的锁记录是存在Java对象头里的。

JVM基于进入和退出Monitor对象，来实现方法同步和代码块同步。

任何对象都有一个monitor与之关联， 当且一个monitor被持有后， 它将处于锁定状态。

代码块同步是使用两个指令实现

监视器锁(monitor)是什么？

底层实现

Java语言专门针对synchronized关键字设置了四种状态

锁的状态总共有四种：无锁状态、偏向锁、轻量级锁和重量级锁。

锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态。

锁可以升级，但不能降级

Java SE 1.6/JDK 1.6

对象空间头分配情况图

无锁状态

无锁的特点

图解无锁的对象头

可以通过-XX：-UseBiasedLocking=false来禁用偏向锁

JDK 1.6提出

偏向锁是什么？

图解偏向锁的对象头

偏向锁的获取过程

全局安全点(SafePaint) 

epoch值

图解偏向锁的获取过程

关闭偏向锁

JDK 1.6提出

轻量级锁是什么？

轻量锁详细获取过程

图解轻量锁详细获取过程

监视器锁(monitor)

重量级锁

重量级锁的获取流程

图解重量锁详细获取过程

这就好比食堂排队打饭的模型

【理想情况】

【现实情况】

除非程序有特殊需要，否则最常用非公平锁的分配机制。

加锁时，不考虑排队等待问题，直接尝试获取锁，获取不到自动到队尾等待

非公平锁实际执行的效率要远远超出公平锁

非公平锁性能比公平锁高5~10倍

因为公平锁需要在多核的情况下维护一个队列

是什么？

ReentrantLock的可重入性

ReentrantLock的构造方法

锁的公平性不能保证线程调度的公平性

tryLock方法不支持公平性

推荐使用下面的代码来进行加锁和解锁

锁的公平性实例代码

ReetrantLock的构造函数

FairSync

Sync

AQS

ReentrantLock是可以实现锁的公平性的， 那么原理是什么呢?

通过其源码来了解一下ReentrantLock是如何实现锁的公平性的

跟踪其源码发现， 调用Lock.lock()方法，其实是调用了sync的内部的方法

sync

综上

与公平性相对的就是非公平性， 通过设置fair参数为true， 便实现了一个公平锁，

 与之相对的， 把fair参数设置为false， 是不是就是非公平锁了?用事实证明一下

private ReentrantLock lock = new ReentrantLock(false) ；

其他代码不变，执行一下看看输出(部分输出)

又称为递归锁

指在同一个线程，在外层方法获取锁时，再进入该线程的内层方法会自动获取锁(前提锁对象得是同一个对象或者class) 

不会因为之前已经获取过，还没释放，而阻塞

Java中Reentrant Lock和synchronized都是可重入锁

在一定程度上可以避免死锁。

每个锁关联

当计数器为0时，表示该锁没有被任何线程持有，那么任何线程都可以获得该锁而调用方法。

当一个线程请求成功后，JVM会记下持有锁的线程，并将计数器记为1。

此时其它线程请求该锁，则必须等待，而持有锁的线程如果再次请求这个锁，就可以再次拿到锁，同时计数器会递增。

当线程退出一个synchronized方法/块时，计数器会递减。

如果计数器为0，则释放该锁

代码来说明一下synchronized的可重入性

在上面这段代码中， 对doSomething和doSomethingElse分别使用了synchronized进行锁定，

 doSomething方法中调用了doSomethingElse方法， 因为synchronized是可重入锁， 

所以同一个线程在调用doSomething方法时， 也能够进入doSomethingElse方法中。

可重入锁，也叫做递归锁

指的是同一线程 外层函数获得锁之后 ，内层递归函数仍然有获取该锁的代码，但不受影响。

线程得到一个对象锁后再次请求该对象锁，是允许的

实现方法

本文里面讲的是广义上的可重入锁，而不是单指JAVA下的ReentrantLock。

ReentrantLock可重入锁

synchronized和 Lock、ReentrantLock的区别

Sync是继承于AQS子类的，

AQS是并发的根本

这种结构在其他JUC包的工具类里面也都存在，主要有这么五类

读锁的共享锁可保证井发读非常高效，而读写、写读、写写的过程互斥 

因为读锁和写锁是分离的， 所以ReentrantReadWriteLock的井发性相比一般的互斥锁有了很大提升

Hotspot的作者经过以往的研究发现大多数情况下锁不仅不存在多线程竞争，而且总是由同一线程多次获得。

偏向锁的目的是在某个线程获得锁之后，消除这个线程锁重入（CAS）的开销，看起来让这个线程得到了偏护。

引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令（由于一旦出现多线程竞争的情况就必须撤销偏向锁，所以偏向锁的撤销操作的性能损耗必须小于节省下来的CAS原子指令的性能消耗）。

上面说过，轻量级锁是为了在线程交替执行同步块时提高性能，而偏向锁则是在只有一个线程执行同步块时进一步提高性能。

CAS操作:将线程ID保存在对象的Mark Word中

有其他线程获取对象锁时失效

经验依据：在大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得

CAS操作

锁升级

如果存在同一时间访问同一锁的场合，就会导致轻量级锁膨胀为重量级锁。

经验依据：对绝大部分的锁，在整个同步周期内都不存在竞争

为什么Synchronized效率低的原因？

依赖于操作系统Mutex Lock所实现的锁，称之为“重量级锁”。

JDK中对Synchronized做的种种优化，其核心都是为了减少这种重量级锁的使用。

JDK1.6以后，为了减少获得锁和释放锁所带来的性能消耗，提高性能，引入了“轻量级锁”和“偏向锁”。

对于HashMap而言，最重要的两个方法是get与set方法

如果对整个HashMap加锁，可以得到线程安全的对象，但是加锁粒度太大。

ConcurrentHashMap 和 HashMap 思路是差不多的，但是因为它支持并发操作，所以要复杂一些。

Segment的大小也被称为ConcurrentHashMap的并发度。

减小锁粒度是指缩小锁定对象的范围，从而减小锁冲突的可能性，从而提高系统的并发能力。

将大对象（这个对象可能会被很多线程访问），拆成小对象，大大增加并行度，降低锁竞争。

降低了锁的竞争，偏向锁，轻量级锁成功率才会提高。

减小锁粒度是一种削弱多线程锁竞争的有效手段，

这种技术典型的应用是ConcurrentHashMap类的实现。

最最典型的减小锁粒度的案例就是ConcurrentHashMap。

ConcurrentHashMap是学习分段锁的最好实践

ConcurrentHashMap并发

1.7ConcurrentHashMap的组成：segment数组+HashEntry数组(数组+链表)

1.8 ConcurrentHashMap的组成：数组+链表+红黑树

简单理解就是，ConcurrentHashMap 是一个 Segment 数组

Segment 通过继承 ReentrantLock 来进行加锁，所以每次需要加锁的操作锁住的是一个 segment，

这样只要保证每个 Segment 是线程安全的，也就实现了全局的线程安全。

put()

get()

构造函数

remove

size

resize()

分段锁也并非一种实际的锁，而是一种思想

通过分段锁的形式，来细化锁的粒度，从而实现高效的并发操作,

ConcurrentHashMap内部细分了若干个小的HashMap，称之为段(Segment)。

默认情况下一个ConcurrentHashMap被进一步细分为16个段，既就是锁的并发度。

如果需要在ConcurrentHashMap中添加一个新的表项

在多线程环境中，如果多个线程同时进行put操作，只要被加入的表项不存放在同一个段中，则线程间可以做到真正的并行。

为了提高性能，Java提供了读写锁，灵活控制

如果没有写锁的情况下，读是无阻塞的，在一定程度上提高了程序的执行效率。

读写锁分为读锁和写锁，多个读锁不互斥，读锁与写锁互斥，这是由jvm自己控制的，你只要上好相应的锁即可。

读锁

写锁

总之，读的时候上读锁，写的时候上写锁！

Java中读写锁有个接口java.util.concurrent.locks.ReadWriteLock，也有具体的实现ReentrantReadWriteLock。