《Java并发编程艺术》第二章Java并发机制的底层实现Javaqq38732834的博客-

第一章Java并发挑战主要有：

1. 上下文切换问题：
   解决思路：
   1.减少线程数量
   2.增长线程内的有效利用率（就是线程运行时间和上下文切换时间）

2. 死锁
   解决思路：
   1.避免一个线程同时获得多个锁
   2.避免一个线程在锁内同时占用多个资源。
   3.尝试使用定时锁（lock.tryLock(timeout)）
   4.对数据库锁，保证操作由一个连接完成

3. 资源限制
   第二章：

volatile

定义： 实现线程访问共享变量时，为了确保共享变量能够准确和一致的更新。
为何需要： 由于在默认的情况下，CPU发现一个操作数是可以进行缓存的便将其缓存下来 （缓冲行填充），若下次再访问该操作数所在地址时，则不通过内存访问，而是直接访问缓冲行中的值 （缓存命中），进行操作，再判断写入的地址是否已经存于缓存行，若是则将值再写到缓冲行 （写命中）。
这样在多线程的场景下，就会影响问题，线程读到的时之前的数据，各做各的也没有达到目标。
如何解决：
这时变需要使用volatile变量了，它添加到某变量上时，就保证了CPU只能从内存读值且缓存行无效。
它会给原来的指令追加一条带lock前缀的指令，这个指令保证了两件事：

1. 将当前处理器缓存行的数据写回系统内存（实现方式1.锁总线，2.锁缓存行，破坏了缓存一致性机制，所以迫使CPU写回内存）
2. 写回内存的操作会使得其他CPU缓存的该内存地址的数据无效。（实现方式：啥内部嗅探技术还有就是迫使缓存行无效，下次操作时强制填充）

这就很好的解决了以上所说的问题。
volatile的优化：
文中提到的LinkedTransfarQueue类 是将数据填充为64字节（或者说68字节），由于某些缓冲行为64字节，所以无法将队列头部指针和尾部指针同时缓存，使得头尾的修改无法互相锁定。
适用的条件：

1. 缓存行64字节带宽
2. 共享变量被频繁的改写。

synchronized

Java中每一个对象都可以所作锁使用（毕竟有对象头就可以），主要加三种表现形式：
对象头见此文相关部分

1. 普通方法：当前实例对象
2. 静态同步方法：当前类的Class对象
3. 同步代码块：配置的对象

底层实现：
JVM中基于进入和退出Moniter对象来实现同步，方法同步和代码块同步的实现原理可不一样，不过都是使用monitorenter 和monitorexit指令，monitorenter指令在编译后插入到同步代码块的开始位置，monitorexit则插入到结束或者异常位置，当一个monitor被持有后，这段代码块便处于锁定状态。

锁的分类：
1.偏向锁：
是一种特殊的“无锁”状态,当一个线程访问同步代码块时，会在对象头和栈帧中的锁记录里储存锁偏向的线程ID，只需简单的测试下对象头的Mark Word是否存储着指向当前线程的偏向锁，若是则成功获得锁，若不是，则看是否设置偏向锁标志，若是，改为本线程ID，若不是，则用CAS竞争锁。
**偏向锁的撤销：**很明显出现竞争时，偏向锁便不再适用了，等待一个没有执行的字节码的时间点（全局安全点），首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着，死了，锁的对象头设置为无锁，活着，要么偏向其他线程，要么恢复到无锁，要么标记该对象不适用于偏向锁。
关闭偏向锁：

-XX：BiasedLockingStartupDelay=0 //由于偏向锁默认程序启动几秒后启动，若需要可以取消延迟 -XX：UseBiasedLocking=flase //如果程序中所有锁通常处于竞争状态可以关闭偏向锁 

2.轻量级锁
加锁：
首先将锁对象头的MarkWord复制到栈帧的锁记录中（Displaced Mark Word），再将MarkWord替换为指向锁记录的指针，若成功，线程获得锁，若失败则说明有竞争，以自旋CAS方式获取锁。若超过三个线程竞争该锁直接膨胀为重量级锁
解锁：
将锁记录中存的MarkWord写回对象头中，若成功，表示当前没有竞争，若失败，膨胀为重量级锁（因为在必然存在竞争时，无用的自旋会让CPU做无用功）。


3.重量级锁
互斥锁，在某个线程持有锁时，其他尝试竞争锁的线程都会被阻塞，当锁被释放时，再唤醒其他线程，重新竞争锁。

注意： 锁只能升级不能降级。

原子性

处理机制：

public class CASTest { private static AtomicInteger atomicInteger = new AtomicInteger(); private static int i; public static void main(String[] args) throws InterruptedException {         List<Thread> list = new ArrayList<>(); for(int i=0;i<1000;i++){             list.add(new Thread(()->{ for(int j =0;j<1000;j++) { safeAdd(); unsafeAdd(); } })); } for(int i =0;i<1000;i++){             list.get(i).start(); } for(Thread i:list){             i.join(); }         System.out.println("safe:"+atomicInteger.get());         System.out.println("unsafe:"+i); } static void safeAdd(){//保证原子性 while(true){ int count = atomicInteger.get(); if(atomicInteger.compareAndSet(count,count+1)){ break; } } } static void unsafeAdd(){//瞎几把加         i++; } } 

//再用CAS写个单例，不过没有太大实用价值，还是建议用doublecheck、饿//汉啊，当然最推荐的还是枚举的写法

public class CASSingle { private static AtomicReference<CASSingle>instance= new AtomicReference<>(); private CASSingle(){} public static CASSingle getCasSingle() { while(true){             CASSingle casSingle = instance.get(); if(casSingle!=null){ return casSingle; }             casSingle = new CASSingle();             System.out.println(Thread.currentThread().getName()+"新建了一个对象"); if(instance.compareAndSet(null,casSingle)){ return casSingle; } } } 

//阔以感受一下，虽然最后得到的同一对象，不过可不止实例化了一个对象

CAS的三大问题：
1.ABA问题：A->B->A表面上没有修改，其实改过了，解决方法是追加版本号（jdk的Atomic包下的AtomicStampedReference来解决，先检查预期再检查版本号）
2.循环时间长开销大
3.只能保证一个共享变量原子操作，用原子引用解决呀，封装成一个类。