一、equals()和==，以及HashCode()

• =号 如果是值引用，比较值是否相等； 如果是对象引用，比较对象内存地址是否相同
• equals()方法中，默认使用等号，如果说我们想要判断对象是否相等需要重写equals方法

HashCode()
Object 的 hashcode 方法是本地方法，也就是用 c 语言或 c++ 实现的，该方法通常用来将对象的 内存地址 转换为整数之后返回。

一般情况下重写equals方法的同时需要重写HashCode，假如不重写HashCode会发生什么情况呢？
以HashSet为例子，我们放入new 相同对象放到HashSet中，会出现重复值。

因为对象在堆中存放在不同的地址上，hashCode是根据对象地址生成的，所以也不同，就存放到不同的位置

所以对于散列表，HashMap，HashSet，HashTable，如果用自定义的对象做key，需要重写hashcode和equals方法；
判断过程是这样的，比较equals中先比较Hashcode是否相等，再比较对象的属性是否相等。

二、String，StringBuffer，StringBuilder

String是被final修饰的不可变字符串
StringBuffer、StringBuilder是可变字符串，

• StringBuffer是线程安全的，使用synchronized关键字修饰
• StringBuilder是非线程安全的，StringBuilder 是没有对方法加锁同步的，所以毫无疑问，StringBuilder 的性能要远大于 StringBuffer
  StringBuffer 适用于用在多线程操作同一个 StringBuffer 的场景，如果是单线程场合 StringBuilder 更适合。

三、反射及应用的场景

反射机制是在运行状态中，对于任意一个类(指的是.class文件)，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法和属性；这种动态获取的信息以及动态调用对象的方法的功能称为java语言的反射机制。

反射应用的场景： 动态代理设计模式也采用了反射机制

• JDBC 的数据库的连接，Class.forName
• Spring 框架的 IOC（动态加载管理 Bean）创建对象以及 AOP（动态代理）功能都和反射有联系；

四、静态代理，JDK动态代理与Cglib动态代理

静态代理：

静态代理实现步骤:
定义一个接口及其实现类；
创建一个代理类同样实现这个接口
将目标对象注入进代理类，然后在代理类的对应方法调用目标类中的对应方法。这样的话，我们就可以通过代理类屏蔽对目标对象的访问，并且可以在目标方法执行前后做一些自己想做的事情。

**总结：**静态代理中，我们对目标对象的每个方法的增强都是手动完成的（后面会具体演示代码），非常不灵活（比如接口一旦新增加方法，目标对象和代理对象都要进行修改）且麻烦(需要对每个目标类都单独写一个代理类)。 实际应用场景非常非常少，日常开发几乎看不到使用静态代理的场景。
动态代理实现的目的和静态代理一样，都是对目标方法进行增强，而且让增强的动作和目标动作分开，达到解耦的目的

JDK动态代理产生的代理类和目标类实现了相同的接口；cglib动态代理产生的代理类是目标对象的子类。

五、HashSet、HashMap、HashTable、concurrentHashMap

HashMap是存储的是键值对，通过数组+链表的结构存储，结合了数据和链表这两种数据结构的特点，能够快速的定位以及插入删除。HashSet是基于HashMap实现的，所有放入 HashSet 中的集合元素实际上由 HashMap 的 key 来保存，HashSet不允许元素有重复的。HashTable的实现基本上与HashMap相同，它通过synchronized关键字实现了线程安全，HashTable的操作是无论是get还是put都会锁定整张表，concurrentHashMap降低了锁的粒度，JDK1.7之前使用分段锁，JDK1.8对数组的每个元素加锁。

HashMap与HashTable的区别：

HashMap 和 Hashtable 都实现了 Map 接口。主要的区别有：线程安全性，同步 (synchronization)，以及速度。

• 由于 HashMap 非线程安全，在只有一个线程访问的情况下，效率要高于 HashTable
• HashMap 允许将 null 作为一个 entry 的 key 或者 value，而 Hashtable 不允许。
• HashMap 把 Hashtable 的 contains 方法去掉了，改成 containsValue 和 containsKey。因为 contains 方法容易让人引起误解。
• Hashtable 继承自陈旧的 Dictionary 类，而 HashMap 是 Java1.2 引进的 Map 的一个实现。
• Hashtable 和 HashMap 扩容的方法不一样，HashTable 中 hash 数组默认大小 11，扩容方式是 old*2+1。HashMap 中 hash 数组的默认大小是 16，而且一定是 2 的指数，增加为原来的 2 倍，没有加 1。
• 两者通过 hash 值散列到 hash 表的算法不一样，HashTbale 是古老的除留余数法，直接使用 hashcode，而后者是强制容量为 2 的幂，
• 新根据 hashcode 计算 hash 值，在使用 hash 位与 （hash 表长度 – 1），也等价取膜，但更加高效，取得的位置更加分散，偶数，奇数保证了都会分散到。前者就不能保证。
• 另一个区别是 HashMap 的迭代器 (Iterator) 是 fail-fast 迭代器，而 Hashtable 的 enumerator 迭代器不是 fail-fast 的。所以当有其它线程改变了 HashMap 的结构（增加或者移除元素），将会抛出 ConcurrentModificationException，但迭代器本身的 remove() 方法移除元素则不会抛出 ConcurrentModificationException 异常。但这并不是一个一定发生的行为，要看 JVM。这条同样也是 Enumeration 和 Iterator 的区别。

