Dirty data and memory leakage of ThreadLocal

background ：

Spring-Boot 2.0.8.RELEASE

Spring-Cloud 2.0.4.RELEASE

tomcat 8.5.37

JDK 1.8

Project use ThreadLocal To pass parameters , such as ： Request data 、 Set a variable

ThreadLocalParamsUtil

public class ThreadLocalParamsUtil {
	private static final Log log = LogFactory.getLog(ThreadLocalParamsUtil.class);

	private static final ThreadLocal<Map<String,Object>> threadLocalMap=new ThreadLocal<>();

    public static <T>T get(String key){
        // ...
    }
    
    public static void set(String key, Object value) {

    }

    public static void clean(String key) {
    
    }
    
    public static void cleanAll() {

    }

      When the interface returns normally , call ThreadLocalParamsUtil.cleanAll() Cleared all shared variables .

      When an exception occurs in the interface processing process , and No, call ThreadLocalParamsUtil.cleanAll() Clear all shared variables .

problem ：

      In the process of interface processing ,ThreadLocalParamsUtil.get("myKey"), occasionally The value obtained is Dirty data , Cause program processing exception .

Simulation scenario ：（ The actual occurrence scenario is actually quite complex , It's simplified here ）

      When an exception occurs in the interface processing , Because shared variables are not cleared , The shared variables in this thread always exist , Memory leaks and dirty data have occurred .

      When subsequent requests use This thread with exceptions When ,ThreadLocalParamsUtil.get("myKey") You will get the value set when the thread last requested , That's dirty data .

      Why not get dirty data every time ？ because tomcat When processing requests, you use Thread pool , The default number of core threads is 10, Then it may pass 10 After requests , You will get dirty data once , Cause program processing exception .

Use matters needing attention ：

    ThreadLocal Shared variables within threads , Convenience is convenience , But pay attention every time set after , You don't need to use this key When , must do remove Clean up , Otherwise, it will not only cause memory leakage , It may also lead to dirty data , So there are some strange mistakes .

notes ：springboot built-in tomcat Thread pool of ：（ Reference resources ：https://blog.csdn.net/qq_31086797/article/details/110523079）

Parameters
Number of core threads in thread pool
server.tomcat.min-spare-threads： The parameter is tomcat Number and size of core threads processing business , The default value is 10

Maximum number of threads in the thread pool
server.tomcat.max-threads： The parameter is tomcat The maximum number and size of threads processing business , The default value is 200, When you have a value for concurrency, you can increase this parameter

Maximum connections requested
server.tomcat.max-connections： This parameter is the maximum number of connections requested , The default value is 10000, Note that this parameter is not set on the thread pool , But in tomcat Of Acceptor class （ Thread class that deals specifically with connections ） Controlled