Original: Taste of Little Sister (wechat official ID: XjjDog), welcome to share, please reserve the source.

If I were to say that many Java hotshots have never used Spring in any depth. You might be surprised at the breadth of Spring applications, the number of features, and the fact that Three generations of Spring, SpringBoot, and SpringCloud have been credited with avoiding the decline of Java many times over, so there’s no reason not to take a closer look.

Spring has been instrumental in getting Java to where it is today. To say that Spring is good, that is more than 100 words of praise. Praise to the extreme is scold, we can only say: Spring cow B!

But why do many bulls rarely use Spring? This is also due to the nature of the work. They often write some middleware, do some distributed references, this time to introduce a Spring, much more bloated. They use Netty more than Spring.

The Spring family mostly solves engineering problems. However, most projects in the world have engineering problems, and it is also the easiest for the boss to make money. Therefore, they hit it off immediately.

For the most part, Spring is extremely difficult to use, especially if you’ve lived through the XML configuration explosion. So SpringBoot has built on this foundation and integrated a toolkit for rapid development. Out of the box, you can start it with a line of code.

@SpringBootApplication
public class Application {
    public static void main(String[] args) { SpringApplication.run(Application.class, args); }}Copy the code

In theory, it is a good thing that the framework is so simple to use. However, the resume is a little bit reckless, and the two glowing words are written on the resume, which directly blinds the interviewer. Want to beat the master into two dimensions – the hormone starts to surge. You know, the Spring family source code size, can be several gigabytes, have you really got it all?

I’m afraid I’m not a god.

The following does not distinguish between Spring and SpringBoot, because the distinction itself is meaningless.

Most of Spring’s interview questions are meaningless

For candidates who have worked for more than three years, the interviewer searched hard and could not find several questions related to Spring. IOC and AOP are such insulting questions that most people who have worked for many years cannot answer well because they are just a game of words. After tossing and turning, it suddenly hit me: Let’s talk about design patterns.

No, design patterns, by their nature, are also literal and easy to over-design, but it’s still a lot better than Spring source code.

Aren’t you proficient in Spring? Off the subject.

Spring – the data? Spring ws-security? Spring – webflow? This has nothing to do with Spring itself, this is the solution. If you’re not immersed in the industry scene for a year or two, how can you be proficient? If you talk about it, you will find that it has little to do with industry knowledge and whether Spring is involved or not.

So if you’re good at Spring, chances are you’re good at using it in the first place, especially those puking, self-propagating notes you read too much.

  1. What is Spring?

    Whoever asked that was out of his mind. Next problem.

  2. What are the benefits of using the Spring framework?

    The person who asks this question, taking up valuable time of your life, suggests you ask in return: What frame are you in relative to?

  3. What design patterns does Spring use?

    He wants to hear about the factory, the template, the singleton. Ten seconds.

You have to ask someone who knows what they’re doing, and it’s the kind of question that catches people off guard. I’ve seen an interviewer who likes to follow some long, boring theorems in Effective Java. Don’t think of it as a god book, it’s only for quiet moments of thought.

Take effective Java’s first rule: Why static factory methods replace constructors? The book lists five reasons.

  • You can have a name
  • You don’t need to create a new object every time
  • A subtype of any type can be returned
  • You can return different objects based on the arguments
  • The returned object does not have to exist

Take a look. There will be very few people around you who can answer the whole question, but that doesn’t stop them from writing code, or even core libraries. So these stinky and long nonsense, in fact, is your heart of conventional knowledge.

For example, if I ask you, why is the heart on the left and not the right? This is a moot question.

So what’s the most spring-related topic? That is the startup process of SpringBoot. Everyone who has suffered from Spring should know a thing or two. It could have been programmed sequentially, but that genius invented the @import annotation, and since then various Spring-boot-starter has entered the era where you have to read the source code to know what it does.

We can actually divide it into two parts.

SpringBoot loading process