HashMap的get和put，插入和获取原理？

判断数组是否为空，为空进行初始化;
不为空，计算 k 的 hash 值，通过(n - 1) & hash计算应当存放在数组中的下标 index;
查看 table[index] 是否存在数据，没有数据就构造一个Node节点存放在 table[index] 中；
存在数据，说明发生了hash冲突(存在二个节点key的hash值一样), 继续判断key是否相等，相等，用新的value替换原数据
(onlyIfAbsent为false)；
如果不相等，判断当前节点类型是不是树型节点，如果是树型节点，创造树型节点插入红黑树中；
如果不是树型节点，创建普通Node加入链表中；判断链表长度是否大于 8， 大于的话链表转换为红黑树；
插入完成之后判断当前节点数是否大于阈值，如果大于开始扩容为原数组的二倍。

HashMap::getNode的流程是:
.1 首先会判断数组是否不等于null,或者数组的长度是否大于0，如果不满足,就说明HashMap里没有数据，直接返回null。
.2 通过 hash & (table.length - 1)获取该key对应的数据节点的hash槽;
.3 判断首节点是否为空, 为空则直接返回空;
.4 再判断首节点.key 是否和目标值相同, 相同则直接返回(首节点不用区分链表还是红黑树);
.5 首节点.next为空, 则直接返回空;
.6 首节点是树形节点, 则进入红黑树数的取值流程, 并返回结果;
.7 进入链表的取值流程, 并返回结果;

HashMap中JDK1.7与JDK1.8的区别

1、数据结构
JDK 1.7之前使用链表+数组；JDK1.8之后，使用链表+数组+红黑树；当链表的深度达到8的时候，也就是默认阈值，就会自动扩容把链表转成红黑树的数据结构来把时间复杂度从O（n）变成O（logN），提高了效率）
2，插入方式
头插与尾插：JDK1.7用的是头插法，而JDK1.8及之后使用的都是尾插法，那么他们为什么要这样做呢？因为JDK1.7是用单链表进行的纵向延伸，当采用头插法时会容易出现逆序且环形链表死循环问题。但是在JDK1.8之后是因为加入了红黑树使用尾插法，能够避免出现逆序且链表死循环的问题。
3，扩容
JDK 1.7是先扩容后插入，JDK 1.8则是先插入后扩容
4，hash运算
JDK 1.7是4次位运算+5次异或，JDK 1.8是1次位运算+1次异或

JDK1.7与1.8的区别

HashMap在并发编程中存在什么问题？

1. 多线程扩容，引起的死循环（JDK1.7），在JDK1.8中已经解决
   (2) 多线程put的时候可能导致元素丢失
   (3) put非null元素后get出来的却是null

HashMap死循环遍历

HashMap死循环遍历

处理冲突的方法

1. 开放寻址法；Hi=(H(key) + di) MOD m, i=1,2,…, k(k<=m-1)，其中H(key)为散列函数，m为散列表长，di为增量序列，可有下列三种取法：
　　（1） di=1,2,3,…, m-1，称线性探测再散列；
　　（2）di=1^2, (-1)^2, 2^2,(-2)2, (3)^2, …, ±(k)^2,(k<=m/2)称二次探测再散列;
　　（3）di=伪随机数序列，称伪随机探测再散列。 ==
　　2. 再散列法：Hi=RHi(key), i=1,2,…,k RHi均是不同的散列函数，即在同义词产生地址冲突时计算另一个散列函数地址，直到冲突不再发生，这种方法不易产生“聚集”，但增加了计算时间。
　　3. 链地址法(拉链法)
　　4. 建立一个公共溢出区

为什么扩容是2的次幂?

