多线程：乐观锁

•  悲观锁:一上来就加锁，没有安全感。每次只能一个线程进入访问完毕后，再解锁。 线程安全，性能较差!
• 乐观锁:一开始不上锁，认为是没有问题的，大家一起跑，等要出现线程安全问题的时候才开始控制。线程安全，性能较好。

为什么出现线程安全问题？100个线程每个加100次应该加10000次才对；因为有100个线程针对一个count，假如中间已经加到了10，有一百个线程同时要给10加1，同时有多个线程把10拽出来给他加1成11（因为两个线程是同时跑的），再写进去的话也都是11，实际上加了两次但只有11进去，丢了一次，所有是有安全问题的。多个线程在访问同一个资源时会产生安全问题。

怎么解决？

1.加悲观锁：对修改变量值count没有安全感，上来就加锁，每次只允许一个线程操作他，操作完成后才允许其他线程操作；就意味着把这段代码进行上锁。

 System.out.println("count=====>" + (++count));//担心优先级问题加（）

（是每次修改都加锁，还是100个线程执行完再加锁？每次修改它加锁，因为不可能这个线程一下加一百次，可能加到99的时候别人抢去加一次，所以单独给他加锁，单独修改加锁，而不是整体加锁——>当然也可以，但不符合开发逻辑。）

实例代码：

//多个线程在访问同一个贡献资源会出现线程安全问题
public class Test1 {
    public static void main(String[] args) {
        // 目标:拓展悲观锁，乐观锁原理。
        // 悲观锁:一上来就加锁，没有安全感。每次只能一个线程进入访问完毕后，再解锁。 线程安全，性能较差!
        //乐观锁:一开始不上锁，认为是没有问题的，大家一起跑，等要出现线程安全问题的时候才开始控制。线程安全，性能较好。
        //需求：1变量，100个线程，每个线程对其加100次。
        Runnable target = new MyRunnable();//任务对象 直new了一个
        for (int i = 1; i <= 100; i++) {// 任务只有一个
            new Thread(target).start();//new了100个线程——》都是拿同一个对象执行——》都是执行各自的run方法
            //方法进栈，每一个线程都到栈里面跑
        }
    }
}

//悲观锁：每次都要在外面排队（100个线程，每个线程都要跑100次，每个线程都要排100次队，总共要排1w次队，一个一个加的，性能很差！）
public class MyRunnable implements Runnable {
    private int count;//记录浏览人数
    //为什么number可以不用静态的，因为到时候任务对象只会new一个，new一个这个变量就只会有一个
    @Override
    public void run() {
        for (int i = 0; i < 100; i++) {//对每个线程加100次
            synchronized (this) {//Runnable对象只new了一份，一百个线程拿的是同一个target对象，this可以取到当前主调target对象
                System.out.println(this);// （this正好对应是MyRunable对象-只new了一次，对这100个线程来说肯定就是同一个）
                //this代表的是MyRunnable对象,run在MyRunnable这个类里边，this就代表的这个类的对象，这个类的对象只new了一个给到线程，底层肯定就把this当作一个对象看，这样就能保证线程安全
                //值是一个一个往前加的，但至于是哪个线程加的就不一定，每个线程都是要竞争的，
                System.out.println(Thread.currentThread().getName()
                        + "count=====>" + (++count));//担心优先级问题加（）
            }
        }
    }
}

2.加乐观锁

这个数字在无限的接近线程安全，(比如每次执行完基本上是9999或者1w)就是100个线程在改这个变量的时候冲突的机会很少,1w次只有1、2次是冲突的，才会导致丢一次数据，也就是出现线程安全的问题并不高,既然冲突的概率很低，就干脆不加锁(比较和交换算法CAS算法CompareAndSet)

机制:只解决冲突这种情况，并不会加锁，大多数情况并不会冲突，因此性能比较高

实例代码：

