多线程（高阶）

锁策略

1.乐观锁：它认为在一般情况下不会出现问题，只有在数据进行修订改的时候才会判断是否有锁竞争，如果没有就会直接修改数据，有的话就会提示失败信息给用户；
乐观锁的经典事项CAS；
2.悲观锁：悲观锁任务只要执行多线程就一定会出现问题，所以在进入方法后会直接加锁；
悲观锁的经典事项：Synchronized，Lock；
3.独占锁和共享锁：
独占锁：指的是这把锁只能被一个线程所拥有；
共享锁：指的是这把锁只能被多个线程所拥有；
独占锁和共享锁的的例子：WriteReadLock()中的写锁就为独占锁，读锁为共享锁；
4.公平锁和非公平锁：
公平锁：获取锁的顺序按照线程访问的先后顺序来进行；
非公平锁：不按照先后顺序（非公平锁的性能较高）
5.可重入锁：
一个线程在拥有了一把锁之后，可以重复的获取这把锁：
经典使用场景（Synchronized，ReentrantLock）
6.自旋锁：一直循环尝试获取锁；Synchronized；
**偏向锁的理解：**在线程初次访问的时候，将线程的ID放到对象头的偏向锁ID字段中，当线程每次访问的时候，都会拿线程的id和对象头信息中的偏向锁id作比较，如果相同则执行任务，不同的话则表示该线程不拥有此锁，需要自身以不断自旋的方式去获取锁；

CAS（Compare And Swap）

CAS实现：

CAS的底层原理实现？
在Java中是通过unsafe类实现的，unsafe类的本地类和本地方法，是由c/c++实现的，通过调用操作系统的Atomic::cmpxcge来实现的；
CAS在Java中是以Atomic*来应用的；

乐观锁CAS存在什么问题？
ABA问题
怎么处理？
在比较的时候加入版本号,这样即使在值相同的情况下，但因版本号不同，
也无法修改值，从而解决了ABA问题
解决方案：AtomicStampedReference；

JUC下常用的四种类

1.ReentrantLock：
a）lock一定要放在加锁之前
b）在finally一定要释放锁
2.Semaphore(可以完成限流操作)

3.CountDownLatch（计时器）：

执行原理：
它内部有一个计数器，每当执行了countDown方法时，计数器-1，直到为0时，就可以执行await后面的代码了。

缺点：计时器只能使用一次。
4.CyclicBarrier 循环屏障：
CyclicBarrier 执行原理：
它的内部有一个计数器，每当线程执行到await（）的时候，计数器+1，当计数器等于开始所创建的屏障大小的时候，就会冲破屏障，执行后面的代码，并且计数器清0，进行下一轮的执行。
CyclicBarrier 和 CountDownLatch有什么区别？
CountDownLatch计时器只能使用一次，而CyclicBarrier可以反复使用。

ConcurrentHashMap

HashMap1.7在多线程并发的时候因为头插法的原因，会导致死循环（）。
HashMap1.8在多线程并发的时会导致数据覆盖。
HashMap的安全版本：ConcurrentHashMap;

HashMap，HashTable，ConcurrentHashMap的区别？
1.HashMap在多线程时是非安全的容器，jdk1.7会造成死循环，1.8会造成数据覆盖；
2.Hash Table在实现线程安全方面略为粗糙，在put时直接在put方法上添加Synchronized关键字来实现线程安全，因此性能不高，实际开发中很少使用，ConcurrentHashMap在1.7的时候使用Lock加分段锁的方式实现线程安全，在1.8的时候使用大量的CAS和volatile来实现线程安全，并且在1.8的时候在读的时候不进行加锁，写的时候进行加锁（读和写是同时进行的，这导致了当读的时候获取到的数据不是最新的）。