HashMap为了存取高效，要尽量较少碰撞，就是要尽量把数据分配均匀，每个链表长度大致相同，这个实现就在把数据存到哪个链表中的算
&运算速度快，至少比%取模运算块
能保证 索引值 肯定在 capacity 中，不会超出数组长度，并且如果不是2的n次幂的话，就会出现重复索引的问题
(n - 1) & hash，当n为2次幂时，会满足一个公式：(n - 1) & hash = hash % n

为什么为什么采用hashcode的高16位和低16位异或能降低hash碰撞?

当数组的长度很短时，只有低位数的hashcode值能参与运算。而让高16位参与运算可以更好的均匀散列，减少碰撞，进一步降低hash冲突的几率。并且使得高16位和低16位的信息都被保留了。

而在这里采用异或运算而不采用& ，| 运算的原因是 异或运算能更好的保留各部分的特征，如果采用&运算计算出来的值的二进制会向1靠拢，采用|运算计算出来的值的二进制会向0靠拢

hash函数如何实现？

hash函数是先拿到通过key 的hashcode，是32位的int值，然后让hashcode的高16位和低16位进行异或操作；
这个也叫扰动函数，这么设计有二点原因：
一定要尽可能降低hash碰撞，越分散越好；
算法一定要尽可能高效，因为这是高频操作, 因此采用位运算；

resize运算的步骤

1. 先要得到扩容后的容量和阈值
   • 散列表未初始化：默认初始化或根据指定容量阈值进行初始化
   • 已初始化：判断是否达到最大容量：1. 已达到最大容量，不扩容，将最大阈值设为int最大值；2. 未达到最大容量，正常扩容，
   2.通过得到的容量和阈值初始化新的散列表
   • 循环旧的散列表：1. 桶位null，跳过 2. 桶只有一个元素Node.next = null,重新hash计算index 3. 桶为链表，遍历链表并通过e.hash & oldCap将链表分为高低位放入新散列表中,低位链位置index不变，高位连为index+oldTable 4. 桶位红黑树，将红黑树拆分分高低位链表，链表长度小于等于6，直接放入新桶，否则重新生成树入桶

六、volitile和synchronized的关键字

sychronized更加轻量级的同步锁
在访问volatile 变量时不会执行加锁操作，因此也就不会使执行线程阻塞，因此volatile 变量是一种比sychronized 关键字更轻量级的同步机制。volatile 适合这种场景：一个变量被多个线程共享，线程直接给这个变量赋值。

volitile关键字：

Volitile关键字：保证内存可见性，禁止指令重排序

内存可见性问题：在多线程环境下，读和写发生在不同的线程中，可能会出现：读线程不能及时的读取到其他线程写入的最新的值，这就是所谓的可见性问题。

从硬件层面：CPU/内存/IO设备之间存在读取速度的差距和存储大小的差异；为了减小各类型设备之间的读取效率差异，增加CPU的处理效率；CPU层面增加了高速缓存，但是带了缓存一致性问题，

缓存执行问题的两种解决方案：

• 总线锁，当其中一个处理器要对共享内存进行操作的时候，在总线上发出一个LOCK#的信号，这个信号使得其他CPU无法通过总线来访问到共享内存中的数据，总线锁定把CPU和内存之间的通信锁住了，在锁定期间，其他处理器不能操作其他内存地址的数据，所以总线锁的开销比较大，这种机制显然是不合理的。
• 缓存锁，最好的办法是控制控制锁的保护粒度，我们只需要保证对于被多个CPU缓存的同一份数据是一致的就行。在P6架构的CPU后，引入了缓存锁，如果当前数据已经被CPU缓存了，并且是要写回到主内存中的，就可以采用缓存锁来解决问题。MESI有四种状态，E独占，M修改，S共享，I无效，根据MESI，CPU某核（比如CPU1）的缓存行（包含变量x）是M、S或E的时候，如果总线嗅探到了变量x被其他核(比如CPU1)执行了写操作(remote write)，那么CPU0的缓存行会置于无效I（无效），在CUP0后续对该变量的操作的嘶吼发现是I状态，就会去主存中同步最新的值。
• Store Bufferes（写缓冲区）

通过内存屏障禁止指令重排序
X86的memory barrier指令包括lfence(读屏障) sfence(写屏障) mfence(全屏障)

Store Memory Barrier(写屏障) ，告诉处理器在写屏障之前的所有已经存储在存储缓存(storebufferes)中的数据同步到主内存，简单来说就是使得写屏障之前的指令的结果对屏障之后的读或者写是可见的
Load Memory Barrier(读屏障) ，处理器在读屏障之后的读操作,都在读屏障之后执行。配合写屏障，使得写屏障之前的内存更新对于读屏障之后的读操作是可见的
Full Memory Barrier(全屏障) ，确保屏障前的内存读写操作的结果提交到内存之后，再执行屏障后的读写操作

