ThreadLocal导致内存泄漏排查小记
共 4387字,需浏览 9分钟
·
2021-04-02 13:34
背景描述
公司sso域名变动,所有涉及的产品都要修改相关的配置。配置修改好之后,运行期间发现业务系统不稳定,出现了很多json解析异常。但是随着sso那边问题得到修改,我们自己的产品也逐渐稳定起来,但查看日志发现多条内存泄露的日志,于是本着学习的心态,对具体的原因进行了粗略的分析,最终得出的结论是异常导致threadLocal.remove()方法没有执行,最后内存泄漏了,以下是本人定位问题的过程。
报错日志
6:21:26.656 严重 [Thread-219] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks
The web application [ttt] created a ThreadLocal withkey of type [java.lang.ThreadLocal]
(value [java.lang.ThreadLocal@1201c9a0]) and a value of type
[tt.zzz.loghelper.model.ActionLog] (value [])
but failed to remove it when the web application was stopped.
Threads are going to be renewed over time to try and avoid a probable memory leak.
翻译和分析
这个threadlocal移除不了,直到项目死了都还没移除掉。具体的异常发起者是这个catalina的loader,具体的方法就是checkThreadLocalMapForLeaks (检测线程的threadlocal是否有泄露),大概说一下就是就是说检测这个线程的threadlocal,然后发现线程中的threadlocal有值,然后就抛出了内存泄露这个异常。大概猜测一下应该是是tomcat在处理请求的时候,因为要从线程池中获取线程,然后让这个线程去跑请求,但是通过这个检测方法检测一下,发现当前获取的这个线程的threadLocal没有释放掉。我们当时说threadlocal是一个弱引用,我们说弱引用只会在内存不够的时候,jvm才会回收它。而我们的thredlocal保存的map映射关系就是保存在这里的弱引用中,意思是如果我们不显式的通过remove()方法去移除弱引用中的值,那么就会存在内存泄露的问题。所以这个报错日志的核心就是没有走threadlocal.remove()方法。
定位问题代码
日志收集上,我们采用了之前老员工写的日志切面,大概得代码如下:
public class WebLogAspect {
private static final Logger log = LoggerFactory.getLogger(WebLogAspect.class);
private ThreadLocalthreadLocal = new ThreadLocal();
private LogHelperProperties logHelperProperties;
private LogService logService;
public WebLogAspect() {
}
"@annotation(ttt .tt.loghelper.aspect.WebLog)") (
public void webLog() {
}
//执行之前
"webLog()") (
public void doBefore(JoinPoint joinPoint) {
ServletRequestAttributes attributes = (ServletRequestAttributes)RequestContextHolder.getRequestAttributes();
if (attributes != null) {
HttpServletRequest request = attributes.getRequest();
ActionLog actionLog = new ActionLog();
//设置threadLocal变量
this.threadLocal.set(actionLog);
}
}
//这里回环日志
"webLog()") (
public Object doAround(ProceedingJoinPoint proceedingJoinPoint) throws Throwable {
//这里继续执行我们自己的函数
Object result = proceedingJoinPoint.proceed();
ActionLog actionLog = (ActionLog)this.threadLocal.get();
//这里对threadLocal进行remove操作,这里应该没有执行?
this.threadLocal.remove();
//写日志
this.logService.writeActionLog(actionLog);
return result;
}
}
通过查看代码我们知道这块的 this.threadLocal.remove();应该是没有执行的,那么没有执行的原因就是异常了。为此作者编写了如下的代码测试了一下:
public class TestThread extends Thread{
private static ThreadLocalmyThreadThreadLocal=new ThreadLocal<>();
public static void main(String[] args) {
MyThread thread=new MyThread();
thread.setName("tianjl");
//设置threadLocal变量
myThreadThreadLocal.set(thread);
try{
//里边抛异常
doSomeThing();
//下边的代码是不执行的,也就是this.threadLocal.remove();不执行
System.out.println(myThreadThreadLocal.get().toString());
myThreadThreadLocal.remove();
}catch (Exception e){
e.printStackTrace();
}
//这里可以获取到本该remove的threadlocal的值
System.out.println(myThreadThreadLocal.get().toString());
}
private static void doSomeThing() throws Exception {
throw new Exception("测试异常");
}
}
执行的效果如下
结论和解决方法
根据SSO的变动我们知道,sso异常导致了线程直接跳出方法,使得函数没有执行threadlocal.remove()方法。造成了threadlocal中的值没有清理,最终导致tomcat在检测线程的threadlocal的时候发现有内存泄露,最后直接抛异常了。具体的解决方法就是将threadlocal.remove()放到finally中去。
public Object doAround(ProceedingJoinPoint proceedingJoinPoint) throws Throwable {
try{
//这里继续执行我们自己的函数
Object result = proceedingJoinPoint.proceed();
ActionLog actionLog = (ActionLog)this.threadLocal.get();
//写日志
this.logService.writeActionLog(actionLog);
return result;
}finally{
//这里对threadLocal进行remove操作,这里应该没有执行?
this.threadLocal.remove();
}
}