,ArrayBlockingQueue是一个用数组实现的有界阻塞队列。此队列按照先进先出（FIFO）的原则对元素进行排序。默认情况下不保证访问者公平的访问队列，所谓公平访问队列是指阻塞的所有生产者线程或消费者线程，当队列可用时，可以按照阻塞的先后顺序访问队列，即先阻塞的生产者线程，可以先往队列里插入元素，先阻塞的消费者线程，可以先从队列里获取元素。通常情况下为了保证公平性会降低吞吐量。
LinkedBlockingQueue是一个用链表实现的有界阻塞队列。此队列的默认和最大长度为Integer.MAX_VALUE。此队列按照先进先出的原则对元素进行排序。
PriorityBlockingQueue是一个支持优先级的*队列。默认情况下元素采取自然顺序排列，也可以通过比较器comparator来指定元素的排序规则。元素按照升序排列。
DelayQueue是一个支持延时获取元素的*阻塞队列。队列使用PriorityQueue来实现。队列中的元素必须实现Delayed接口，在创建元素时可以指定多久才能从队列中获取当前元素。只有在延迟期满时才能从队列中提取元素。我们可以将DelayQueue运用在以下应用场景：
缓存系统的设计：可以用DelayQueue保存缓存元素的有效期，使用一个线程循环查询DelayQueue，一旦能从DelayQueue中获取元素时，表示缓存有效期到了。
定时任务调度。使用DelayQueue保存当天将会执行的任务和执行时间，一旦从DelayQueue中获取到任务就开始执行，从比如TimerQueue就是使用DelayQueue实现的。
SynchronousQueue是一个不存储元素的阻塞队列。每一个put操作必须等待一个take操作，否则不能继续添加元素。SynchronousQueue可以看成是一个传球手，负责把生产者线程处理的数据直接传递给消费者线程。队列本身并不存储任何元素，非常适合于传递性场景,比如在一个线程中使用的数据，传递给另外一个线程使用，SynchronousQueue的吞吐量高于LinkedBlockingQueue 和 ArrayBlockingQueue。
LinkedTransferQueue是一个由链表结构组成的*阻塞TransferQueue队列。相对于其他阻塞队列，LinkedTransferQueue多了tryTransfer和transfer方法。
transfer方法。如果当前有消费者正在等待接收元素（消费者使用take()方法或带时间限制的poll()方法时），transfer方法可以把生产者传入的元素立刻transfer（传输）给消费者。如果没有消费者在等待接收元素，transfer方法会将元素存放在队列的tail节点，并等到该元素被消费者消费了才返回。
tryTransfer方法。则是用来试探下生产者传入的元素是否能直接传给消费者。如果没有消费者等待接收元素，则返回false。和transfer方法的区别是tryTransfer方法无论消费者是否接收，方法立即返回。而transfer方法是必须等到消费者消费了才返回。
LinkedBlockingDeque是一个由链表结构组成的双向阻塞队列。所谓双向队列指的你可以从队列的两端插入和移出元素。双端队列因为多了一个操作队列的入口，在多线程同时入队时，也就减少了一半的竞争。相比其他的阻塞队列，LinkedBlockingDeque多了addFirst，addLast，offerFirst，offerLast，peekFirst，peekLast等方法，以First单词结尾的方法，表示插入，获取（peek）或移除双端队列的第一个元素。以Last单词结尾的方法，表示插入，获取或移除双端队列的最后一个元素。另外插入方法add等同于addLast，移除方法remove等效于removeFirst。但是take方法却等同于takeFirst，不知道是不是Jdk的bug，使用时还是用带有First和Last后缀的方法更清楚。
线程池原理？
1，为什么要使用线程池
降低创建线程和销毁线程的性能开销
提高响应速度，当有新任务需要执行是不需要等待线程创建就可以立马执行
合理的设置线程池大小可以避免因为线程数超过硬件资源瓶颈带来的问题
2，线程池有哪几种类型
Executors 的工厂方法，就可以使用线程池：
newFixedThreadPool：该方法返回一个固定数量的线程池，线程数不变，当有一个任务提交时，若线程池中空闲，则立即执行，若没有，则会被暂缓在一个任务队列中，等待有空闲的线程去执行。
newSingleThreadExecutor: 创建一个线程的线程池，若空闲则执行，若没有空闲线程则暂缓在任务队列中。
newCachedThreadPool：返回一个可根据实际情况调整线程个数的线程池，不限制最大线程数量，若用空闲的线程则执行任务，若无任务则不创建线程。并且每一个空闲线程会在 60 秒后自动回收
newScheduledThreadPool: 创建一个可以指定线程的数量的线程池，但是这个线程池还带有延迟和周期性执行任务的功能，类似定时器。
3，线程池有哪几种工作队列？
ArrayBlockingQueue （有界队列）：是一个基于数组结构的有界阻塞队列，此队列按 FIFO（先进先出）原则对元素进行排序。
LinkedBlockingQueue （*队列）：一个基于链表结构的阻塞队列，此队列按FIFO （先进先出） 排序元素，吞吐量通常要高于ArrayBlockingQueue。静态工厂方法Executors.newFixedThreadPool()使用了这个队列。
SynchronousQueue（同步队列）: 一个不存储元素的阻塞队列。每个插入操作必须等到另一个线程调用移除操作，否则插入操作一直处于阻塞状态，吞吐量通常要高于LinkedBlockingQueue，静态工厂方法Executors.newCachedThreadPool使用了这个队列。
DelayQueue（延迟队列）：一个任务定时周期的延迟执行的队列。根据指定的执行时间从小到大排序，否则根据插入到队列的先后排序。指定时间到了之后，才能出队列；队列头的离出队时间最近。
PriorityBlockingQueue（优先级队列）: 一个具有优先级的无限阻塞队列。
ArrayListQueue、LinkedBlockingQueue、SynchronousQueue是阻塞队列
有界队列：ArrayBl
*队列：
有界队列
ArrayBlockingQueue：一个由数组结构组成的有界阻塞队列。
LinkedBlockingQueue：一个由链表结构组成的有界阻塞队列。
*队列
PriorityBlockingQueue：一个支持优先级排序的*阻塞队列。
DelayQueue：一个使用优先级队列实现的延迟*阻塞队列。
SynchronousQueue：一个内部只能包含一个元素的队列。。
4. 怎么理解*队列和有界队列
有界队列即长度有限，满了以后ArrayBlockingQueue会插入阻塞。
*队列就是里面能放无数的东西而不会因为队列长度限制被阻塞，但是可能会出现OOM异常。
5. 线程池中的几种重要的参数及流程
1.向线程池提交任务时，会首先判断线程池中的线程数是否大于设置的核心线程数，如果不大于，就创建一个核心线程来执行任务。
2.如果大于核心线程数，就会判断缓冲队列是否满了，如果没有满，则放入队列，等待线程空闲时执行任务。
3.如果队列已经满了，则判断是否达到了线程池设置的最大线程数，如果没有达到，就对线程做扩让，创建临时线程来执行任务。
4.如果已经达到了最大线程数，则执行指定的拒绝策略。这里需要注意队列的判断与最大线程数判断的顺序，不要搞反。
public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler) { if (corePoolSize < 0 || maximumPoolSize <= 0 || maximumPoolSize < corePoolSize || keepAliveTime < 0) throw new IllegalArgumentException(); if (workQueue == null || threadFactory == null || handler == null) throw new NullPointerException(); this.corePoolSize = corePoolSize; this.maximumPoolSize = maximumPoolSize; this.workQueue = workQueue; this.keepAliveTime = unit.toNanos(keepAliveTime); this.threadFactory = threadFactory; this.handler = handler; }
corePoolSize：核心池的大小，在创建了线程池后，默认情况下，线程池中并没有任何线程，而是等待有任务到来才创建线程去执行任务，当有任务来之后，就会创建一个线程去执行任务，当线程池中的线程数目达到corePoolSize后，就会把到达的任务放到缓存队列当中
maximumPoolSize：线程池最大线程数最大线程数
keepAliveTime：表示线程没有任务执行时最多保持多久时间会终止
unit：参数keepAliveTime的时间单位TimeUtil类的枚举类（DAYS、HOURS、MINUTES、SECONDS 等）
workQueue：阻塞队列，用来存储等待执行的任务
threadFactory：线程工厂，主要用来创建线程
handler：拒绝处理任务的策略
----AbortPolicy：丢弃任务并抛出 RejectedExecutionException 异常。（默认这种）
----DiscardPolicy：也是丢弃任务，但是不抛出异常
----DiscardOldestPolicy：丢弃队列最前面的任务，然后重新尝试执行任务（重复此过程）
-----CallerRunsPolicy：由调用线程处理该任务
6.线程池的数量如何确定？
在遇到这类问题时，先冷静下来分析
需要分析线程池执行的任务的特性： CPU 密集型还是 IO 密集型
每个任务执行的平均时长大概是多少，这个任务的执行时长可能还跟任务处理逻辑是否涉及到网络传输以及底层系统资源依赖有关系
如果是 CPU 密集型，主要是执行计算任务，响应时间很快，cpu 一直在运行，这种任务 cpu的利用率很高，那么线程数的配置应该根据 CPU 核心数来决定，CPU 核心数=最大同时执行线程数，加入 CPU 核心数为 4，那么服务器最多能同时执行 4 个线程。过多的线程会导致上下文切换反而使得效率降低。那线程池的最大线程数可以配置为 cpu 核心数+1
如果是 IO 密集型，主要是进行 IO 操作，执行 IO 操作的时间较长，这是 cpu 出于空闲状态，导致 cpu 的利用率不高，这种情况下可以增加线程池的大小。这种情况下可以结合线程的等待时长来做判断，等待时间越高，那么线程数也相对越多。一般可以配置 cpu 核心数的 2 倍。
一个公式：线程池设定最佳线程数目 = （（线程池设定的线程等待时间+线程 CPU 时间）/线程 CPU 时间 ）* CPU 数目
这个公式的线程 cpu 时间是预估的程序单个线程在 cpu 上运行的时间（通常使用 loadrunner测试大量运行次数求出平均值）
Callable和Future
Callable和Future，它俩很有意思的，一个产生结果，一个拿到结果。
Callable接口类似于Runnable，从名字就可以看出来了，但是Runnable不会返回结果，并且无法抛出返回结果的异常，而Callable功能更强大一些，被线程执行后，可以返回值，这个返回值可以被Future拿到，也就是说，Future可以拿到异步执行任务的返回值，
为什么会出现 Callable 和 Future？
创建线程的2种方式，一种是直接继承 Thread，另外一种就是实现 Runnable 接口。
这2种方式都有一个缺陷就是：在执行完任务之后无法获取执行结果。
如果需要获取执行结果，就必须通过共享变量或者使用线程通信的方式来达到效果，这样使用起来就比较麻烦。
从 Java 1.5 开始，就提供了 Callable 和 Future，通过它们可以在任务执行完毕之后得到任务执行结果。
Callable 接口代表一段可以调用并返回结果的代码。Future 接口表示异步任务，是还没有完成的任务给出的未来结果。所以说 Callable 用于产生结果，Future 用于获取结果。
Callable 与 Runnable区别
java.lang.Runnable 吧，它是一个接口，在它里面只声明了一个 run() 方法：
public interface Runnable{ public abstract void run(); }
由于 run() 方法返回值为 void 类型，所以在执行完任务之后无法返回任何结果。
Callable 位于 java.util.concurrent 包下，它也是一个接口，在它里面也只声明了一个方法，只不过这个方法叫做 call()：
public interface Callable<V>{ V call() throws Exception; }
可以看到，这是一个泛型接口，call() 函数返回的类型就是传递进来的V类型。
如何使用 Callable 呢？
一般情况下是配合 ExecutorService 来使用的，在 ExecutorService 接口中声明了若干个submit方法的重载版本：
<T> Future<T> submit(Callable<T> task); <T> Future<T> submit(Runnable task, T result); Future<?> submit(Runnable task);
第一个 submit 方法里面的参数类型就是 Callable。
暂时只需要知道 Callable 一般是和 ExecutorService 配合来使用的，具体的使用方法讲在后面讲述。
一般情况下我们使用第一个 submit 方法和第三个 submit 方法，第二个 submit 方法很少使用。
Future
Future 就是对于具体的 Runnable 或者 Callable 任务的执行结果进行取消、查询是否完成、获取结果。必要时可以通过 get 方法获取执行结果，该方法会阻塞直到任务返回结果。
Future 类位于 java.util.concurrent 包下，它是一个接口：
public interface Future<V> { boolean cancel(boolean mayInterruptIfRunning); boolean isCancelled(); boolean isDone(); V get() throws InterruptedException, ExecutionException; V get(long timeout, TimeUnit unit) throws InterruptedException, ExecutionException, TimeoutException; }
在Future接口中声明了5个方法，下面依次解释每个方法的作用：
cancel 方法用来取消任务，如果取消任务成功则返回 true，如果取消任务失败则返回 false。参数 mayInterruptIfRunning 表示是否允许取消正在执行却没有执行完毕的任务，如果设置 true，则表示可以取消正在执行过程中的任务。如果任务已经完成，则无论 mayInterruptIfRunning 为 true 还是 false，此方法肯定返回 false，即如果取消已经完成的任务会返回 false；如果任务正在执行，若 mayInterruptIfRunning 设置为 true，则返回 true，若 mayInterruptIfRunning 设置为 false，则返回 false；如果任务还没有执行，则无论 mayInterruptIfRunning 为 true 还是 false，肯定返回 true。
isCancelled 方法表示任务是否被取消成功，如果在任务正常完成前被取消成功，则返回 true。
isDone 方法表示任务是否已经完成，若任务完成，则返回 true；
get() 方法用来获取执行结果，这个方法会产生阻塞，会一直等到任务执行完毕才返回；
get(long timeout, TimeUnit unit) 用来获取执行结果，如果在指定时间内，还没获取到结果，就直接返回 null。
也就是说Future提供了三种功能：
1）判断任务是否完成；
2）能够中断任务；
3）能够获取任务执行结果。
因为 Future 只是一个接口，所以是无法直接用来创建对象使用的，因此就有了下面的 FutureTask。
FutureTask
FutureTask 实现了 RunnableFuture 接口，这个接口的定义如下：
public interface RunnableFuture<V> extends Runnable, Future<V> { void run(); }
可以看到这个接口实现了 Runnable 和 Future 接口，接口中的具体实现由 FutureTask 来实现。这个类的两个构造方法如下 ：
public FutureTask(Callable<V> callable) { if (callable == null) throw new NullPointerException(); sync = new Sync(callable); } public FutureTask(Runnable runnable, V result) { sync = new Sync(Executors.callable(runnable, result)); }
如上提供了两个构造函数，一个以 Callable 为参数，另外一个以 Runnable 为参数。这些类之间的关联对于任务建模的办法非常灵活，允许你基于 FutureTask 的 Runnable 特性（因为它实现了 Runnable 接口），把任务写成 Callable，然后封装进一个由执行者调度并在必要时可以取消的 FutureTask。
FutureTask 可以由执行者调度，这一点很关键。它对外提供的方法基本上就是Future和Runnable接口的组合：get()、cancel、isDone()、isCancelled() 和 run()，而 run() 方法通常都是由执行者调用，我们基本上不需要直接调用它。
Callable与Future讲解 简书版本
谈谈synchronized与ReentrantLock的区别？
(1)底层实现上来说，synchronized 是JVM层面的锁，是Java关键字，通过monitor对象来完成（monitorenter与monitorexit），对象只有在同步块或同步方法中才能调用wait/notify方法，ReentrantLock 是从jdk1.5以来（java.util.concurrent.locks.Lock）提供的API层面的锁。
synchronized 的实现涉及到锁的升级，具体为无锁、偏向锁、自旋锁、向OS申请重量级锁，ReentrantLock实现则是通过利用CAS（CompareAndSwap）自旋机制保证线程操作的原子性和volatile保证数据可见性以实现锁的功能。
(2)synchronized 不需要用户去手动释放锁，synchronized 代码执行完后系统会自动让线程释放对锁的占用； ReentrantLock则需要用户去手动释放锁，如果没有手动释放锁，就可能导致死锁现象。一般通过lock()和unlock()方法配合try/finally语句块来完成，使用释放更加灵活。
(3)synchronized是不可中断类型的锁，除非加锁的代码中出现异常或正常执行完成； ReentrantLock则可以中断，可通过trylock(long timeout,TimeUnit unit)设置超时方法或者将lockInterruptibly()放到代码块中，调用interrupt方法进行中断。
(4)synchronized为非公平锁 ReentrantLock则即可以选公平锁也可以选非公平锁，通过构造方法new ReentrantLock时传入boolean值进行选择，为空默认false非公平锁，true为公平锁。
(5)synchronized不能绑定； ReentrantLock通过绑定Condition结合await()/singal()方法实现线程的精确唤醒，而不是像synchronized通过Object类的wait()/notify()/notifyAll()方法要么随机唤醒一个线程要么唤醒全部线程。
(6)锁的对象 ：synchronzied锁的是对象，锁是保存在对象头里面的，根据对象头数据来标识是否有线程获得锁/争抢锁；ReentrantLock锁的是线程，根据进入的线程和int类型的state标识锁的获得/争抢。
谈谈synchronized与ReentrantLock的区别？
Cookie、Session、Token的区别于联系
Cookie工作流程：
（1）浏览器端第一次发送请求到服务器端
（2）服务器端创建Cookie，该Cookie中包含用户的信息，然后将该Cookie发送到浏览器端
（3）浏览器端再次访问服务器端时会携带服务器端创建的Cookie
（4）服务器端通过Cookie中携带的数据区分不同的用户
Session工作流程：
（1）浏览器端第一次发送请求到服务器端，服务器端创建一个Session，用于跟踪用户的状态，同时，给session对象分配一个唯一标识sessionId。为了管理session对象，以sessionId为键，以session对象为值，封装成Map集合。
（2）服务端产生响应时，将sessionId以cookie方式发送给客户端，存放在客户端浏览器的缓存中
（3）当客户端再次请求服务器，会将sessionId以cookie请求头的方式发送给服务器
（4）服务器端得到sessionId后，从Map集合中得到session对象，从而跟踪状态
Cookie与Session的对比
(1)cookie数据存放在客户的浏览器上，session数据放在服务器上
(2)cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,如果主要考虑到安全应当使用session
(3)session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，如果主要考虑到减轻服务器性能方面，应当使用COOKIE
(4)单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能3K。
(5)所以：将登陆信息等重要信息存放为SESSION;其他信息如果需要保留，可以放在COOKIE中
SSM项目：jsonp跨域请求原理
Jsonp 跨域原理。
（摘选） 浏览器的同源策略把跨域请求都禁止了，但是页面中的
Jsonp 跨域原理
Mybatis工作流程？
Mybatis高频面试题
Mybatis 插件原理？
Mybatis高频面试题
Spring Boot 约定大于配置原理？
约定大于配置如何实现
如何手写一个Starter？
先在Meta-Info下的Spring.facotry中配置EnableAutoConfig，然后将新写的类，加上@configuration，其中的方法 加上@Bean，@ConditionOn
SQL如何优化？
JVM OOM 如何处理？
synchronized中如何实现可重入？
synchronize深入理解
HashMap为什么不是线程安全的？
首先需要强调一点，HashMap的线程不安全体现在会造成死循环、数据丢失、数据覆盖这些问题。其中死循环和数据丢失是在JDK1.7中出现的问题，在JDK1.8中已经得到解决，然而1.8中仍会有数据覆盖这样的问题。
首先HashMap是线程不安全的，其主要体现：
在jdk1.7中，在多线程环境下，扩容时会造成环形链或数据丢失。
在jdk1.8中，在多线程环境下，会发生数据覆盖的情况
JDK1.7和JDK1.8中HashMap为什么是线程不安全的？
为什么都说 HashMap 是线程不安全的？ 简书 牛P版本？
ConcurrentHashMap总结 扩容过程
JDK8的ConcurrentHashMap扩容
在JDK8中彻底抛弃了JDK7的分段锁的机制，新的版本主要使用了Unsafe类的CAS自旋赋值+synchronized同步+LockSupport阻塞等手段实现的高效并发，代码可读性稍差。
ConcurrentHashMap的JDK8与JDK7版本的并发实现相比，最大的区别在于JDK8的锁粒度更细，理想情况下talbe数组元素的大小就是其支持并发的最大个数，在JDK7里面最大并发个数就是Segment的个数，默认值是16，可以通过构造函数改变一经创建不可更改，这个值就是并发的粒度，每一个segment下面管理一个table数组，加锁的时候其实锁住的是整个segment，这样设计的好处在于数组的扩容是不会影响其他的segment的，简化了并发设计，不足之处在于并发的粒度稍粗，所以在JDK8里面，去掉了分段锁，将锁的级别控制在了更细粒度的table元素级别，也就是说只需要锁住这个链表的head节点，并不会影响其他的table元素的读写，好处在于并发的粒度更细，影响更小，从而并发效率更好，但不足之处在于并发扩容的时候，由于操作的table都是同一个，不像JDK7中分段控制，所以这里需要等扩容完之后，所有的读写操作才能进行，所以扩容的效率就成为了整个并发的一个瓶颈点，好在Doug lea大神对扩容做了优化，本来在一个线程扩容的时候，如果影响了其他线程的数据，那么其他的线程的读写操作都应该阻
Put方法
1、判断Node[]数组是否初始化，没有则进行初始化操作 2、通过hash定位数组的索引坐标，是否有Node节点，如果没有则使用CAS进行添加（链表的头节点），添加失败则进入下次循环。 3、检查到内部正在扩容，就帮助它一块扩容。 4、如果f！=null，则使用synchronized锁住f元素（链表/红黑树的头元素）。如果是Node（链表结构）则执行链表的添加操作；如果是TreeNode（树型结构）则执行树添加操作。 5、判断链表长度已经达到临界值8（默认值），当节点超过这个值就需要把链表转换为树结构。 6、如果添加成功就调用addCount（）方法统计size，并且检查是否需要扩容
为什么要使用CAS+Synchronized取代Segment+ReentrantLock？
减少内存开销:如果使用ReentrantLock则需要节点继承AQS来获得同步支持，增加内存开销，而1.8中只有头节点需要进行同步。
内部优化:synchronized则是JVM直接支持的，JVM能够在运行时作出相应的优化措施：锁粗化、锁消除、锁自旋等等。
Synchronized中哪怕出现争抢了,只要线程可以在30到50次自旋里拿到锁,那么Synchronized就不会升级为重量级锁,而等待的线程也就不用被挂起,我们也就少了挂起和唤醒这个上下文切换的过程开销.
Java ConcurrentHashMap扩容机制
单例模式
设计模式之单例模式
JAVA设计模式之单例模式
饿汉式单例类
//饿汉式单例类.在类初始化时，已经自行实例化 public class Singleton1 { private Singleton1() {} private static final Singleton1 single = new Singleton1(); //静态工厂方法 public static Singleton1 getInstance() { return single; } }
为什么用使用饿汉式的单例类？
因此，在上述单例类被加载时，就会实例化一个对象并交给自己的引用，供系统使用。单例就是该类只能返回一个实例。
换句话说，在线程访问单例对象之前就已经创建好了。再加上，由于一个类在整个生命周期中只会被加载一次，因此该单例类只会创建一个实例。
也就是说，线程每次都只能也必定只可以拿到这个唯一的对象。即饿汉式单例天生就是线程安全的。
懒汉式单例类
//懒汉式单例类.在第一次调用的时候实例化自己 public class Singleton { private Singleton() {} private static Singleton single=null; //静态工厂方法 public static Singleton getInstance() { if (single == null) { single = new Singleton(); } return single; } }
**懒汉式单例类+synchronized **
//懒汉式单例类.在第一次调用的时候实例化自己 public class Singleton { private Singleton() {} private static Singleton single=null; public static synchronized Singleton getInstance() { if (single == null) { single = new Singleton(); } return single; } }
为什么要使用双重检查锁？
第一次校验：由于单例模式只需要创建一次实例，如果后面再次调用getUinqueSingle方法时，则直接返回之前创建的实例，因此大部分时间不需要执行同步方法里面的代码，大大提高了性能。
如果不加第一次校验的话，那跟上面的懒汉模式没什么区别，每次都要去竞争锁。
第二次校验：如果没有第二次校验，假设线程t1执行了第一次校验后，判断为null，这时t2也获取了CPU执行权，也执行了第一次校验，判断也为null。接下来t2获得锁，创建实例。这时t1又获得CPU执行权，由于之前已经进行了第一次校验，结果为null（不会再次判断），获得锁后，直接创建实例。结果就会导致创建多个实例。
所以需要在同步代码里面进行第二次校验，如果实例为空，则进行创建。
为什么要加Volatile关键字？
在java内存模型中，volatile 关键字作用可以是保证可见性或者禁止指令重排。
这里是因为 uniqueSingle=new Singleton()，它并非是一个原子操作，事实上，在 JVM 中上述语句至少做了以下这 3 件事：
第一步是给 singleton 分配内存空间；
第二步开始调用 Singleton 的构造函数等，来初始化 singleton；
第三步，将 singleton 对象指向分配的内存空间（执行完这步 singleton 就不是 null 了）。
这里需要留意一下 1-2-3 的顺序，因为存在指令重排序的优化，也就是说第 2 步和第 3 步的顺序是不能保证的，最终的执行顺序，可能是 1-2-3，也有可能是 1-3-2
//懒汉式单例类.在第一次调用的时候实例化自己 public class Singleton { private Singleton() {} private static Singleton single=null; public static Singleton getInstance() { if (singleton == null) { synchronized (Singleton.class) { if (singleton == null) { singleton = new Singleton(); } } } return singleton; } }
- 而volatile关键字避免了指令重排
**懒汉式单例类+双重检查锁+Volatile **
静态内部类为什么是线程安全的？
静态内部类的优点是：外部类加载时并不需要立即加载内部类，内部类不被加载则不去初始化INSTANCE，故而不占内存。具体来说当SingleTon第一次被加载时，并不需要去加载SingleTonHoler，只有当getInstance()方法第一次被调用时，使用INSTANCE的时候,才会导致虚拟机加载SingleTonHoler类。这种方法不仅能确保线程安全，也能保证单例的唯一性，同时也延迟了单例的实例化。
静态内部类
public class Singleton { private Singleton(){ } public static Singleton getInstance(){ return Inner.instance; } private static class Inner { private static final Singleton instance = new Singleton(); } }
静态内部类单例模式的核心原理为对于一个类，JVM在仅用一个类加载器加载它时，静态变量的赋值在全局只会执行一次！
单例模式，静态内部类原理剖析
单例模式（Singleton Pattern）之静态内部类
众所周知，单例模式是创建型模式，都会新建一个实例。那么一个重要的问题就是反序列化。当实例被写入到文件到反序列化成实例时，我们需要重写readResolve方法，以让实例唯一。
ConcurrentHashMap的扩容方法 超级无敌牛逼版本
流程如下：
根据操作系统的 CPU 核数和集合 length 计算每个核一轮处理桶的个数，最小是16
修改 transferIndex 标志位，每个线程领取完任务就减去多少，比如初始大小是transferIndex = table.length = 64，每个线程领取的桶个数是16，第一个线程领取完任务后transferIndex = 48，也就是说第二个线程这时进来是从第 48 个桶开始处理，再减去16，依次类推，这就是多线程协作处理的原理
领取完任务之后就开始处理，如果桶为空就设置为 ForwardingNode ,如果不为空就加锁拷贝，只有这里用到了 synchronized 关键字来加锁，为了防止拷贝的过程有其他线程在put元素进来。拷贝完成之后也设置为 ForwardingNode节点。
如果某个线程分配的桶处理完了之后，再去申请，发现 transferIndex = 0，这个时候就说明所有的桶都领取完了，但是别的线程领取任务之后有没有处理完并不知道，该线程会将 sizeCtl 的值减1，然后判断是不是所有线程都退出了，如果还有线程在处理，就退出
直到最后一个线程处理完，发现 sizeCtl = rs<< RESIZE_STAMP_SHIFT 也就是标识符左移 16 位，才会将旧数组干掉，用新数组覆盖，并且会重新设置 sizeCtl 为新数组的扩容点。
以上过程总的来说分成两个部分：
分配任务：这部分其实很简单，就是把一个大的数组给切分，切分多个小份，然后每个线程处理其中每一小份，当然可能就只有1个或者几个线程在扩容，那就一轮一轮的处理，一轮处理一份
处理任务：复制部分主要有两点，第一点就是加锁，第二点就是处理完之后置为ForwardingNode来占位标识这个位置被迁移过了。
ConcurrentHashMap源码解析，多线程扩容