JMM层面：
经过上面的分析，我们已经知道了volatile变量可以通过缓存一致性协议保证每个线程都能获得最新值，即满足数据的“可见性”。

除了显示引用volatile关键字能够保证可见性以外，在Java中，还有很多的可见性保障的规则。
从JDK1.5开始，引入了一个happens-before的概念来阐述多个线程操作共享变量的可见性问题。所以
我们可以认为在JMM中，如果一个操作执行的结果需要对另一个操作课件，那么这两个操作必须要存在
happens-before关系。这两个操作可以是同一个线程，也可以是不同的线程

synchronized关键字

Syncchronized锁住了什么？

Synchronized锁的3种使用形式（使用场景）：
Synchronized修饰普通同步方法：锁对象当前实例对象；
Synchronized修饰静态同步方法：锁对象是当前的类Class对象；
Synchronized修饰同步代码块：锁对象是Synchronized后面括号里配置的对象，这个对象可以是某个对象（xlock），也可以是某个类（Xlock.class）；

Syncchronized的锁存在哪里？

对象是存放在堆内存中，对象大致可以分为三个部分，分别是对象头，实例变量，填充字节。

• 对象头主要是由MarkWord和Klass Point(类型指针组成)。
• 实例变量存储的是对象的属性信息，包括父类的属性信息，按照4字节对齐
• 填充字符，因为虚拟机要求对象字节必须是8字节的整数倍。

Syncchronized锁的对象存储在对象头的MarkWord中。每一个JAVA对象都会与一个监视器monitor关联，我们可以把它理解成为一把锁，当一个线程想要执行一段被synchronized修饰的同步方法或者代码块时，该线程得先获取到synchronized修饰的对象对应的monitor。monitorenter表示去获得一个对象监视器。monitorexit表示释放monitor监视器的所有权，使得其他被阻塞的线程可以尝试去获得这个监视器

锁分为四种类型：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态（级别从低到高）
除了 偏向锁可以转换为无状态锁，其他的锁都只能升不能降。

偏向所锁，轻量级锁都是乐观锁，重量级锁是悲观锁。 一个对象刚开始实例化的时候，没有任何线程来访问它的时候。它是可偏向的，意味着，它现在认为只可能有一个线程来访问它，所以当第一个线程来访问它的时候，它会偏向这个线程，此时，对象持有偏向锁。偏向第一个线程，这个线程在修改对象头成为偏向锁的时候使用CAS操作，并将对象头中的ThreadID改成自己的ID，之后再次访问这个对象时，只需要对比ID，不需要再使用CAS在进行操作。一旦有第二个线程访问这个对象，因为偏向锁不会主动释放，所以第二个线程可以看到对象时偏向状态，这时表明在这个对象上已经存在竞争了，检查原来持有该对象锁的线程是否依然存活，如果挂了，则可以将对象变为无锁状态，然后重新偏向新的线程，如果原来的线程依然存活，则马上执行那个线程的操作栈，检查该对象的使用情况，如果仍然需要持有偏向锁，则偏向锁升级为轻量级锁，（偏向锁就是这个时候升级为轻量级锁的）。如果不存在使用了，则可以将对象回复成无锁状态，然后重新偏向。 轻量级锁认为竞争存在，但是竞争的程度很轻，一般两个线程对于同一个锁的操作都会错开，或者说稍微等待一下（自旋），另一个线程就会释放锁。 但是当自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁膨胀为重量级锁，重量级锁使除了拥有锁的线程以外的线程都阻塞，防止CPU空转。

总结：偏向锁：只有一个线程进入临界区；
轻量级锁：多个线程交替进入临界区；
重量级锁：多个线程同时进入临界区。

volatile与 synchronized的区别

通过使用volatile关键字，是强制的从公共内存中读取变量的值, 是线程同步的轻量级实现, 所以volatile性能肯定比synchronized要好，并且 volatile只能修饰于变量，而synchronized可以修饰方法，以及代码块。
随着JDK新版本的发布，synchronized关键字在执行效率上得到很大提升，在开发中使用synchronized关键字的比率还是比较大的。
多线程访问volatile不会发生阻塞，而synchronized会出现阻塞。
volatile能保证数据的可见性，但不能保证原子性;而synchronized可以保证原子性，也可以间接保证可见性，因为它会将私有内存和公共内存中的数据做同步。

Lock与synchronized的区别

