多线程7

常见锁的策略

锁策略具体的情况

一.悲观锁VS乐观锁

判断条件：加锁的时候，预测当前锁冲突的概率是大还是小

预测当前锁冲突概率大，后续要做的工作往往就会更多.加锁开销就更大（时间，系统资源）=>悲观锁

预测当前锁冲突概率不大，后续要做的工作往往就更少.加锁开销就更小(时间，系统资源）=>乐观锁

synchronized是属于既是乐观锁，也是悲观锁，它支持自适应.

synchronized能够自动的统计出当前的锁冲突的次数，进行判定当前是锁冲突概率低，

还是概率高当冲突概率低的时候，就是按照乐观锁的方式来执行的.(速度更快）

当冲突概率高的时候，就会升级成悲观锁的方式来执行.（做的工作更多）

二.重量级锁VS轻量级锁

判断条件：做的事情多少,

做的事情多少叫重量级锁，做的事情少,叫轻量级锁。

一般来说，悲观锁，往往就是重量级锁加锁过程做的事情多，重量

一般来说，乐观锁，往往就是轻量级锁加锁过程做的事情少，轻量

synchronized是属于既是.重量级锁VS轻量级锁，它支持自适应.

三.自旋锁VS挂起等待锁

自旋锁

    void lock(){
        while (true){
            if (){
                continue;
            }
            获取到锁
                    break;
        }
    }

消耗了更多的cpu资源但是一旦锁被释放就能第一时间拿到锁拿到锁的速度更快，由于一直在执行这样的操作，所以一直消耗cpu。

挂起等待锁

挂起等待锁，是重量级锁的一种典型实现方式

当尝试加锁，并且锁被占用了，出现锁冲突，就会让当前这个尝试加锁的线程，被挂起.（阻塞状态）此时这个线程就不会参与调度了，直到这个锁被释放，然后系统才能唤醒这个线程，去尝试重新获取锁

(拿锁慢，节省cput的消耗)消耗的时间更长一旦线程被阻塞了，啥时候被唤醒这个过程是不可控的，可能会经历很长很长的时间。

synchronized轻量级锁部分，基于自旋锁实现;重量级锁部分，基于挂起等待锁实现.

四.可重入锁vs不可重入锁

synchronized就是可重入锁，一个线程，针对这把锁，连续加锁两次，不会死锁

不可重入锁，就会造成连续加锁两次之后会死锁。

五.公平锁炎VS非公平锁

公平锁：严格按照先来后到的顺序来获取锁哪个线程等待的时间长，哪个线程就拿到锁

非公平锁：若干个线程，各凭本事，随机的获取到锁和线程等待时间无关了。

公平锁：相当于买饭，先排队的人，先吃饭，后排队的人后买饭

非公平锁，像抢票，所有人在同一时间，一起抢票。

synchronized属于非公平锁多个线程，尝试获取这个锁

六.互斥锁VS读写锁

互斥锁：给读操作加锁：读的时候，不能写给写操作加锁：写的时候，不能读。

java的读写锁是这样设定的：

1）读锁和读锁之间，不会产生互斥

2）写锁和写锁之间,会产生互斥

3）读锁和写锁之间会产生互斥

日常开发中，有很多场景，景，属于“读多，写少”，用读写锁提高效率。

synchronized实现原理

synchronized即使悲观锁，也是乐观锁，既是轻量级锁，也是重量级锁.轻量级锁是自旋锁实现，重量级锁是挂起等待锁实现.是可重入锁，不是读写锁，是非公平锁.

synchronized 的"自适应"锁升级的过程：

1）未加锁的状态 (无锁）--->代码中开始调用执行synchronized->(2)

2)偏向锁--->遇到锁冲突

3)轻量级锁--->冲突进一步提升

4)重量级锁

偏向锁的作用：能不加锁，就不加锁，能晚加锁，就晚加锁。

就像买房子，刚开始没加锁的状态的时候，就是没买，然后跟房地产的人说，再看看，这时候就相当于偏向锁，等到有人想要买房子的时候，就会提升为轻量锁，直接将房子叫了定金，如果这时候还有很多人买，冲突加剧，就会变成重量级锁。

锁消除

最典型的，就只在一个线程里，使用synchronized.

由于编译器优化，需要保证优化后的逻辑和优化前是要等价的这里做的是比较保守的.能够起到的作用有限的。

 就是将很多的步骤合并，使其简化。

最终目的：提高效率

锁粗化

锁的粒度

加锁的范围内，，包含多少代码包含的代码越多，就认为锁的粒度就越粗反之,锁的粒度就越细。

  synchronized (this){
            fun1();
        }
        synchronized (this){
            fun2();
        }
        synchronized (this){
            fun3();
        }

合并 

 synchronized (this){
            fun1();
            fun2();
            fun3();
        }

synchronized的优化策略

1)锁升级[重要]=>高频考点.(把偏向锁,理解好，解释清楚)

2)锁消除

3)锁粗化

CAS

这是一条cpu指令，就可以完成比较和交换这样的一套操作下来(原子的)。

 boolean cas(内存地址,寄存器1,寄存器2)
    {
        if (内存地址==寄存器1){
            把  内存地址的值和 寄存器2 的值,进行交换
            return  true;
        }
        return  false;
    }

用来赋值

在java 代码中也就可以使用CAS操作了

只要代码有了加锁，此时代码就和“高性能”。

import java.util.concurrent.atomic.AtomicInteger;

public class Test5 {

        private  static AtomicInteger count=new AtomicInteger(0);
    public static void main(String[] args) {
        Thread t1=new Thread(()->{
           for (int i=0;i<5000;i++){
               count.getAndIncrement();//count++;
               count.incrementAndGet();//++count;
               count.getAndIncrement();//count--;
               count.decrementAndGet(); //--count;
               count.getAndAdd(10);//count+=10;
           }
        });

    }

}
--

此处我们的代码中，没有用到任何的加锁操作的，

这一套，基于CAS，不加锁来实现线程安全代码的方式，也称为“无锁编程

还可以基于CAS来封装成自旋锁（自旋锁也是基于CAS来实现的），

这样做，其实也就失去了“无锁编程”的意义了.

public class SpinLock{
    private Thread owner=null;//持有锁的线程是谁未加锁状态，此时owner就是null.
    public void lock(){
     while (!CAS(this.owner-->此处的比较和赋值是原子的～~就可以借助这样的逻辑来进行行加锁的实现,null-->如果当前前owner的值为null就把当前调用lock方法的线程引l用赋值到owner里面此时CAS返回true，再来！取反，就是false，循环结束了,Thread.currentThread()))
{
         
     }
    }
    public void unlock(){
        this.owner=null;
    }
}

如果当前owner不为null,此时CAS不会进行任何交换/赋值直接返回false，再来！取反，就是true，就要继续循环，再判定一次～~

CAS的ABA问题属于CAS的一个重要注意事项.

CAS 这里核心是"比较－发现相等－交换"=>潜台词发现相等=>数据中间没有发生过任何改变

此处CAS期望的是，中间没有其他线程修改过这个数据实际上，不一定.可能会出现，其他线程，把这个数据，从A->B->A看起来好像没变，好像没人改，其实是已经变过了，但是影响不大。