一、多线程

1. 无返回值

①. 实现runnable接口

• run方法不会抛异常
• 需要Thread的start方法启动多线程

②. 继承Thread类

• java只能单继承，所以扩展收到限制

2. 有返回值（实现Callable接口）

①. future拿 到返回值

• 拿返回值
• 判断任务是否执行完
• 中断任务
• 向线程池summit的多个任务，只有全部执行完，future才可以get到值

②. call方法会抛异常

③. 需要Thread的start方法启动多线程

3. 解决future的get方法阻塞问题completionService

①. take方法也是阻塞方法，只是会拿其中一个完成的future

②. poll方法和take类似，只是poll方法不会阻塞，没有完成的任务直接返回null,可以加等待的时间

4. ThreadLocal

①. 线程间的数据隔离

②. 解决多线程安全问题

• set(往里面放数据
• get(从里面取当前线程的数据
• 使用完get和set后要用remove去除内部map的key与value的引用关系，因为key是弱引用，下次gc的时候被回收，导致value会被线程长期持有，造成内存泄露

③. 优雅做法:帮ThreadLocal包装到单例中

二、并发包

• BlockingQueue
• ConcurrentHashMap
• ReentrantLock
• LockSupport
• CyclicBarrier
• CountDownL atch
• ReadWriteLock
• Semaphore
• Condition

三、相关问题理解

1. 对volatile的理解

①. 虚拟机提供的轻量的同步机制

• 保证可见性：前后加了内存屏障
• 不保证原子性
• 禁止指令重排：当程序执行到volatile变量的读操作或者写操作时，在其前面的操作的更改肯定全部已经进行，且结果已经对后面的操作可见;在其后面的操作肯定还没有进行

②. 在JMM的理解

• 可见性：主内存，线程工作内存
• 原子性
• 有序性质：指令重排

③. 哪些地方用过volatile

• 单例模式的double check (禁止 了指令重排)
  • 在真正的new操作对象的时候，new命令其实包含了，开辟内存，初始化内存等操作:
  • 多线程情况下，一个线程在new的时候，内存还没有被初始化完全，另一个线程进来后发现对象引用已经不是null了，就会返回一个未初始化完全的对象，从而造成出错
• 代理模式

2. CAS的理解（比较交换）

①. 工作内存与主存数据比较一样的时候修改，不一样的时候重复读取主存，跟新工作内存数据

②. CAS底层，unsafe的理解：native方法，unsafe类

③. CAS缺点：

A. 循环时间长，CPU开销大

B.只能保证一个共享变量的原子性:不能保证代码块的原子性

C. 有ABA问题：

• 原因：一个线程短时间内把变量由A改成B，再由B改成A
• 解决:加入时间戳版本，原子引用
• AtomicStampedReference

3. Arayit是线程不安全的，解决线程不安全的方言

• 加锁
• 使用vector线程安全的数组
• 使用Collections内部方法转为线程安全的List

4. 各种锁的理解

①. 公平锁/非公平锁

• 是什么:公平锁只等待锁的线程按先来先得顺序得到锁
• 两者区别:公平锁按FIFO的等待队列等待锁， 锁操作耗时
• ReentrantLock默认是非公平锁，synchronize是非公平锁

②. 对象锁

• Synchronize.每 个对象的头部markword字段有标志标志，monitorenter 和monitorexit 指令来实现同步的，monitor管程 来控制
• 头部mark word字段，有锁状态，是否偏向锁，锁标志
• JVM级的不需要业务代码控制

③. 偏向锁

• 偏向锁的核心思想是，如果一个线程获得 了锁，那么锁就进入偏向模式，此时Mark Word的结构也变为偏向锁结构，当这个线程再次请求锁时，无需再做任何同步操作，即获取锁的过程，这样就省去了大量有关锁申请的操作

④. 可重入锁

• 是什么:同一个线程外层函数获取锁后，内存递归函数仍然能获得锁
• ReentrantLock和Snychronize是典型的可重入锁
• 底层实现原理，ReentrantLock是AQS同步队列， Snychronize是锁住的对象头部字段记录的标志，在monitor中 会做计数

⑤. 自旋锁

• SpinLock,短时间的自旋，不会释放CPU

⑥. 独占锁(写)/共享锁(读)

• ReentrantReadWriteLock

⑦. 读写锁

• 写的时候排他，读的时候共享排他写锁

⑧. 锁优化

• 偏向税→轻量级锁→自旋锁→重量级锁

5. CountDownLatch/CyclicBarrier/Semaphore

①. CountDownLatch

• 让一些线程阻塞，知道一些线程完成操作
• 一些线程执行await(阻塞，一些线程完成操作后执行CountDownQ减数
• 案例:等待人到齐，才开会

②. CyclicBarrier

• 一些线程阻塞在一个点， 然后同时进行
• await(方法阻塞
• 案例:跑步比赛到齐开始

③. Semaphore

• 用于并大资源数量的控制，同-时间只能有固定数的线程进入临界区
• 案例:抢车位

6. 阻塞队列

①. 是什么

• 阻塞队列空的时候，从队列获取数据的线程会被阻塞
• 阻塞队列满的时候，往队列放数据的线程会被阻塞

②. 好处

• 不需要关心什么时候阻塞线程，什么时候唤醒，阻塞队列帮处理了

③. Blockqueue核心方法处理出错

• 抛异常
• 返回特殊值
• 一直阻塞
• 超时退出

④. 架构种类

• ArrayBlockingQueue基于数组的有界
• LinkedBlockingDeque基于链表的有界，默认界值很大
• SynchronousQueue同步队列，不存数据，生产一个消费一 个
• PriorityBlockingQueue有优先级的无界阻塞队列
• delayQueue延迟无界阻塞队列
• LinkedTransferQueue链表结构的无界阻塞队列
• LinkedBlockingDeque链表结构阻塞双端队列

⑤. 用在哪里

• 生产者消费者模式
• 线程池
• 消息中间件

7. Java线程池，ThreadPoolExecutor的理解 田

①. 线程池优势

• 充分利用CPU
• 减少频繁创建线程的性能消耗

②. 线程池的使用

• 自定义线程池，继承ThreadPoolExecutor
• 线程池函数
  • Executors.newCachedThreadPool
  • Executors.newSingle ThreadPool
  • Executors.newFixedThreadPool
  • Executors.newScheduleThreadPool

③. 线程池的重要参数

• corePoolSize线程池的常驻核心线程数
• maximumpoolSize线程池能够容纳的最多线程数
• keepAliveTime多余核心线程数的空闲线程的最多存活时间
• unit keepAlive Time的单位
• workqueue任务队列，提交到线程池还未处理的任务
• threadFactory线程池中线程的工厂。用于创建线程，
• handler拒绝策略，任务丢列满，线程数达到最大时，做的处理

④. 线程池的工作原理

a. 创建线程池后等待提交任务

b. 调用execute添加任务，线程池做的判断：

• 如果线程数量小于核心线程数，就马上创建线程处理任务
• 如果正在运行的线程数大于核心线程数，就将任务放入任务队列
• 如果任务队列满了，且正在运行的线程数小于最大线程数，就创建非核心线程处理任务
• 如果队列满了，且线程数达到最大线程数，线程池使用饱和拒绝策略处理任务

c. 当一个线程任务处理完，会从任务队列中取下一个任务执行

d. 当一个线程空闲时间超过keepAliveTime时候，线程池处理（如果当前线程数量大于核心线程数，那么这个线程就会被销毁）

8. 线程池参数的合理配置

①. 线程池拒绝策略

• AbortPoliy直接抛出异ReiectedException.阻止系统运行
• CallerRunPoliy由提交任务的业务线程处理_
• DisadndeltPole她弃队列中等待最久的任务，然后把最新的任务加入人任务队列
• DicardPolil 直接丢弃任务，不予处理。也不抛出异常，允许任务丢弃

②. 创建线程池的方法

a. 使用自定义线程池

b. executors线程池问题：

• 默认使用链表有界阻塞队列，界很大，导致内存溢出
• 缓存调度线程池会创建大量线程导致资源占用大

③. 如何合理配置线程池数量

• CPU密集型操作: cpu核心数+1
• IO密集型操作: 2xcpu核心数

9. 死锁定位分析

①. 产生原因：

• 系统资源不足
• 资源分配不当
• 线程执行顺序不合适
• 线程互斥，资源持有等待，不可剥夺

②. 解决：jps定位到进程id, jstack定位到栈代码

# 链接 Java程序员福利"常用资料分享"