背景描述

      公司sso域名变动，所有涉及的产品都要修改相关的配置。配置修改好之后，运行期间发现业务系统不稳定，出现了很多json解析异常。但是随着sso那边问题得到修改，我们自己的产品也逐渐稳定起来，但查看日志发现多条内存泄露的日志，于是本着学习的心态，对具体的原因进行了粗略的分析，最终得出的结论是异常导致threadLocal.remove()方法没有执行，最后内存泄漏了，以下是本人定位问题的过程。

报错日志

6:21:26.656 严重 [Thread-219] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaksThe 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()方法。

定位问题代码

       日志收集上，我们采用了之前老员工写的日志切面，大概得代码如下：

@Aspectpublic class WebLogAspect {    private static final Logger log = LoggerFactory.getLogger(WebLogAspect.class);    private ThreadLocalthreadLocal = new ThreadLocal();    @Autowired    private LogHelperProperties logHelperProperties;    @Autowired    private LogService logService;        public WebLogAspect() {    }    @Pointcut("@annotation(ttt .tt.loghelper.aspect.WebLog)")    public void webLog() {    }//执行之前    @Before("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);        }    }//这里回环日志    @Around("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中去。  

@Around("webLog()")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();      }}