前言

        锁的策略：加锁过程中，即处理冲突的过程中，需要涉及到的一些不同的处理方式（此处锁策略并不是java独有的），本篇内容主要是讲解一下关于锁的相关知识点；

1. 关于锁的分组

1.1 第一组：乐观锁和悲观锁

------>这是两种不同的锁的实现方式

        乐观锁：在加锁之前，预估当前出现锁冲突的概率不大，因此在进行加锁的时候不会做太多的工作。加锁过程中做的事情比较少，加锁的速度可能更快，但是更容易引入一些其他的问题（即可能会消耗更多的cpu资源）

        悲观锁：在加锁之前，预估当前出现锁冲突的概率比较大，因此在进行加锁的时候会做更多的工作，因为做的事情更多，所以加锁的速度回更慢，但是整个过程中不容易出现其他的问题。

1.2 第二组：轻量级锁和重量级锁

        轻量级锁，加锁的开销更小，加锁的速度更快--->轻量级锁，一般都是乐观锁

        重量级锁，加锁的开销更大，加锁的速度更慢--->轻量级锁，一般都是悲观锁

        轻量重量是加锁之后对结果的评价，悲观乐观，是加锁之前，对未来的事情进行的预估,根据整体来说，这两种角度，描述的都是同一个事情；

1.3 第三组：自旋锁和挂起等待锁

        自旋锁：是轻量级锁的一种典型实现；加锁的时候，如果加锁失败，不会就此阻塞放弃cpu，而是相当于添加一个while循环，不停的进行锁竞争，这次锁竞争失败了就再次进入循环竞争锁，直到加锁成功，才退出循环。

        这种反复快速的执行，就称为 “自旋”，故此自旋锁也是乐观锁，使用自旋锁的前提是预期锁冲突概率不大，只要其他线程释放了锁，它就能第一时间加锁成功；但如果有很多线程要加锁，就必要使用自旋锁了，因为会浪费cpu资源。

        等待挂起锁：是重量级锁的一种典型体现，也是悲观锁；加锁的时候，如果加锁失败，就会等待一段时间，这段时间它不会去进行加锁操作和别的线程锁竞争，故此就能把一些cpu资源让出来，被让出来的这些cpu资源可以干一些其他事情，等一段时间过后，会再次尝试加锁，如果失败还是重复以上工作，直到最后成功拿到锁；

        当等待挂起的时候，会有内核调度器介入，所以就需要完成的操作就多了，从而要获取锁的时间花费也更多一些。

Q：java中的synchronized算以上锁的哪种情况？

A：synchronized具有自适应能力，且synchronized在某些情况下是乐观锁，轻量级锁，自旋锁；但是在某些情况下时悲观锁，重量级锁，等待挂起锁，当然系统内部会自动的评估当前锁冲突的激烈程度；

        如果当前锁冲突的激烈程度不大，就处于乐观锁\轻量级锁\自旋锁；

        如果当前锁冲突的激烈程度很大，就处悲观锁锁\重量级锁\等待挂起锁；

1.4 第四组： 普通互斥锁和读写锁

        普通互斥锁：类似synchronized这种，操作涉及到加锁、解锁

        读写锁：这里加锁的情况分为两种：加读锁，加写锁

        读锁和读锁之间，不会出现锁冲突（不会阻塞）；写锁和写锁之间，会涉出现锁冲突（会阻塞）；读锁和写锁之间，会出现锁冲突（会阻塞）；当一个线程加读锁时，另一个线程只能读，不能写；当一个线程加写锁时，另一个线程不能写，也不能读

Q:为啥要引入读写锁？

A:     如果两个线程读，本身就是线程安全的，不需要进行互斥；

        如果使用synchronized这种方式加锁，两个线程读与会产生互斥（阻塞），对于性能有一定的损耗，完全给读操作不加锁，就怕连个线程一个是读线程，一个是写线程，这样更加会涉及锁冲突；如上所述，读写锁能很好地解决上述的问题

         java标准库中，也提供了专门的类，来实现读写锁（读写锁本质上还是系统提供的读写锁，系统提供api，jvm中将api进行封装给我们使用），注意synchornized不是读写锁；

1.5 第五组：公平锁和非公平锁

        此处的公平即遵循先来后到的规则才是公平；

        公平锁：如果线程和线程之间，锁竞争的时间大小不一样，按照锁竞争时间久的线程先拿到锁，有先后顺序（先来后到的意思）

       非公平锁：线程和线程之间没有拿锁顺序，随机调度，各凭各的本事拿锁。

        这里使用公平锁，就能很好的解决线程饿死的这一问题。而要想实现公平锁，就需要引入额外的数据结构（引入队列，记录每个线程的先后顺序），才能实现公平锁。

