Java笔记1--volatile&CAS&集合

volatile保证有序性(禁止指令重排)

image.png

volatile总结

volatile实现禁止指令重排优化，从而避免多线程环境下程序出现乱序执行的现象先了解一个概念，内存屏障（Memory Barrier）又称内存栅栏，是一个CPU指令，它的作用有两个：

一是保证特定操作的执行顺序
二是保证某些变量的内存可见俐（利用该特性实现volatile的内存可见性）。

由于编译器和处理器都能执行指令重排优化。如果在指令间插入一条Memory Barrier则会告诉编译器和CPU，不管什么指令都不能和这条Memory Barier指令重排序，也就是说通过插入内存屏障禁止在内存屏障前后的指令执行重排序优化。内存屏障另外一个作用是强制刷出各种CPU的缓存数据，因此任何CPU上的线程都能读取到这些数据的最新版本。

image.png

线程安全性获得保证

工作内存与主内存同步延迟现象导致的可见性问题可以使用synchronized或volatile关键字解决，它们都可以使一个线程修改后的变量立即对其他线程可见。
对于指令重排导致的可见性问题和有序性问题
可以利用volatile关键字解决，因为volatile的另外一个作用就是禁止重排序优化。

CAS,unsafe

image.png

var1 Atomiclnteger对象本身。
var2该对象值得引用地址。
var4 需要变动的数量。
var5是用过varl var2找出的主内存中真实的值。
用该对象当前的值与var5比较：|
如果相同，更新var5+var4并且返回true，如果不同，继续取值然后再比较，直到更新完成。

image.png

CAS底层汇编

image.png

CAS简单总结

CAS（CompareAndSwap）
比较当前工作内存中的值和主内存中的值，如果相同则执行规定操作，否则继续比较直到主内存和工作内存中的值一致为止.
CAS应用
CAS有3个操作数，内存值V，旧的预期值A，要修改的更新值。
当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。

问题引申: 为什么原子类用CAS而不是synchronized?
因为,synchronized虽然保证了数据的一致性,但并发性下降了.

CAS的缺点

1.CPU循环开销可能大
2.只能保证一个共享变量的原子性
3.引发ABA问题 (狸猫换太子)

假设有线程1和线程2,其中线程2的处理速度比1快,此时在主内存里有个A值,线程1和线程2都拷贝到了这个A值,线程2比较皮,为了证明自己比线程1快,他主内存的A改成了B,然后又把主内存的B改成了A,而线程1这时来主内存拿值是拿到A的,他认为这个值没有被动过.

image.png

解决ABA问题

image.png

时间戳原子引用

import java.util.concurrent.atomic.AtomicReference;
import java.util.concurrent.atomic.AtomicStampedReference;

public class ABADemo2 {
    private static AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference<>(100, 1);

    public static void main(String[] args) {
        new Thread(() -> {
            int stamp = atomicStampedReference.getStamp();
            System.out.println(Thread.currentThread().getName() + " 的版本号为：" + stamp);
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            atomicStampedReference.compareAndSet(100, 101, atomicStampedReference.getStamp(), atomicStampedReference.getStamp() + 1 );
            atomicStampedReference.compareAndSet(101, 100, atomicStampedReference.getStamp(), atomicStampedReference.getStamp() + 1 );
        }).start();

        new Thread(() -> {
            int stamp = atomicStampedReference.getStamp();
            System.out.println(Thread.currentThread().getName() + " 的版本号为：" + stamp);
            try {
                Thread.sleep(3000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            boolean b = atomicStampedReference.compareAndSet(100, 2019, stamp, stamp + 1);
            System.out.println(b); // false
            System.out.println(atomicStampedReference.getReference()); // 100
        }).start();
    }
}

集合类不安全问题

image.png

copyOnwrite

image.png

copyonwrite容器即写时复制的容器。往一个容器添加元素的时候，不直接往当前容器object[]添加，而是先将当前容器object[]进行copy，复制出一个新的容器0bject[]newELements，然后新的容器object[]newELements里添加元素，添加完元素之后，再将原容器的引用指向新的容器 setArray（newELements）；这样做的好处是可以copyonurite容器进行并发的读，而不需要加锁，因为当前容器不会添加在何元素。所以copyonwrite容器也是一种读写分离的思想，读和写不同的容器

HashSet底层是HashMap,而CopyOnWriteArraySet底层是CopyOnWriteArrayList

image.png

HashSet底层是HashMap但只需要存入一个值,这时因为在底层的K-V键值对中,只用到了key,而Value用一个PRESENTObject常量对象填充

image.png

在JUC包下,HashMap的安全类是ConcurrenthashMap

image.png