ThreadLocal

① 了解ThreadLocal使用场景和内部实现
使用场景：全局参数传递、解决线程安全问题
使用案例: PageHelper、MDC类、@Transactional的数据库连接

ThreadLocal对象可以提供线程局部变量，每个线程Thread拥有一份自己的副本变量，多个线程间互不干扰。一个线程可以创建多个ThreadLocal对象，将其存到当前线程的ThreadLocalMap里。ThreadLocalMap底层数据结构是一个Entry数组，它的Entry是继承WeakReference的，key是ThreadLocal对象（弱引用）

● 为什么ThreadLocalMap中把ThreadLocal对象存储为Key时使用的是弱引用

一般来说使用ThreadLocal时会有两个引用指向ThreadLocal对象，一个是创建ThreadLocal对象时的显式的引用，还有一个就是ThreadLocalMap对ThreadLocal对象的弱引用，当我们不再使用ThreadLocal时，显式引用不再指向ThreadLocal对象。这时只有ThreadLocalMap对ThreadLocal对象的弱引用存在。

● 假设ThreadLocalMap对ThreadLocal的引用是强引用
由于ThreadLocalMap是属于线程的，而我们创建多线程时一般是使用线程池进行创建，线程池中的部分线程在任务结束后是不会关闭的，那么这部分线程中的ThreadLocalMap将会一直持有对ThreadLocal对象的强引用，导致ThreadLocal对象无法被垃圾回收，从而造成内存泄漏。

● 设置成弱引用之后

下一次垃圾回收时，无论内存空间是否足够，只被弱引用指向的对象都会被直接回收。所以将ThreadLocalMap对ThreadLocal对象的引用设置成弱引用，就能避免ThreadLocal对象无法回收导致内存泄漏的问题。但是ThreadLocalMap对value的引用是强引用，所以value部分还是有内存泄漏的可能。所以ThreadLocal类定义了expungeStaleEntry方法用于清理key为null的value。expungeStaleEntry在remove中方法中调用。

② 使用ThreadLocal时要注意什么？比如说内存泄漏?

ThreadLocalMap的生命周期跟Thread一样长，如果没有手动删除对应key会导致内存泄漏。

可能发送内存泄漏的地方:
1、大量地(静态)初始化ThreadLocal实例，初始化之后不再调用get()、set()、remove()方法。
2、初始化了大量的ThreadLocal，这些ThreadLocal中存放了容量大的Value，并且使用了这些ThreadLocal实例的线程一直处于活跃的状态。

最佳实践：
每次使用完ThreadLocal实例，都调用它的remove()方法，清除Entry中的数据
用remove()方法最佳时机是线程运行结束之前的finally代码块中调用
同时尽量避免使用ThreadLocal存储大对象

ThreadPoolExecutor

① 了解线程池的工作原理以及几个重要参数的设置

// 以ThreadPoolExecutor参数最全的构造器为例
    public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) {
    }

② 往线程池里提交一个任务会发生什么？

③ 线程池的非核心线程什么时候会被释放？

阻塞队列里没有任务时，非核心线程要在等到keepAliveTime时间后才会释放

④ 如何排查死锁？

首先清楚线程状态，一个Thread对象可以有多个状态，在java.lang.Thread.State中，总共定义六种状态：

1、NEW
 
线程刚刚被创建，也就是已经new过了，但是还没有调用start()方法，jstack命令不会列出处于此状态的线程信息
 
2、RUNNABLE #java.lang.Thread.State: RUNNABLE
 
RUNNABLE这个名字很具有欺骗性，很容易让人误以为处于这个状态的线程正在运行。事实上，这个状态只是表示，线程是可运行的。我们已经无数次提到过，一个单核CPU在同一时刻，只能运行一个线程。
 
3、BLOCKED # java.lang.Thread.State: BLOCKED (on object monitor)
 
线程处于阻塞状态，正在等待一个monitor lock。通常情况下，是因为本线程与其他线程公用了一个锁。其他在线程正在使用这个锁进入某个synchronized同步方法块或者方法，而本线程进入这个同步代码块也需要这个锁，最终导致本线程处于阻塞状态。
 
4、WAITING
 
等待状态，调用以下方法可能会导致一个线程处于等待状态：
 
Object.wait 不指定超时时间 # java.lang.Thread.State: WAITING (on object monitor)
 
Thread.join with no timeout
 
LockSupport.park #java.lang.Thread.State: WAITING (parking)
 
例如：对于wait()方法，一个线程处于等待状态，通常是在等待其他线程完成某个操作。本线程调用某个对象的wait()方法，其他线程处于完成之后，调用同一个对象的notify或者notifyAll()方法。Object.wait()方法只能够在同步代码块中调用。调用了wait()方法后，会释放锁。
 
5、TIMED_WAITING
 
线程等待指定的时间，对于以下方法的调用，可能会导致线程处于这个状态：
 
Thread.sleep #java.lang.Thread.State: TIMED_WAITING (sleeping)
 
Object.wait 指定超时时间 #java.lang.Thread.State: TIMED_WAITING (on object monitor)
 
Thread.join with timeout
 
LockSupport.parkNanos #java.lang.Thread.State: TIMED_WAITING (parking)
 
LockSupport.parkUntil #java.lang.Thread.State: TIMED_WAITING (parking)
 
6、TERMINATED
 
线程终止。

其次，使用 jstack 命令可以查看线程的堆栈信息，定位到简单的死锁，通过 jstack 也能定位CPU高的问题，具体步骤如下：

查看当前占用cpu最高的进程pid（COMMAND列）；

top

获取当前进程中所有线程占CPU的情况（也可top -p<pid>再按 H）；

top -Hp <pid>

将占用最高的tid转换为16进制

printf "%x\n" <tid>;

查看占用最高的线程的堆栈状态。通过这个流程可以直接定位到哪个线程正在执行占用了大量的cpu。其中A10 就是过滤到关键词之后(A:after)10行信息。

jstack <pid> | grep -A10 <16进制tid>

关注堆栈信息里的：

死锁，Deadlock（重点关注）
执行中，Runnable
等待资源，Waiting on condition（重点关注）
等待获取监视器，Waiting on monitor entry（重点关注）
对象等待中，Object.wait() 或 TIMED_WAITING
暂停，Suspended
阻塞，Blocked（重点关注）
停止，Parked

如果是因为同一个线程池里的两个线程争夺资源发生“死锁”，则需修改业务逻辑，改为不同的线程池来处理或者使用单线程处理。