1.6 第六组：可重入锁和不可重入锁

        可重入锁：如synchronized，加锁一段代码，锁里面可以再进行一次加锁，锁里面可以嵌套多个锁，里面是用计数器这种方式对加锁的数量进行计数，并判断是否解锁，是可重入锁。

        不可重入锁：系统自带的锁，不能连续加锁两次。

1.7 synchronized和Linux基于特定锁的简单比较

        下面来说明一下synchronized和系统自带的锁的具体锁；
synchronized：乐观锁 / 悲观锁自适应

                        轻量级锁 / 重量级锁自适应

                        自旋锁 / 挂起等待所自适应

                        不是读写锁

                        非公平锁

                        可重入锁

linux提供的mutex（系统自带的锁）：          

                        悲观锁

                        重量级锁

                        挂起等待所

                        不是读写锁

                        非公平锁

                        不可重入锁

 

2. 细说synchronized的自适应

        Synchronized的加锁过程，自适应如下所述：

        当线程执行到synchronized的时候，如果这个对象处于未加锁的状态，就会经历一下的过程：

2.1 锁升级

        1、偏向锁阶段

        核心思想：“懒汉模式”，就是能不加锁，就不加锁；所谓的偏向锁，并不是真的加锁了，只是做了个非常轻量的标记。

        一旦有线程来竞争这个锁，持有偏向锁的线程能第一时间拿到这个锁，如果没有其他线程竞争锁，下次还是拿到锁的线程大概率还是持有偏向锁的线程。

        总的来说，当有锁竞争的情况下，偏向锁没有提高效率，在没有锁竞争的情况下，偏向锁就能大幅度的提高效率了。

        这个标记是锁里面的一个属性，每个锁都有自己的标记，当锁对象首次加锁是，没有涉及到锁竞争，这个阶段就是偏向锁阶段，一旦涉及到锁竞争，就会升级成轻量级锁阶段。

        2、轻量级锁阶段

        此处的轻量级锁就是通过自旋的方式实现的。假设有锁竞争，但不多的时候，就会处于轻量级锁阶段，它的优势：当其他线程释放锁了，处于轻量级锁阶段的线程能第一时间拿到锁；劣势：比较消耗cpu资源，因为是自旋的方式实现的，会有个循环一直尝试拿锁。

        当线程多了，轻量级锁就不合适了，每个线程都循环尝试拿锁，但如果已经有线程拿到锁了，其他线程要阻塞等待，但等待的这过程是会有循环不断的尝试拿锁，这里消耗的cpu资源就很多了。这时，就会从轻量级锁阶段升级成重量级锁阶段。

        3、重量级锁阶段
        此处的重量级锁是用挂起等待的方式实现的，当有很多线程同时去竞争这个锁时，有个线程拿到锁了，其他线程没拿到，就会阻塞等待，等待一段时间再去尝试拿锁，不成功再阻塞等待一段时间，循环以上步骤，如此就会让出cpu的资源，可以利用这些cpu资源干一些其他的事。

        注意：当前版本此处只能升级，不能降级。

2.2 锁消除 

        锁消除是synchronized的内部优化；

        有时候，有些代码可以一眼看上去就不用加锁，但是代码加锁了，这时候，编译器就会把这个锁给消除掉，毕竟加锁操作也是要消耗一些硬件资源的。

        注意：锁消除和偏向锁的区别

        锁消除：针对能够一眼就看出不涉及到线程安全问题的代码，编译器能够把锁给消除掉。

        偏向锁：是已经运行代码了，才知道没有锁竞争。

2.3 锁粗化

        通常情况下，我们更偏好于让锁更细一些，这样更有利于并发编程的时候解决线程安全问题；但有时候，让锁更粗写能提高效率，会希望锁粗点。

        锁粗化：把多个细粒度的锁合并成一个粗粒度的锁。如下图所示：

        一段代码中，频繁的加锁解锁，肯定会消耗更多的硬件资源，但是如果能把一段代码的多个加锁、解锁操作，优化成只有一次加锁、解锁，这样也能提高效率。

ps：关于多线程中锁策略的内容就到这里了，如果对你有所帮助的话，就请一键三连哦！！！