本文回答以下问题，文内可能有遗漏、错误或表达不够清晰的地方。
- ThreadLocal
① 了解ThreadLocal使用场景和内部实现
② 使用ThreadLocal时要注意什么？比如说内存泄漏? - ThreadPoolExecutor
① 了解线程池的工作原理以及几个重要参数的设置
② 往线程池里提交一个任务会发生什么？
③ 线程池的非核心线程什么时候会被释放？
④ 如何排查死锁？
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
如果是因为同一个线程池里的两个线程争夺资源发生“死锁”，则需修改业务逻辑，改为不同的线程池来处理或者使用单线程处理。
- 当线程池里的一个线程出现异常时又会发生什么：
如果是以execute方式提交线程，异常输出在控制台；如果是以submit方式提交线程，在控制台没有直接输出，必须调用Future.get()方法时，才可以捕获到异常；
一个线程出现了异常，不会影响线程池里面其他线程的正常执行，这个异常线程不会被回收，而是会被线程池移除掉，同时创建一个新的线程放到线程池中。
参考文章
https://blog.csdn.net/hjfalz/article/details/117914630
https://www.shuzhiduo.com/A/MAzAPaApd9/
https://pdai.tech/md/java/thread/java-thread-x-juc-executor-ThreadPoolExecutor.html
