Analysis and solution of faults caused by the same bean ID in spring

preface

Recently, a colleague's bean configuration problem caused the production environment to write a large amount of data to the wrong redis instance, which almost hung up redis. After rapid problem location, it is found that a colleague added a redis configuration file, and the ID of the configured redissentinelconfiguration is the same. Then, when using @ Autowired to inject beans, the redis configuration read is not the original because of the mechanism covered by spring beans.

To sum up, there are two problems:

The code is as follows:

UserClient:

beans. xml:

beans2. xml:

application. properties:

Applition:

Run the program and you will find that no matter the injected userclient2 or userclient1, the output result is Shanghai. But what we want to achieve is that when injecting userclient1, the output should be Hangzhou, and when injecting userclient2, the output should be Shanghai. This is also the source of the problem mentioned at the beginning. To achieve this effect, it is easy to change the name of userconfiguration.

However, why just change the name? Why don't beans with the same bean ID in different spring configuration files be created separately? The reason is that spring overwrites instances with the same bean ID. You can understand it as a map. The key is the bean ID and the value is the class. Then, when the bean with the same ID is put twice, it will be overwritten naturally.

Let's first recall the bean life cycle:

The problem is that when registering the bean definition, we can see the following output from the console

That is, beans The userconfiguration configured in the XML is called beans2 Userconfiguration instance of XML configuration overrides. So naturally, the result we get is Shanghai.

Spring bean override

Through the above analysis, we already know that it is caused by the covered, so how to reflect it? If you encounter problems that cannot be solved, you can often get answers by looking at the source code:

The logic of this code is to throw an exception if instances with the same bean ID are not allowed to exist, and this value is true by default, that is, the same bean ID definition is allowed to exist.

@Autowired annotation implementation mechanism

The problem of bean coverage has been solved, so there is another problem. Why is there no error when @ Autowired is used to inject userclient? Two types of beans are clearly configured@ Autowired is injected according to bytype.

Are you sure? Not exactly.

Because @ Autowired is an annotation provided by spring, we can see how to inject code in Autowired annotation beanpostprocessor AutowiredMethodElement. In the inject() method.

1. Resolve dependencies

2. Obtain candidate beans and determine the optimal bean to be injected finally

3. The decision-making process of the optimal bean: 1) there is @ primary annotation when judging; 2) If not, get the bean with the highest priority, that is, whether it implements org springframework. core. Bean of ordered interface (priority comparison can be specified through annotation @ order (0). The smaller the number, the higher the priority); 3) If not, assemble according to the attribute name

Priority definition:

At this point, we can understand why @ Autowired can inject different beans through attribute names.

summary

The above is the whole content of this article. I hope the content of this article can bring some help to your study or work. If you have any questions, you can leave a message. Thank you for your support for programming tips.