本文回答以下问题,文内可能有遗漏、错误或表达不够清晰的地方。
- 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
网友评论