synchronized的缺陷
　在上面一篇文章中，我们了解到如果一个代码块被synchronized修饰了，当一个线程获取了对应的锁，并执行该代码块时，其他线程便只能一直等待，等待获取锁的线程释放锁，而这里获取锁的线程释放锁只会有两种情况：
　　1）获取锁的线程执行完了该代码块，然后线程释放对锁的占有；
　　2）线程执行发生异常，此时JVM会让线程自动释放锁。

那么如果这个获取锁的线程由于要等待IO或者其他原因（比如调用sleep方法）被阻塞了，但是又没有释放锁，其他线程便只能干巴巴地等待，试想一下，这多么影响程序执行效率。
　　因此就需要有一种机制可以不让等待的线程一直无期限地等待下去（比如只等待一定的时间或者能够响应中断），通过Lock就可以办到。
　　再举个例子：当有多个线程读写文件时，读操作和写操作会发生冲突现象，写操作和写操作会发生冲突现象，但是读操作和读操作不会发生冲突现象。

但是采用synchronized关键字来实现同步的话，就会导致一个问题：
　　如果多个线程都只是进行读操作，所以当一个线程在进行读操作时，其他线程只能等待无法进行读操作。
　　因此就需要一种机制来使得多个线程都只是进行读操作时，线程之间不会发生冲突，通过Lock就可以办到。
　　另外，通过Lock可以知道线程有没有成功获取到锁。这个是synchronized无法办到的。

总结一下，也就是说Lock提供了比synchronized更多的功能。但是要注意以下几点：
　　1）Lock不是Java语言内置的，synchronized是Java语言的关键字，因此是内置特性。Lock是一个类，通过这个类可以实现同步访问；
　　2）Lock和synchronized有一点非常大的不同，采用synchronized不需要用户去手动释放锁，当synchronized方法或者synchronized代码块执行完之后，系统会自动让线程释放对锁的占用；而Lock则必须要用户去手动释放锁，如果没有主动释放锁，就有可能导致出现死锁现象。
Lock包含，上锁，获取锁，释放锁，

public interface Lock {
    void lock();   //就是用来获取锁。如果锁已被其他线程获取，则进行等待。
    void lockInterruptibly() throws InterruptedException;//当通过这个方法去获取锁时，如果线程正在等待获取锁，则这个线程能够响应中断，即中断线程的等待状态
    boolean tryLock();  //尝试获取锁
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
    void unlock(); //释放锁
    Condition newCondition();
}
//lock 在使用中，强制上锁，不会被其他线程interrupt住；而trylock可以在规定的interval时间内，尝试获取锁，如果获取到，返回true，否则false。trylock随时可以被其他线程interrupt中断掉。

CAS？CAS 有什么缺陷，如何解决？

CAS：Compare and Swap，即比较再交换。

CAS算法理解：CAS是一种无锁算法，CAS有3个操作数，内存值E，旧的预期值V，要修改的新值N。当且仅当预期值V和内存值E相同时，将内存值E修改为N，否则什么都不做。

CAS带来的问题：
1.ABA问题
因为CAS需要在操作值的时候，检查值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么CAS进行检查的时候发现它的值没有发生变化，但是实际上却变化了。ABA问题的解决思路就是使用版本号。在变量前面加上版本号，每次变量更新的时候把版本号加1，那么A->B->A就会变成1A->2B->3A。从Java 1.5开始，JDK的Atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法的作用是首先检查当前引用是否等于预期引用，并且检查当前的标志是否等于预期标志，如果全部相等，则以原子方式将该应用和该标志的值设置为给定的更新值。

2.循环时间长开销大
自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销，如果JVM能支持处理器提供的pause指令，那么效率会有一定的提升。pause指令有两个作用：第一，它可以延迟流水线执行指令（de-pipeline），使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零；第二，它可以避免在循环的时候因内存顺序冲突（Memory Order Violation）而引起CPU流水线被清空，从而提高CPU的实行效率。

3.只能保证一个共享变量的原子操作
当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候可以用锁。还有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如，有两个共享变量i=2,j=a,合并一下ji=2a,然后用CAS来操作ij。从Java 1.5开始，JDK提供了AtomicReference类来保证引用对象之前的原子性，就可以把多个变量放在一个对象里来进行CAS操作。

ThreadLocal作用、原理以及适用范围

ThreadLocal：线程本地变量，它为每个使用该对象的线程创建了一个独立的变量副本。
原理：在Thread类中存在一个ThreaLocalMap变量，ThreadLocalMap中又有一个Entry类型的数组，而这个Entry对象则以ThreadLocal的弱引用为key。当我们调用ThreadLocal的get()方法时，会先获取当前线程的ThreadLocalMap对象，并将当前ThreadLocal对象作为key（实际上key为ThreadLocal的弱引用），去它的Entry数组中寻找我们需要的value。就这是我们说ThreadLocal为每个线程创建了一个变量副本的意思，线程对自己ThreadLocalMap中的值进行操作时，并不会对其它线程造成影响。

