当前位置：网站首页>Be careful of this hole in transmittable thread local

Be careful of this hole in transmittable thread local

2022-06-30 08:20:00 【InfoQ】

Hello , I'm looking at the mountains .

transmittable-thread-local It is a thread pool reuse scenario that is open source by Alibaba , A solution to the problem of context passing data during asynchronous execution . From the official documents

https://github.com/alibaba/transmittable-thread-local

For more information .

This article mainly changes transmittable-thread-local An exception occurred when using the method .

Abnormal scene

Before looking at the abnormality , First, let's briefly describe the general situation of the project .

The project is Java Stack , Used SpringBoot+MyBatis Frame structure , The build tool is Maven. Because the project uses a lot of multi-threaded logic , So we introduced transmittable-thread-local, Solve the problem of context passing data . Later, the project was upgraded , Access to the company's monitoring system , Startup parameters are added during startup

-javaagent:/path/to/transmittable-thread-local-2.12.1.jar

, Solve the problem of multi-threaded context value passing by means of zero intrusion .

therefore , Some logic went wrong .

Let's look at the exception stack （ The log has been deleted , Hide project information ）：

org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type 'org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor' available: expected single matching bean but found 3: executor1,executor2,executor3
 at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveNamedBean(DefaultListableBeanFactory.java:1200)
 at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveBean(DefaultListableBeanFactory.java:420)
 at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:349)
 at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:342)
 at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1127)
 ……
 at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
 at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:771)
 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
 at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:749)
 at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:88)
 ……

The exception log is clear , It is through

AbstractApplicationContext.getBean

obtain Bean When , Because there are multiple of the same type

ThreadPoolTaskExecutor

,Spring The container doesn't know which to return Bean, Just throw it out

NoUniqueBeanDefinitionException

abnormal .

Troubleshoot problems

Let's look at the calling code ：

public static void doSth(Object subtag, Object extra, long time) {
 ApplicationContextContainer.getBean(ThreadPoolTaskExecutor.class)
 .execute(() -> {
 //  Some business code 
 });
}

@Component
public class ApplicationContextContainer implements ApplicationContextAware {
 private static ApplicationContext applicationContext;

 public static <T> T getBean(Class<T> clazz) {
 return applicationContext.getBean(clazz);
 }

 @Override
 public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
 ApplicationContextContainer.applicationContext = applicationContext;
 }
}

You can see it ,

applicationContext.getBean

Only the class type , There is no indication of Bean Name . It is assumed that there are multiple... Defined in the project

ThreadPoolTaskExecutor

Type of Bean, The names are executor1、executor2、executor3（ The name has been changed , When we write code, we try to use the naming method of seeing the name and knowing the meaning ）.

@Configuration
public class ExecutorConfig {
 @Bean(value = &quot;executor1&quot;)
 public Executor executor1() {
 ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
 //  Some initialization methods 
 taskExecutor.initialize();
 return taskExecutor;
 }

 @Bean(value = &quot;executor2&quot;)
 public Executor executor2() {
 ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
 //  Some initialization methods 
 taskExecutor.initialize();
 return TtlExecutors.getTtlExecutor(taskExecutor);
 }

 @Bean(value = &quot;executor3&quot;)
 public Executor executor3() {
 ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
 //  Some initialization methods 
 taskExecutor.initialize();
 return TtlExecutors.getTtlExecutor(taskExecutor);
 }
}

From the above code, you can find , It does executor1、executor2、executor3 Three

Executor

,executor1 yes

ThreadPoolTaskExecutor

Type of ,executor2 and executor3 Is a

TtlExecutors.getTtlExecutor

Packaged

ThreadPoolTaskExecutor

Let's see

TtlExecutors.getTtlExecutor

Method ：

public static Executor getTtlExecutor(@Nullable Executor executor) {
 if (TtlAgent.isTtlAgentLoaded() || null == executor || executor instanceof TtlEnhanced) {
 return executor;
 }
 return new ExecutorTtlWrapper(executor, true);
}

Infer from mistakes , after

TtlExecutors.getTtlExecutor

After that, I returned

ThreadPoolTaskExecutor

type . That is, the code above has gone

if

sentence , The input parameters are returned directly .

however , Here are two of the top ten unsolved mysteries of development ：

The code has not been changed , Well done before , Why did you make a mistake ;

This place is easy to use , Why is an error reported on the server .

Location problem

First , We need to know , The end of code is not metaphysics . The computers we use today can't lie , Just report a mistake , There must be a problem .

Let's take a closer look

TtlExecutors.getTtlExecutor

Methods

if

Judge ：

TtlAgent.isTtlAgentLoaded()： This is judgment ttlAgentLoaded identification , This will be discussed later ;

null == executor： Input parameter is null, Obviously not in line with ;

executor instanceof TtlEnhanced： The input parameters are
TtlEnhanced
type , The input is
ThreadPoolTaskExecutor
type , Do not conform to the .

therefore , Focus on ttlAgentLoaded identification ：

public static boolean isTtlAgentLoaded() {
 return ttlAgentLoaded;
}

Find the modification from the global view

ttlAgentLoaded

The place is ：

public final class TtlAgent {
 public static void premain(final String agentArgs, @NonNull final Instrumentation inst) {
 kvs = splitCommaColonStringToKV(agentArgs);

 Logger.setLoggerImplType(getLogImplTypeFromAgentArgs(kvs));
 final Logger logger = Logger.getLogger(TtlAgent.class);

 try {
 logger.info(&quot;[TtlAgent.premain] begin, agentArgs: &quot; + agentArgs + &quot;, Instrumentation: &quot; + inst);
 final boolean disableInheritableForThreadPool = isDisableInheritableForThreadPool();

 //  Omit irrelevant code 

 ttlAgentLoaded = true;
 } catch (Exception e) {
 String msg = &quot;Fail to load TtlAgent , cause: &quot; + e.toString();
 logger.log(Level.SEVERE, msg, e);
 throw new IllegalStateException(msg, e);
 }
 }
 
 //  Omit irrelevant code 
}

There are certain javaagent Knowledge should know ,

premain

The method is java Startup time , load javaagent Post execution method .

That's a good fit .

The server code before the error is reported ,

ExecutorConfig

Class executor1 yes

ThreadPoolTaskExecutor

type ,executor2 and executor3 yes

ExecutorTtlWrapper

type , Use

applicationContext.getBean(clazz)

The name you can get is executor1 Of Bean.

And then use

-javaagent:/path/to/transmittable-thread-local-2.12.1.jar

To achieve zero intrusion

transmittable-thread-local

Injection capability .

ExecutorConfig

Class executor2 and executor3 yes

ThreadPoolTaskExecutor

type , Use

applicationContext.getBean(clazz)

You'll find three

ThreadPoolTaskExecutor

Type of Bean,Spring The container has no way to determine which one to return , So he threw

NoUniqueBeanDefinitionException

abnormal .

Local startup is the addition of

-javaagent:/path/to/transmittable-thread-local-2.12.1.jar

command , Problem recurrence .

solve the problem

It is easy to solve the above error reports , Is the use of

applicationContext.getBean(beanName, clazz)

Method , By entering the specified Bean Name and type of , Get OK Bean, Change the code to ：

public static void doSth(Object subtag, Object extra, long time) {
 ApplicationContextContainer.getBean(&quot;executor1&quot;, ThreadPoolTaskExecutor.class)
 .execute(() -> {
 //  Some business code 
 });
}

Pipeline release regression test , Problem solving .

Green mountain does not change , Green water flows long , I'll see you next time .