question
Background of the problem: Since springcache is not very useful, it is not aimed at fine-grained expiration time control. So our company wrote a cache aspect based on spel expression to achieve similar functions. But recently, it has been found that the key is null when the cache is generated during use.
The performance of the problem is mainly to find that in redis, sometimes there is cached data with a key suffix of null in the user's redis cache, but the value has user information:
reason
By chance, I found that this problem suddenly reappeared, so I started to debug and found that the original spring's own ParameterNameDiscoverer (a tool for obtaining method parameter names) used ASM (a bytecode manipulation framework) to parse method parameter names. , Cglib is the parameter name obtained by the parsed class file. In the method inside ParameterNameDiscoverer, it is found that the parsed class input stream is actually null, why is it, so I guess that the class of the disk file does not exist. So restart the project and find that the parameter name can be successfully obtained, but it cannot be obtained after executing the mvn clean command. In addition, because the LocalVariableTableParameterNameDiscoverer object is obtained by new each time when parsing the parameter name, it is not applied to its own caching mechanism, which leads to the frequent occurrence of this problem.
Thinking about the problem of the online test environment, it turns out that the script executed by online jenkens is to copy the file first and kill the process.
solution
- Adjust the redis cache aspect, if the spel expression cannot successfully obtain the value, it will not be cached.
- To adjust the spel tool, instead of creating a new LocalVariableTableParameterNameDiscoverer each time, use a singleton to apply its own caching mechanism, otherwise the disk io will be inefficient every time.
- Adjust the jenkens execution script, kill the process first and then restart the project.