面试总结之并发篇(下)
说说自己是怎么使用synchronized关键字？
修饰实例方法：作用于当前对象实例加锁，进入同步代码前要获得当前对象实例的锁
修饰静态方法：也就是给当前类加锁，会作用于类的所有对象实例，因为静态成员不属于任何一个实例对象，所以如果一个线程A调用一个实例对象的非静态synchronized方法，而线程B需要调用这个实例对象所属类的静态synchronized方法是允许的，不会发生互斥现象，因为访问静态synchronized方法占用的锁是当前类的锁，而访问非静态synchronized方法占用的锁是当前实例对象锁。
修饰代码块：指定加锁对象，对指定对象加锁，进入同步代码块之前要获得给定对象的锁。
总结：synchronized关键字加到static静态方法和synchronized(class)代码块上都是给class类上锁。synchronized关键字加到实例方法上是给对象实例上锁。尽量不要使用synchronized(String a),因为JVM中，字符串常量池具有缓存功能！
常用的线程池有哪些？
- SingleThreadExecutor:创建一个单线程的线程池，此线程池保证所有任务的执行顺序按照任务的提交顺序执行
- FixedThreadPool:创建固定大小的线程池，每次提交一个任务就创建一个线程，直到线程达到线程池的最大大小
- CachedThreadPool:创建一个可缓存的线程池，此线程池不会对线程池大小做限制，线程池大小完全依赖于操作系统(或者说JVM)能够创建的最大线程大小。
- ScheduledThreadPool:创建一个大小无限的线程池，此线程池支持定时以及周期性执行任务的需求。
锁的优化机制了解吗？
从jdk1.6版本之后，synchronized本身也在不断优化锁的机制，有些情况下它并不会是一个很重量级的锁了。优化机制包括自适应锁、自旋锁、锁消除、锁粗化、轻量级锁和偏向锁。
锁的状态由低到高依次为无锁->偏向锁->轻量级锁->重量级锁，升级的过程就是由低到高，降级在一定条件下也是有可能发生的。
自旋锁：由于大部分时候，锁被占用的时间很短，共享变量的锁定时间也很短，所以没有必要挂起线程，用户态和内核态的来回上下文切换严重影响性能。自旋的概念就是让线程执行一个忙循环，可以理解为就是啥也不干，防止从用户态转入内核态，自旋锁可以通过设置-XX：+UseSpining来开启，自旋的默认次数是10次，可以使用-XX：PreBlockSpin设置。
自适应锁：自适应锁也是自旋锁，但是自旋的时间不是固定的，而是由前一次在同一个锁上的自旋时间和锁的持有者状态来决定。
锁消除：锁消除指的是JVM检测到一些同步的代码块，完全不存在数据竞争的场景，也就是不需要加锁，就会进行锁消除。
锁粗化：锁粗化指的是有很多操作都是对同一个对象进行加锁，就会把锁的同步范围扩展到整个操作序列之外。
偏向锁：当线程访问同步块获取锁时，会在对象头和栈帧中的锁记录里存储偏向锁的线程ID，之后这个线程再次进入同步块时都不需要CAS来加锁和解锁了，偏向锁会永远偏向第一个获得锁的线程，如果后续没有其它线程获得过这个锁，持有锁的线程就永远不需要进行同步，反之，当有其他线程竞争偏向锁时，持有偏向锁的线程就会释放偏向锁，可以通过设置-XX：+UseBiasedLocking开启偏向锁。
轻量级锁：JVM的对象的对象头中包含有一些锁的标志位，代码进入同步块的时候，JVM将会使用CAS方式来尝试获取锁，如果更新成功则会把对象头中的状态位标记为轻量级锁，如果更新失败，当前线程就尝试自旋来获取锁。
整个锁升级的过程非常复杂，我尽力去除一些无用的环节。简单来描述整个升级的机制。
简单点说，偏向锁就是通过对象头的偏向线程ID来对比，甚至都不需要CAS了，而轻量级锁主要就是通过CAS修改对象头锁记录和自旋来实现，重量级锁则是除了拥有锁的线程其他全部阻塞。
线程池核心线程数怎么设置呢？
分为cpu密集型和IO密集型
cpu密集型：这种任务消耗的主要是cpu资源，可以将线程数设置为N(cpu核心数)+1，比cpu核心数多出来的一个线程是为了防止线程偶发的缺页中断，或者其他原因导致的任务暂停而带来的影响。一旦任务暂停，cpu就会处于空闲状态，而在这种情况下多出来的一个线程就可以充分利用cpu的空闲时间。
IO密集型：这种任务应用起来，系统会用大部分的时间来处理IO交互，而线程在处理IO的时间段内不会占用cpu来处理，这时就可以将cpu交出给其他线程使用。因此在IO密集型任务的应用中，我们可以多配置一些线程，具体的计算方法是：核心线程数=cpu核心数量*2.
java线程池中队列常用类型有哪些？
- ArrayBlockingQueue是一个基于数组结构的有界阻塞队列，此队列按FIFO(先进先出)原则对元素进行排序。
- LinkedBlockingQueue是一个基于链表结构的阻塞队列，此队列按FIFO(先进先出)排序元素，吞吐量通常要高于ArrayBlockingQueue.
- SynchronousQueue是一个不存储元素的阻塞队列。
- PrioityBlockingQueue是一个具有优先级的无限阻塞队列。PriorityBlockingQueue也是基于最小二叉堆实现。
- DelayQueue:
- 只有当其指定的延迟时间到了，才能够从队列中获取到该元素。
- DelayQueue是一个没有大小限制的队列
- 因此往队列中插入数据的操作(生产者)永远不会被阻塞，而只有获取数据的操作(消费者才会被阻塞。
说一下线程之间是如何通信的？
线程之间的通信有两种方式：共享内存和消息传递。
共享内存：在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间通过写-读内存中的公共状态来隐式进行通信。典型的共享内存通信方式，就是通过共享对象进行通信。线程A和线程B之间如果要通信的话，那么久必须经历下面两个步骤：
- 线程A把本地内存A更新过得把共享变量刷新到主内存中去。
- 线程B到主内存中去读取线程A之前更新过的共享变量。
消息传递：在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的发送消息来显式进行通信，在java中典型的消息传递方式就是：wait()和notify(),或者BlockingQueue.
CAS有什么缺点吗？
CAS的缺点主要有3点：
ABA问题：ABA问题指的是在CAS更新的过程中，当读取到的值是A，然后准备赋值的时候仍然是A，但是实际上有可能A的值被改成了B，然后又被改回了A，这个CAS更新的漏洞就叫做ABA。只是ABA的问题大部分场景下都不影响并发的最终效果。
java中有AtomicStampedReference来解决这个问题，他加入了预期标志和更新后标志两个字段，更新时不光检查值，还要检查当前的标志是否等于预期标志，全部相等的话才会更新。
循环时间长开销大：自旋CAS的方式如果长时间不成功，会给CPU带来很大的开销。
只能保证一个共享变量的原子操作：只对一个共享变量操作可以保证原子性，但是多个则不行，多个可以通过AtomicReference来处理或者使用锁synchronized实现。
