开篇介绍

大家好，我是Java最全面试题库的提裤姐，明天这篇是JavaSE系列的第十三篇，次要总结了Java中的多线程问题，多线程分为三篇来讲，这篇是第三篇，在后续，会沿着第一篇开篇的常识线路始终总结上来，做到日更！如果我能做到百日百更，心愿你也能够跟着百日百刷，一百天养成一个好习惯。

volatile关键字的作用?

对于可见性，Java提供了volatile关键字来保障可见性。当一个共享变量被volatile润饰时，它会保障批改的值会立刻被更新到主存，当有其余线程须要读取时，它会去内存中读取新值。次要的原理是应用了内存指令。

  • LoadLoad重排序：一个处理器先执行一个L1读操作，再执行一个L2读操作；然而另外一个处理器看到的是先L2再L1
  • StoreStore重排序：一个处理器先执行一个W1写操作，再执行一个W2写操作；然而另外一个处理器看到的是先W2再W1
  • LoadStore重排序：一个处理器先执行一个L1读操作，再执行一个W2写操作；然而另外一个处理器看到的是先W2再L1
  • StoreLoad重排序：一个处理器先执行一个W1写操作，再执行一个L2读操作；然而另外一个处理器看到的是先L2再W1

说一下volatile关键字对原子性、可见性以及有序性的保障

在volatile变量写操作的后面会退出一个Release屏障，而后在之后会退出一个Store屏障，这样就能够保障volatile写跟Release屏障之 前的任何读写操作都不会指令重排，而后Store屏障保障了，写完数据之后，立马会执行flush处理器缓存的操作 。
在volatile变量读操作的后面会退出一个Load屏障，这样就能够保障对这个变量的读取时，如果被别的处理器批改过了，必须得从其余 处理器的高速缓存（或者主内存）中加载到本人本地高速缓存里，保障读到的是最新数据； 在之后会退出一个Acquire屏障，禁止volatile读操作之后的任何读写操作会跟volatile读指令重排序。
与volatie读写内存屏障比照一下，是相似的意思。
Acquire屏障其实就是LoadLoad屏障 + LoadStore屏障，
Release屏障其实就是StoreLoad屏障 + StoreStore屏障

什么是CAS?

CAS（compare and swap）的缩写。Java利用CPU的CAS指令，同时借助JNI来实现Java的非阻塞算法,实现原子操作。其它原子操作都是利用相似的个性实现的。
CAS有3个操作数：内存值V，旧的预期值A，要批改的新值B。
当且仅当预期值A和内存值V雷同时，将内存值V批改为B，否则什么都不做。
CAS的毛病：

  • CPU开销过大

在并发量比拟高的状况下，如果许多线程重复尝试更新某一个变量，却又始终更新不胜利，周而复始，会给CPU带来很到的压力。

  • 不能保障代码块的原子性

CAS机制所保障的常识一个变量的原子性操作，而不能保障整个代码块的原子性。比方须要保障3个变量独特进行原子性的更新，就不得不应用synchronized了。

  • ABA问题

这是CAS机制最大的问题所在。

什么是AQS?

AQS，即AbstractQueuedSynchronizer，队列同步器，它是Java并发用来构建锁和其余同步组件的根底框架。
同步组件对AQS的应用：
AQS是一个抽象类，主是是以继承的形式应用。
AQS自身是没有实现任何同步接口的，它仅仅只是定义了同步状态的获取和开释的办法来供自定义的同步组件的应用。从图中能够看出，在java的同步组件中，AQS的子类（Sync等）个别是同步组件的动态外部类，即通过组合的形式应用。
形象的队列式的同步器，AQS定义了一套多线程访问共享资源的同步器框架，许多同步类实现都依赖于它，如罕用的ReentrantLock/Semaphore/CountDownLatch
它保护了一个volatile int state（代表共享资源）和一个FIFO（双向队列）线程期待队列（多线程争用资源被阻塞时会进入此队列）

Semaphore是什么？

Semaphore就是一个信号量，它的作用是限度某段代码块的并发数。
semaphore有一个构造函数，能够传入一个int型整数n，示意某段代码最多只有n个线程能够拜访，如果超出了n，那么请期待，等到某个线程执行结束这段代码块，下一个线程再进入。
由此能够看出如果Semaphore构造函数中传入的int型整数n=1，相当于变成了一个synchronized了。

