不知道大家还有没有印象，上次我们已经说过了，我们为了实现集合相关类的线程安全，JDK 提供了一套同步容器，也就是 Vector，Hashtable，还有一个 Collections 工具类中的几个方法。

问题是什么呢，同步容器并不能保证线程安全，我在们写代码的时候还需要注意一些方法的使用，在 JDK 1.5 及以后就出现了 java.util.current 包，这个包中就提供了大量的类来实现线程安全，这也就是我们经常说的 JUC。

举例例子吧，与 HashMap 对应的线程安全的容器，ConcurrentHashMap 就是出自这个包。

稍微整理了一下这个包中都包含了哪些功能，做个思维导图。

不得不说，这其中的知识点非常多，我这只是列出了一部分，作为大纲，我呢也不可能都说，用到的类也很少，目前工作基本接触不到这些类的使用。

但是吧，我还是强烈建议有基础的同学看看源码，膜拜一下大神。

我就简单说几个面试常问的，并发容器，atomic 包，Lock 和其实现类，线程池。

并发容器最最常问的就是 ConcurrentHashMap 的原理，四个字分段加锁。使用的是 synchronized 代码块加锁，只不过锁的范围不再是整个 table ，而是一个一个的 Node。

原子包中的原子类主要就是提供了一些不需要加锁就能保证原子性操作的一些方法，我们不使用锁进行同步，而是使用算法来保证操作的原子性，主要涉及的算法是 CAS，核心方法就是 compareAndSwap。这个方法是实现是 native 的，嗯，不是 Java 实现的。

算法思想就是我拿工作内存中的值和主存中的值进行比较，若是一样我才操作，不一样那就修改主存中的值，继续比较直到满足条件。这样做也就保证了主内存和工作内存中的值一致。

有个有趣的事情，CAS 是定义在一个 Unsafe 类中的。有么有想过，尽然还有这么有意思的类名，原来这个类是由 sun 公司提供的，之所以命名为 Unsafe 是因为 GC 的时候不能回收这个类，所以官方不建议使用。

嗯，在 CAS 算法中还有可能出现 ABA 问题，就是说在读取内存中变量的时候看起来没有变化，可能是已经又变回来了，解决的方法就是每次修改变量的时候都会加上一个版本号，同时比较版本号和变量的值是否改变。

ReentrantLock 名为可重入锁，就是说一个线程在获得一个锁之后，再次获取该锁时，不需要重新等待获取。ReentrantLock 又分为公平锁和非公平锁，公平锁指的是严格按照先来先得的顺序排队等待去获取锁，而非公平锁每次获取锁时，是先直接尝试获取锁，获取不到，再按照先来先得的顺序排队等待。

ReentrantReadWriteLock 可重入读写锁，指的是没有线程进行写操作时，多个线程可同时进行读操作，当有线程进行写操作时，其它读写操作只能等待。可以多线程一起读但是一旦有写就需要等着，有较好的并发行和吞吐量。

线程频繁的创建和销毁是很浪费资源的，所以我们就创建一个线程池用来保证有一部分线程始终处于待命状态，来任务了可以立马执行，这也是线程池的优点，提高资源的利用率，提高了请求响应的速度，而且我们还可以管理已经创建的线程。

线程池主要关注点在线程池创建的 7 个参数上，我们并发量很小的时候，待命的线程过多也是浪费大量的资源，所以关于性能调优，这些没有定论，要根据自身的业务场景。

参数主要是线程池的大小，最大线程数，设置空闲时间，线程过多时使用何种阻塞队列，创建线程的工厂是什么，当阻塞队列也满了时，采用什么策略来处理后续线程。

东西真的好多，我这只是说了一丢丢，好多东西我只是知道但是没有用过，我是感觉脱离业务的技术意义不大，虽然学起来感觉很牛逼，但是用不到的我也就止步于此了，大家加油，至少拓展了我们的思路，再接触时不会怂！