5月13日学习记录 多线程语法相关问题

多线程语法梳理

参考： https://www.jianshu.com/p/01188fa8e511

volatile关键词

多线程访问共享变量吗，为了确保共享变量能被准确和一致的更新，线程应该确保通过排他锁单独获得这个变量。Java语言提供了volatile，在某些情况下比锁更加方便。如果一个字段被声明成volatile，java线程内存模型确保所有线程看到这个变量的值是一致的。

1. 使用volitate修饰的变量在汇编阶段，会多出一条lock前缀指令
2. 它确保指令重排序时不会把其后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面；即在执行到内存屏障这句指令时，在它前面的操作已经全部完成
3. 它会强制将对缓存的修改操作立即写入主存
4. 如果是写操作，它会导致其他CPU里缓存了该内存地址的数据无效

缺点：

并不能保证操作的原子性

synchronized 关键词

synchronized 是JVM实现的一种锁，其中锁的获取和释放分别是
monitorenter 和 monitorexit 指令，该锁在实现上分为了偏向锁、轻量级锁和重量级锁，其中偏向锁在 java1.6 是默认开启的，轻量级锁在多线程竞争的情况下会膨胀成重量级锁，有关锁的数据都保存在对象头中

加了 synchronized 关键字的代码段，生成的字节码文件会多出 monitorenter 和 monitorexit 两条指令（利用javap -verbose 字节码文件可看到关，关于这两条指令的文档如下：

使用方法：

修饰普通方法： 同步对象是实例对象
修饰静态方法： 同步对象是类本身
修饰代码块： 可以自己设置同步对象​

缺点：

会让没有得到锁的资源进入Block状态，争夺到资源之后又转为Running状态，这个过程涉及到操作系统用户模式和内核模式的切换，代价比较高。Java1.6为 synchronized 做了优化，增加了从偏向锁到轻量级锁再到重量级锁的过度，但是在最终转变为重量级锁之后，性能仍然较低。

CAS

如果只是用 synchronized 来保证同步会存在以下问题
synchronized 是一种悲观锁，在使用上会造成一定的性能问题。在多线程竞争下，加锁、释放锁会导致比较多的上下文切换和调度延时，引起性能问题。一个线程持有锁会导致其它所有需要此锁的线程挂起。

原理： Java不能直接的访问操作系统底层，是通过native方法（JNI）来访问。CAS底层通过Unsafe类实现原子性操作。AtomicBoolean，AtomicInteger，AtomicLong以及 Lock 相关类等底层就是用 CAS实现的，在一定程度上性能比 synchronized 更高。

缺点： ABA问题， 在这个过程中线程B获取到N的值是一个旧值​​，虽然和当前N的值相等，但是实际上N的值已经经历了一次 1到2到1的改变， 上面这个例子就是典型的ABA问题​

解决ABA问题：

怎样去解决ABA问题
给变量加一个版本号即可，在比较的时候不仅要比较当前变量的值 还需要比较当前变量的版本号。Java中AtomicStampedReference 就解决了这个问题
循环时间长开销大
在并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。