内存泄漏问题：

ThreadLocalMap使用ThreadLocal的弱引用作为key，如果一个ThreadLocal没有外部强引用来引用它，那么系统 GC 的时候，这个ThreadLocal势必会被回收，这样一来，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永远无法回收，造成内存泄漏。
其实，ThreadLocalMap的设计中已经考虑到这种情况，也加上了一些防护措施：在ThreadLocal的get(),set(),remove()的时候都会清除线程ThreadLocalMap里所有key为null的value。
解决方案：线程执行前重新调用set()设置值。线程复用导致产生脏数据，如果复用线程在执行下个任务之前调用set()重新设置值，那么脏数据问题就不会出现了。

脏数据问题：脏数据问题：线程复用导致产生脏数据。由于线程池会复用Thread对象，进而Thread对象中的threalLocals也会被复用，导致Thread对象在执行其他任务时通过get()方法获取到之前任务设置的数据，从而产生脏数据。
解决方案：每次使用完ThreadLocal，都调用它的remove()方法，清除数据。
适用范围： 数据库连接、Session管理等。

举一个在实际中应用的例子，例如，我们有一个银行的BankDAO类和一个个人账户的PeopleDAO类，现在需要个人向银行进行转账，在PeopleDAO类中有一个账户减少的方法，BankDAO类中有一个账户增加的方法，那么这两个方法在调用的时候必须使用同一个Connection数据库连接对象，如果他们使用两个Connection对象，则会开启两段事务，可能出现个人账户减少而银行账户未增加的现象。

使用同一个Connection对象的话，在应用程序中可能会设置为一个全局的数据库连接对象，从而避免在调用每个方法时都传递一个Connection对象。问题是当我们把Connection对象设置为全局变量时，你不能保证是否有其他线程会将这个Connection对象关闭，这样就会出现线程安全问题。

解决办法就是在进行转账操作这个线程中，使用ThreadLocal中获取Connection对象，这样，在调用个人账户减少和银行账户增加的线程中，就能从ThreadLocal中取到同一个Connection对象，并且这个Connection对象为转账操作这个线程独有，不会被其他线程影响，保证了线程安全性。

什么是AQS，抽象队列同步器？

AQS定义就是抽象队列同步器，定义了锁的框架，具体实现由其子类完成，在AQS内部会保存一个状态变量state，通过CAS修改该变量的值，修改成功的线程表示获取到该锁，没有修改成功，或者发现状态state已经是加锁状态，则通过一个Waiter对象封装线程，添加到一个FIFO的双向等待队列中，并挂起等待被唤醒。AQS支持两种模式：独占和共享，独占模式中锁只会被一个线程独占，共享模式中多个线程可同时执行。像ReentrantLock,ReentrantReadWriteLock、CountDownLatch、Semaphore这些常用类都是基于AQS实现的。

ReentrantLock可重入锁

,ReentrantLock通过AQS+Volitile+CAS实现，是可以重入的锁,当一个线程获取锁时,还可以接着重复获取多次。
ReentrantLock核心流程加锁和解锁，默认的是非公平锁

• 1.非公平锁在调用 lock 后，首先就会调用 CAS 进行一次抢锁，如果这个时候恰巧锁没有被占用，那么直接就获取到锁返回了。
• 2.非公平锁在 CAS 失败后，和公平锁一样都会进入到 tryAcquire 方法，在 tryAcquire 方法中，如果发现锁这个时候被释放了（state == 0），非公平锁会直接 CAS 抢锁，但是公平锁会判断等待队列是否有线程处于等待状态，如果有则不去抢锁，乖乖排到后面。
  公平锁和非公平锁就这两点区别，如果这两次 CAS 都不成功，那么后面非公平锁和公平锁是一样的，都要进入到阻塞队列等待唤醒。
  相对来说，非公平锁会有更好的性能，因为它的吞吐量比较大。当然，非公平锁让获取锁的时间变得更加不确定，可能会导致在阻塞队列中的线程长期处于饥饿状态。

可重入锁的实现就是Volitile关键字，获取锁的时候加1，释放锁的时候-1

Condition接口及其实现原理