//乐观锁
//机制：只解决冲突这种情况，并不会加锁，大多数情况并不会冲突，因此性能比较高
public class Test2 {
    public static void main(String[] args) {
        Runnable target = new MyRunnable2();
        for (int i = 1; i <= 100; i++) {
            new Thread(target).start();
            //这个数字在无限的接近线程安全，就是100个线程在改这个变量的时候冲突的机会很少，
            // 1w次只有1、2次是冲突的，才会导致丢一次数据，也就是出现线程安全的问题并不高
            //既然冲突的概率很低，就干脆不加锁（比较和交换算法-CAS算法）
        }
    }
}

import java.util.concurrent.atomic.AtomicInteger;

public class MyRunnable2 implements Runnable {
    //private int count;//记录浏览人数
    // 整数修改的乐观锁:原子类实现的。
    private AtomicInteger count = new AtomicInteger();
    //是用这个对象来保证线程安全的，count还是记录浏览人数
    //这个对象里边就是用乐观锁实现的——》对象里面实际是封装了一个value相当于之前的count（记录从0开始的在线人数）
    @Override
    public void run() {
        for (int i = 0; i < 100; i++) {
                /*System.out.println(Thread.currentThread().getName()
                        + "count=====>" + (++count));*/
                System.out.println(Thread.currentThread().getName()
                        + "count=====>" + count.incrementAndGet());//这个方法的内部没有加锁，内部的思想基于乐观锁实现的
                //要加一的话用原子类对象调用方法incrementAndGet——把底层值加一再取出来展示（相当于++count）
        }
    }
}

源码： 

想知道他（incrementAndGet()）是不是基于乐观锁，incrementAndGet()源码：

this代表的是当前这个原子（AtomicInteger）对象count，只有一个，VALUE不是存储的在线人数值，是内部声明的this对象也就是原子对象value的地址（VALUE是他的地址），他到时候会根据VALUE的地址取小写value的值。

getAndAddInt()源码：

o是接的原子对象，offset接的是小写value的地址，delta记的是1，v是当前要加的整数值，就是取的value值。

expected是期待的值，x是改的值， compareAndSetInt()已经是c语言写的方法。

（c的方法中是拿这个expected的值与原子对象里面根据地址值找到value的真实值比较，如果expected是10value还是10的话，就比较成功了，就会把x的11更新到value里边去变成11了，方法就会返回true代表修改成功，——》到!weakCompareAndSetInt取反就变成false，循环结束代表这次修改成功，return v是10回去，——》到getAndAddInt方法来看，返回v=10，整个方法返回10，后面delta+1是11给用户看，代表这次修改到11了，这是正常修改流程。）

如果expected期待值是10，x要修改的值是11，到 compareAndSetInt()方法看底层真实的value值——根据o原子对象，offset地址 找value真实值；如果value真实值已经被“别人”改成12（别人跑的非常快）发现10和12不等，就不修改11，就会返回flase，回到!weakCompareAndSetInt取反就变成true，之后do-while循环会再次去原子对象里面根据地址找到value最新的值12，又拿着v=12去改x=13，重新再到compareAndSetInt()方法中进行比较，如果跟底层v真实值12一比较相等，说明“版本号”统一了，就把13改进去给到底层的v（value），改进去之后返回true代表修改成功了，又到!weakCompareAndSetInt取反变成false，循环就结束，此时getAndAddInt方法中return的v就是12，12返回incrementAndGet()方法delta:12+1，将13给用户，告诉用户13改成功了。

（其中还有一开始getAndAddInt方法中do-while循环的v存12这个值（按本举例）一直存，最终返回12，而不是修改完成后重新去取，如果修改完成后重新去取的话（这次是基于12改的，修改成功最终返回12告诉我这次12是修改成功的，然后展示13） 12改13的那一刻正要取13的时候别人如果一下改成16，结果把17给回去会“一脸懵逼”，（这里面就是：你是12改的我就给你返回12 ，你在最后展示给用户看的时候+1显示13就好了）此时最新的值已经可能不准了。所以基于此原因考虑提前把v拿出来最后也返回的是v也就是这个12。）

正常流程草图之后的流程草图

IDEA2023：

Offset小写value的地址。

 代码到这就截至了，下面已经是c语言代码了。