public static void main(String[] args) {          int N = 8; //工人数          Semaphore semaphore = new Semaphore(5); //机器数目          for(int i=0;i<N;i++)              new Worker(i,semaphore).start();      }          static class Worker extends Thread{          private int num;          private Semaphore semaphore;          public Worker(int num,Semaphore semaphore){              this.num = num;              this.semaphore = semaphore;          }                  @Override          public void run() {              try {                  semaphore.acquire();                  System.out.println("工人"+this.num+"占用一个机器在生产...");                  Thread.sleep(2000);                  System.out.println("工人"+this.num+"开释出机器");                  semaphore.release();                          } catch (InterruptedException e) {                  e.printStackTrace();              }          }      }

Synchronized的原理是什么？

Synchronized是由JVM实现的一种实现互斥同步的形式，查看被Synchronized润饰过的程序块编译后的字节码，会发现，被Synchronized润饰过的程序块，在编译前后被编译器生成了monitorenter和monitorexit两个字节码指令。
在虚拟机执行到monitorenter指令时，首先要尝试获取对象的锁：如果这个对象没有锁定，或者以后线程曾经领有了这个对象的锁，把锁的计数器+1；
当执行monitorexit指令时，将锁计数器-1；当计数器为0时，锁就被开释了。如果获取对象失败了，那以后线程就要阻塞期待，直到对象锁被另外一个线程开释为止。
Java中Synchronize通过在对象头设置标记，达到了获取锁和开释锁的目标。

为什么说Synchronized是非偏心锁？

非偏心次要体现在获取锁的行为上，并非是依照申请锁的工夫前后给期待线程调配锁的，每当锁被开释后，任何一个线程都有机会竞争到锁，这样做的目标是为了进步执行性能，毛病是可能会产生线程饥饿景象。

JVM对java的原生锁做了哪些优化?

在Java6之前, Monitor的实现齐全依赖底层操作系统的互斥锁来实现.

因为Java层面的线程与操作系统的原生线程有映射关系,如果要将一个线程进行阻塞或唤起都须要操作系统的帮助,这就须要从用户态切换到内核态来执行,这种切换代价非常低廉,很耗处理器工夫,古代JDK中做了大量的优化。
一种优化是应用自旋锁,即在把线程进行阻塞操作之前先让线程自旋期待一段时间,可能在期待期间其余线程曾经解锁,这时就无需再让线程执行阻塞操作,防止了用户态到内核态的切换。
古代JDK中还提供了三种不同的 Monitor实现,也就是三种不同的锁:

  • 偏差锁(Biased Locking)
  • 轻量级锁
  • 重量级锁

这三种锁使得JDK得以优化 Synchronized的运行,当JVM检测到不同的竞争情况时,会主动切换到适宜的锁实现,这就是锁的降级、降级。当没有竞争呈现时,默认会应用偏差锁。
JVM会利用CAS操作,在对象头上的 Mark Word局部设置线程ID,以示意这个对象偏差于以后线程,所以并不波及真正的互斥锁,因为在很多利用场景中,大部分对象生命周期中最多会被一个线程锁定,应用偏差锁能够升高无竞争开销。
如果有另一线程试图锁定某个被偏差过的对象,JVM就撤销偏差锁,切换到轻量级锁实现。
轻量级锁依赖CAS操作 Mark Word来试图获取锁,如果重试胜利,就应用一般的轻量级锁否则,进一步降级为重量级锁。

Synchronized和 ReentrantLock的异同？

synchronized：
是java内置的关键字，它提供了一种独占的加锁形式。synchronized的获取和开释锁由JVM实现，用户不须要显示的开释锁，十分不便。然而synchronized也有一些问题：
当线程尝试获取锁的时候，如果获取不到锁会始终阻塞。
如果获取锁的线程进入休眠或者阻塞，除非以后线程异样，否则其余线程尝试获取锁必须始终期待。

ReentrantLock：
ReentrantLock是Lock的实现类，是一个互斥的同步锁。ReentrantLock是JDK 1.5之后提供的API层面的互斥锁，须要lock()和unlock()办法配合try/finally语句块来实现。
期待可中断防止，呈现死锁的状况（如果别的线程正持有锁，会期待参数给定的工夫，在期待的过程中，如果获取了锁定，就返回true，如果期待超时，返回false）
偏心锁与非偏心锁多个线程期待同一个锁时，必须依照申请锁的工夫程序取得锁，Synchronized锁非偏心锁，ReentrantLock默认的构造函数是创立的非偏心锁，能够通过参数true设为偏心锁，但偏心锁体现的性能不是很好。

从性能角度：
ReentrantLock比 Synchronized的同步操作更精密（因为能够像一般对象一样应用），甚至实现 Synchronized没有的高级性能,如：

  • 期待可中断当持有锁的线程长期不开释锁的时候，正在期待的线程能够抉择放弃期待,对解决执行工夫十分长的同步块很有用。
  • 带超时的获取锁尝试在指定的工夫范畴内获取锁，如果工夫到了依然无奈获取则返回。
  • 能够判断是否有线程在排队期待获取锁。
  • 能够响应中断请求与Synchronized不同，当获取到锁的线程被中断时,可能响应中断,中断异样将会被抛出,同时锁会被开释。
  • 能够实现偏心锁。

从锁开释角度：
Synchronized在JVM层面上实现的，岂但能够通过一些监控工具监控 Synchronized的锁定，而且在代码执行出现异常时，JVM会主动开释锁定，然而应用Lock则不行,Lock是通过代码实现的,要保障锁定肯定会被开释，就必须将 unLock()放到 finally{}中。

从性能角度：
Synchronized晚期实现比拟低效，比照 ReentrantLock，大多数场景性能都相差较大。
然而在Java6中对其进行了十分多的改良,
在竞争不强烈时：Synchronized的性能要优于 ReetrantLock；
在高竞争状况下：Synchronized的性能会降落几十倍,然而 ReetrantLock的性能能维持常态。