Condition是在java 1.5中才出现的，它用来替代传统的Object的wait()、notify()实现线程间的协作，相比使用Object的wait()、notify()，使用Condition1的await()、signal()这种方式实现线程间协作更加安全和高效。在Object的监视器模型上，一个对象拥有一个同步队列和等待队列，而并发包中的Lock（更确切地说是同步器）拥有一个同步队列和多个等待队列

• Condition是个接口，基本的方法就是await()和signal()方法；
• Condition依赖于Lock接口，生成一个Condition的基本代码是lock.newCondition()
• 调用Condition的await()和signal()方法，都必须在lock保护之内，就是说必须在lock.lock()和lock.unlock之间才可以使用

为何要使用Condition？

因为有时候获得锁的线程发现其某个条件不满足导致不能继续后面的业务逻辑，此时该线程只能先释放锁，等待条件满足。那可不可以不释放锁的等待呢？比如将await方法替换为sleep方法(这也是面试经常问的await和sleep的区别)？
显然不行，因为等待的条件显然和共享的资源是有关的，在这个例子里，take方法会等待notEmpty条件，notEmpty指的是items不为空，意味着此时items是空的，那么就只有对items执行add操作，即其它线程调用put方法才有机会达到notEmpty的条件，所以如果使用sleep(不释放锁)来等待而不是await(释放锁)来等待，则会导致notEmpty这个条件永远满足不了。
总结起来，就是获得锁的线程发现某个条件不满足而不能继续执行，而且该条件需要其它线程对共享资源进行操作才能触发，所以必须释放锁。

为什么要使用多个Condition？

图中可以看到，每个Condition会有自己单独的等待队列，调用await方法，会放到对应的等待队列中。当调用某个Condition的signalAll/signal方法，则只会唤醒对应的等待队列中的线程。
唤醒的粒度变小了，且更具针对性。如果只使用一个Condition的话，有些线程即使被唤醒并取得锁，其依然有可能并不满足条件而浪费了机会，产生时间损耗，相当于notEmpty的Condition唤醒了
notFull的队列线程。

ConditionObject是同步器AbstractQueuedSynchronizer的内部类，它实现了Condition接口，因为Condition的操作需要获取相关联的锁，所以作为同步器的内部类也较为合理。每个Condition对象都包含着一个队列（以下称为等待队列），该队列是Condition对象实现等待/通知功能的关键。

等待
调用condition的await方法，将会使当前线程进入等待队列并释放锁(先加入等待队列再释放锁)，同时线程状态转为等待状态。
从同步队列和阻塞队列的角度看，调用await方法时，相当于同步队列的首节点移到condition的等待队列中

通知
调用condition的signal方法时，将会把等待队列的首节点移到等待队列的尾部，然后唤醒该节点。
被唤醒，并不代表就会从await方法返回，也不代表该节点的线程能获取到锁，它一样需要加入到锁的竞争acquireQueued方法中去，只有成功竞争到锁，才能从await方法返回。

CountDownLatch、CyclicBarrier的区别

CountDownLatch ： 一个线程 ( 或者多个) 在等待， 等另外N个线程完成某个事情之后，这 一个线程 才能执行。(基于AQS共享锁实现)
CyclicBarrier：N个线程相互等待，任何一个线程完成之前，所有的线程都必须等待。(基于Condition实现)

因此，CountDownLatch 的重点是那个 一个线程 ，是它在等待， 而另外那N的线程在把“某个事情”做完之后，这 一个线程 可以继续执行，或者终止。

而 CyclicBarrier 来说，重点是那 N个线程 ，他们之间任何一个没有完成，所有的线程都必须等待。

差异点：
1 CountDownLatch计数器只能使用一次。CyclicBarrier则可以调用其reset()方法进行重置多次使用(在计算错误时可重置后再计算)。
2 CountDownLatch使用countDown()+await()进行处理，需要通过countDown的次数到设置的次数，其await()才不会阻塞，往往是一个主线程中使用CountDownLatch然后控制所有子线程。CyclicBarrier的同步屏障是针对对应的子线程的，但同时设置了new CyclicBarrier(N)也需要对应N次的线程(部分主子线程)来执行await()，才能继续执行await()后面的代码。

Semaphore(计数信号量)限流

限制可以访问某些资源的线程数量，
它默认构造 AQS 的 state 为 permits。当执行任务的线程数量超出 permits,那么多余的线程将会被放入阻塞队列 Park,并自旋判断 state 是否大于 0。只有当 state 大于 0 的时候，阻塞的线程才能继续执行,此时先前执行任务的线程继续执行 release 方法，release 方法使得 state 的变量会加 1，那么自旋的线程便会判断成功。 如此，每次只有最多不超过 permits 数量的线程能自旋成功，便限制了执行任务线程的数量。