First of all, the annotation SpringBootApplication actually contains a whole bunch of other annotations. The more important ones are,

  • SpringBootConfigurationIndicates that this is a configuration class that will be scanned and loaded intoIoCThe container
  • ComponentScanDefine the path to scan from the package of the annotation class by default
  • EnableAutoConfigurationThis is a SpringBoot-specific annotation used to load classes defined by SPI

Except for the last one, there’s nothing to say about the other two. The Enable series does a lot of work by dynamically registering scenario-specific bean definitions with the @import annotation. For example, @enablecaching and @enableDiscoveryClient are common.

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@AutoConfigurationPackage
@Import({AutoConfigurationImportSelector.class})
public @interface EnableAutoConfiguration {
    String ENABLED_OVERRIDE_PROPERTY = "spring.boot.enableautoconfiguration"; Class<? >[] exclude()default {};

    String[] excludeName() default {};
}
Copy the code

Looking at the code above, the Import annotation actually does some very heavy work. It imports the a class called AutoConfigurationImportSelector. This is where all of SpringBoot’s initialization comes in. Not only the Enable* annotation, but also the AutoConfigurationPackage annotation imports a class called Registrar through the Import.

So the @import annotation is really powerful. Because AutoConfigurationImportSelector ImportSelector interface is achieved, so has realized its selectImports method. The meta-INF /spring.factories loading is done in this method.

Layer by layer, the EnableAutoConfiguration annotation goes into the ImportSelector implementation and gives control of the loading to the AutoConfiguration specified by meta-INF/Spring.Factories.

It’s important to note that this loading process is not necessarily great. But since it’s the implementation of SpringBoot, and SpringBoot is very popular, hopefully you’ll be able to deal with it quickly when you run into problems. Taken together, it becomes a necessary knowledge.

SpringBoot boot process

To understand SpringBoot’s startup process, take a look at the various hooks it provides. We have the @PostConstruct annotation, the InitializingBean interface, CommandLineRunner, etc. There will be even more.

We need to categorize these implementations because some are global and some are Bean.

Take the global SpringBoot listener for example, there are CommandLineRunner and ApplicationRunner interface with similar functions, have to be said to be very bloated.

The process is definitely long and smelly, but what about these hook functions? It’s actually distributed through events. Whether global or Bean, a list of hooks is cached and the interface is invoked when the corresponding process is executed. Most hooks, since they are lists, have an Order, so adding the @order annotation can specify the Order in which they should be executed.

I’ve never been interested in the red tape, because the mechanics are there, and it’s up to the framer to decide how much to expose and how much to break down. There is no need to take it as a truism, the granularity and name of a different framework will be different, but the principle is the same.

End

Unfortunately, Spring and SpringBoot chose to expose these internal interfaces as much as possible, and added a lot of semantic apis to the functionality. For example, the original Bean extends @service, @Component, @repository, and so on. The result is that you have what you want, easy to get started but complicated to use; All kinds of packaging and jumping, even the debug message does not understand; As long as you expose the interface, there are always people who do not play cards according to the rules, so when using, generally will use norms to constrain.

These are not true, but Spring has chosen one of many possibilities. For example, indentation in Python and YML, automatic format in Go, is not truth, is choice, don’t get confused. You can demand it, but you can’t say it’s the right thing to do.

That’s not the kind of flexibility a company wants. For example, if you provide the CommandLineRunner interface, don’t worry about being an ApplicationRunner, which adds to the programmer’s mental burden. A spring-data-JPA, there are five or six ways to query, don’t you feel pain?

What’s more, some people are so proud of it that they don’t have to be. I don’t know that your job is to get out of one mountain of shit and clean up another. But the question is, what do you need all those shovels for?

Xjjdog is a public account that doesn’t allow programmers to get sidetracked. Focus on infrastructure and Linux. Ten years architecture, ten billion daily flow, and you discuss the world of high concurrency, give you a different taste. My personal wechat xjjdog0, welcome to add friends, further communication.