多线程高阶

JUC

1.ReentrantLock

a.lock要写在try之前
b.一定要在final里面进行unlock().

2.信号量(semaphore)

方法：acquire(尝试获取锁，如果可以正常获取到，则执行后面的业务逻辑，如果获取失败，则阻塞等待)  
			release(释放锁)

3.计数器(CountDownLauth)

计数起是用来保证一组线程同时完成某个操作之后，才能继续后面的任务.

CountDownLauth是如何实现的？
答：在CountDownLauth里面有一个计数器，每次调用countdown()方法的时候计数器的数量 -1，知道减到0之后，就可以执行await之后的代码

CountDownLauth缺点：
CountDownLauth计数器的使用是一次性的，当用完一次之后，就不能在使用了

4.循环屏障(循环栅栏)

CyclicBarrier

CyclicBarrier和CountDownLauth的区别？
答：CountDownLauth计数器只能使用一次， CyclicBarrier它的计数器可以重复使用

HashMap 底层实现结构、负载因子，哈希冲突的解决等线程问题

HashMap(非线程安全的容器)
JDK 1.7 死循环
JDK 1.8 数据覆盖

HashMap JDK 1.7死循环分析：

HashMap 负载因子 0.75 在大于这个因子的时候，进行扩容
尽量的避免哈希冲突所带来的性能开销问题

HashMap在JDK1.7是头插法，在JDK1.8是尾插法
HashMap线程安全方案：ConcurrentHashMap
JDK 1.7是将ConcurrentHashMap分成几个segment进行加锁

JDK 1.8 锁优化，读的时候不加锁，写的时候加锁，使用了大量的CAS.Voiltail

Hashtable 线程安全的容器
给put方法整体加锁，所以一般情况下不会使用它，性能较低

HashMap.ConcurrentHashMap.Hashtable的区别？
答：
1.HashMap 是非线程安全的容器，他在JDK 1.7 会造成死循环，JDK1.8会造成数据覆盖.Hashtable和ConcurrentHashMap都是线程安全.
2.Hashtable实现线程安全的手段比较简单，它是在put方法整体加了一把锁，使用synchronized 修饰，因此性能不高，所以使用频率较低；而ConcurrentHashMap是HashMap在多线程下的替代方案，它在JDK 1.7 的时候使用的Lock加分段锁的方案来实现线程安全问题的保障，而在JDK 1.8 的时候使用了大量的CAS Volatiel 来实现线程的，并且在JDK 1.8 的时候读取的时候不加锁(读取的数据可能不是最新的，因为读取和写入可以同时进行)，只有在写的时候才加锁。