Semaphore 有两种模式，公平模式和非公平模式。
公平模式： 调用 acquire 的顺序就是获取许可证的顺序，遵循 FIFO；
非公平模式： 抢占式的。

ConcurrentHashMap 1.7与1.8的区别

一、其实可以看出JDK1.8版本的ConcurrentHashMap的数据结构已经接近HashMap，相对而言，ConcurrentHashMap只是增加了同步的操作来控制并发，从JDK1.7版本的ReentrantLock+Segment+HashEntry，到JDK1.8版本中synchronized+CAS+HashEntry+红黑树,相对而言，总结如下思考

• JDK1.8的实现降低锁的粒度，JDK1.7版本锁的粒度是基于Segment的，包含多个HashEntry，而JDK1.8锁的粒度就是HashEntry（首节点）
• JDK1.8版本的数据结构变得更加简单，使得操作也更加清晰流畅，因为已经使用synchronized来进行同步，所以不需要分段锁的概念，也就不需要Segment这种数据结构了，由于粒度的降低，实现的复杂度也增加了
• JDK1.8使用红黑树来优化链表，基于长度很长的链表的遍历是一个很漫长的过程，而红黑树的遍历效率是很快的，代替一定阈值的链表，这样形成一个最佳拍档
• JDK1.8为什么使用内置锁synchronized来代替重入锁ReentrantLock，我觉得有以下几点

因为粒度降低了，在相对而言的低粒度加锁方式，synchronized并不比ReentrantLock差，在粗粒度加锁中ReentrantLock可能通
-Condition来控制各个低粒度的边界，更加的灵活，而在低粒度中，Condition的优势就没有了
-JVM的开发团队从来都没有放弃synchronized，而且基于JVM的synchronized优化空间更大，使用内嵌的关键字比使用API更加自然
在大量的数据操作下，对于JVM的内存压力，基于API的ReentrantLock会开销更多的内存，虽然不是瓶颈，但是也是一个选择依据

二、put（）
1.7：先定位Segment，再定位桶，put全程加锁，没有获取锁的线程提前找桶的位置，并最多自旋64次获取锁，超过则挂起。
1.8：由于移除了Segment，类似HashMap，可以直接定位到桶，拿到first节点后进行判断，1、为空则CAS插入；2、为-1则说明在扩容，则跟着一起扩容；3、else则加锁put（类似1.7）

三、get（）
基本类似，由于value声明为volatile，保证了修改的可见性，因此不需要加锁。

四、resize（）
1.7：跟HashMap步骤一样，只不过是搬到单线程中执行，避免了HashMap在1.7中扩容时死循环的问题，保证线程安全。
1.8：支持并发扩容，HashMap扩容在1.8中由头插改为尾插（为了避免死循环问题），ConcurrentHashmap也是，迁移也是从尾部开始，扩容前在桶的头部放置一个hash值为-1的节点，这样别的线程访问时就能判断是否该桶已经被其他线程处理过了。

五、size（）
1.7：很经典的思路：计算两次，如果不变则返回计算结果，若不一致，则锁住所有的Segment求和。
1.8：用baseCount来存储当前的节点个数，这就设计到baseCount并发环境下修改的问题（说实话我没看懂-_-!）。

常见的阻塞队列？及其使用场景

JDK7提供了7个阻塞队列。分别是
ArrayBlockingQueue ：一个由数组结构组成的有界阻塞队列。
LinkedBlockingQueue ：一个由链表结构组成的有界阻塞队列。
PriorityBlockingQueue ：一个支持优先级排序的无界阻塞队列。
DelayQueue：一个使用优先级队列实现的无界阻塞队列。
SynchronousQueue：一个不存储元素的阻塞队列。
LinkedTransferQueue：一个由链表结构组成的无界阻塞队列。
LinkedBlockingDeque：一个由链表结构组成的双向阻塞队列。

,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.线程池的数量如何确定？
在遇到这类问题时，先冷静下来分析

1. 需要分析线程池执行的任务的特性： CPU 密集型还是 IO 密集型
2. 每个任务执行的平均时长大概是多少，这个任务的执行时长可能还跟任务处理逻辑是否涉及到网络传输以及底层系统资源依赖有关系
   如果是 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
  
  而volatile关键字避免了指令重排

**懒汉式单例类+双重检查锁+Volatile **

//懒汉式单例类.在第一次调用的时候实例化自己 
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; 
    }
}

静态内部类为什么是线程安全的？
静态内部类的优点是：外部类加载时并不需要立即加载内部类，内部类不被加载则不去初始化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源码解析，多线程扩容

ConcurrentHashMap的参数概念