Digging into Spring's Source 5: How @Autowired Picks the Bean to Inject — Dependency Resolution

What this post covers

This is the fifth post in the "Digging into Spring's Source" series. Part 4 followed one getBean() call through the three steps of building a bean: instantiate, inject dependencies, initialise. For the second step I only said "a post-processor fetches another bean with getBean() and puts it where the @Autowired is" and moved on. This post opens up that sentence: how the bean to inject is found, and how one is chosen. On the map of Part 1 this is unit U03.

There are four questions to answer.

• Who notices an @Autowired field, and where does the bean to inject come from?
• When two or more beans have the same type, which one is injected — and in what order are @Primary, @Qualifier and the field name consulted?
• When the injection point is a List<T> or a Map<String, T>, what goes in, and who decides the order?
• When a class has several constructors, which one is called — and what happens when there is no bean to inject?

Every line number and every detail in this post refers to that commit. In other versions the line numbers will differ and some details may too. Part 1 explains how to get the source at the same commit.

The examples in this post were run on the released Spring Framework 7.0.9 to check their output (I did not build and run the 7.1.0-SNAPSHOT this series reads). The output shown is exactly what came out.

The dependency-injection source has many branches for special cases. This post keeps only the main thread that someone seeing Spring for the first time can follow; what was left out is named at the end, under "If you want to go deeper".

Words to know first

Bean and container were explained in Part 1 and Part 3. A bean is an object Spring creates and manages; the container is what creates and keeps those beans.

Dependency injection (DI) means the container hands an object the other objects it needs. Part 4 introduced the two flavours: field injection (into a field) and constructor injection (as a constructor argument).

An injection point is one place the container has to fill. One @Autowired field, one method parameter, one constructor parameter: each is one injection point. In the source it is the class InjectionPoint, and the main character of this post, DependencyDescriptor, extends it.

A candidate is a bean that could go into a given injection point. Usually, matching the type is enough to be a candidate. This whole post is really about "collecting candidates and narrowing them down to one".

A qualifier is a marker on an injection point that narrows the candidates further, such as @Qualifier("english").

A post-processor (BeanPostProcessor) is an object that gets a turn while a bean is being created. Part 4 showed the hooks around initialisation; @Autowired is handled by a post-processor too. That post-processor is the first section of this post.

1. Who finds @Autowired — AutowiredAnnotationBeanPostProcessor

@Autowired is only an annotation; by itself it does nothing. The thing that looks for it and fills in a value is a post-processor called AutowiredAnnotationBeanPostProcessor. The name is long, but read it as "the bean post-processor for the Autowired annotation" and it makes sense.

Which annotations it looks for

The constructor of this class builds the list of annotations to look for.

	public AutowiredAnnotationBeanPostProcessor() {
		this.autowiredAnnotationTypes.add(Autowired.class);
		this.autowiredAnnotationTypes.add(Value.class);

		ClassLoader classLoader = AutowiredAnnotationBeanPostProcessor.class.getClassLoader();
		try {
			this.autowiredAnnotationTypes.add((Class<? extends Annotation>)
					ClassUtils.forName("jakarta.inject.Inject", classLoader));
			logger.trace("'jakarta.inject.Inject' annotation found and supported for autowiring");
		}
		catch (ClassNotFoundException ex) {
			// jakarta.inject API not available - simply skip.
		}
	}

spring-beans/src/main/java/org/springframework/beans/factory/annotation/AutowiredAnnotationBeanPostProcessor.java, lines 192–205

Three of them: Spring's @Autowired, @Value for injecting values, and the standard jakarta.inject.Inject, only if it is on the classpath. Whenever this post says "marked @Autowired", read it as "marked with one of these three".

This post-processor is registered automatically when a container that uses annotation configuration, such as AnnotationConfigApplicationContext, starts (AnnotationConfigUtils lines 164–168). In the same place, two things that appear in sections 3 and 4 are plugged into the container as well: ContextAnnotationAutowireCandidateResolver, which judges qualifiers, and AnnotationAwareOrderComparator, which decides ordering (lines 148–153).

When and how it gets its turn

Part 4's second step, populateBean(), calls postProcessProperties() on every registered post-processor (AbstractAutowireCapableBeanFactory lines 1442–1448). Our post-processor's version of that method is two lines: look up the list of injection points for this class (InjectionMetadata) and tell it to inject (lines 490–502).

From one field to its value. The yellow box is a list built once per class; the blue box is the post-processor hook from Part 4.

The list of injection points is built by scanning the class (buildAutowiringMetadata, lines 547–607). It walks the fields and methods, collects those carrying one of the three annotations, then moves up to the superclass and repeats (do ... while (targetClass != null && targetClass != Object.class), lines 602–604). The result is cached under the bean name, so the reflective scan happens once per class (lines 527–545).

The code that actually fills one field, AutowiredFieldElement.resolveFieldValue(), is the starting point of this whole post (lines 756–791). Two lines matter. One field becomes one DependencyDescriptor (new DependencyDescriptor(field, this.required), line 757), and that descriptor is handed to the container's resolveDependency() (line 764). Method injection does the same for each parameter (line 864). The returned value is written into the field only if it is not null (lines 750–753).

The question form — DependencyDescriptor

A DependencyDescriptor is a form that says "this is what this place needs". It wraps a field or a parameter and answers the following.

The last row is the link back to Part 4. Once the candidates have been found and one chosen, its name goes into getBean(), and if that bean does not exist yet, Part 4's creation journey starts right there.

Easy to get wrong

• static fields are not injected. While building the list, static fields and methods are skipped with only a log message (lines 560–565, lines 578–583).
• Superclass fields are filled first. The elements collected while walking up are inserted at the front of the list (elements.addAll(0, ...), lines 600–601).
• private fields are injected too. ReflectionUtils.makeAccessible(field) is called before the value is written (line 751). Access modifiers have nothing to do with injection. Shared tools such as ReflectionUtils get their own post, Part 16.

2. Finding candidates — from resolveDependency to findAutowireCandidates

The resolveDependency() that receives the form lives in DefaultListableBeanFactory, the class from Part 3 that implements everything a container does. It first separates out three special cases, Optional, ObjectProvider and @Lazy (section 6; jakarta.inject.Provider, if it is on the classpath, is separated out in the same place, lines 1648–1650), and hands everything else to doResolveDependency() (lines 1637–1659). It is the xxx() / doXxx() pairing we saw in Part 4.

doResolveDependency() is pleasant to read because the source labels it Step 1 through Step 6. Reduced to its skeleton:

	public @Nullable Object doResolveDependency(DependencyDescriptor descriptor, @Nullable String beanName,
			@Nullable Set<String> autowiredBeanNames, @Nullable TypeConverter typeConverter) throws BeansException {
		// ...
			// Step 1: pre-resolved shortcut for single bean match, for example, from @Autowired
			Object shortcut = descriptor.resolveShortcut(this);
			// ...
			// Step 2: pre-defined value or expression, for example, from @Value
			Object value = getAutowireCandidateResolver().getSuggestedValue(descriptor);
			// ...
			// Step 3: shortcut for declared dependency name or qualifier-suggested name matching target bean name
			if (descriptor.usesStandardBeanLookup()) {
				// ...
			}

			// Step 4a: multiple beans as stream / array / standard collection / plain map
			Object multipleBeans = resolveMultipleBeans(descriptor, beanName, autowiredBeanNames, typeConverter);
			// ...
			// Step 4b: direct bean matches, possibly direct beans of type Collection / Map
			Map<String, Object> matchingBeans = findAutowireCandidates(beanName, type, descriptor);
			if (matchingBeans.isEmpty()) {
				// ...
				// Raise exception if nothing found for required injection point
				if (isRequired(descriptor)) {
					raiseNoMatchingBeanFound(type, descriptor.getResolvableType(), descriptor);
				}
				return null;
			}
			// ...
			// Step 5: determine single candidate
			if (matchingBeans.size() > 1) {
				autowiredBeanName = determineAutowireCandidate(matchingBeans, descriptor);
				if (autowiredBeanName == null) {
					if (isRequired(descriptor) || !indicatesArrayCollectionOrMap(type)) {
						// Raise exception if no clear match found for required injection point
						return descriptor.resolveNotUnique(descriptor.getResolvableType(), matchingBeans);
					}
					// ...
				}
				instanceCandidate = matchingBeans.get(autowiredBeanName);
			}
			// ...
			// Step 6: validate single result
			// ...
			if (instanceCandidate instanceof Class) {
				instanceCandidate = descriptor.resolveCandidate(autowiredBeanName, type, this);
			}
			return resolveInstance(instanceCandidate, descriptor, type, autowiredBeanName);
		// ...
	}

spring-beans/src/main/java/org/springframework/beans/factory/support/DefaultListableBeanFactory.java, lines 1662–1776

Steps 1 to 5. Green is an exit that returns a value; red is an exit that throws.

Read from the top:

1. Steps 1 and 2: the fast lanes. If this injection point was resolved once before and the bean name remembered (the post-processor from section 1 caches it as a ShortcutDependencyDescriptor, lines 910–923), that name is used directly. With @Value, a converted value is returned instead of a bean. This post does not cover @Value.
2. Step 3: same name, done. If there is a bean whose name is exactly the field name (or the @Qualifier value) and its type matches, that bean is returned without collecting candidates at all (lines 1696–1715). Two of the examples in section 3 actually finish here.
3. Step 4a: places that take many. If the type is an array, List, Set or Map, every matching bean is collected and returned. That is section 4.
4. Step 4b: collecting candidates. findAutowireCandidates() returns the beans that "match the type and qualify as candidates" as a map from name to object. If it is empty and the injection point is required, a NoSuchBeanDefinitionException is thrown.
5. Step 5: choosing one. With two or more candidates, determineAutowireCandidate() chooses (section 3). If it cannot, resolveNotUnique() is called, which means a NoUniqueBeanDefinitionException (DependencyDescriptor lines 191–193).
6. Step 6: fetching. The chosen name goes into resolveCandidate(), that is, getBean().

Qualifying as a candidate — findAutowireCandidates

findAutowireCandidates(), which collects the candidates, has three parts (lines 1959–2005).

1. Collect names by type. BeanFactoryUtils.beanNamesForTypeIncludingAncestors() (lines 1962–1963) calls the getBeanNamesForType() from section 5-3 of Part 3 and, if there is a parent container, asks it too (BeanFactoryUtils lines 261–274). It is the lookup that walks every blueprint and compares types.
2. Leave yourself out. isSelfReference() filters out the case where the bean being built finds itself as a candidate (line 1977, lines 2269–2273).
3. Ask whether it qualifies. isAutowireCandidate() asks the AutowireCandidateResolver plugged in during section 1. The most basic qualification is the blueprint's autowireCandidate flag (AutowireCandidateResolver lines 45–46); a generic-type check and the @Qualifier check sit on top of it. Section 3 covers that.

Example 1: two beans of the same type

Two beans implement the Greeter interface and there is one place to put one.

// An example written for this post (not Spring's code)
public class NoUniqueExample {

    interface Greeter {
        String greet();
    }

    @Component
    static class KoreanGreeter implements Greeter {
        public String greet() { return "안녕하세요"; }
    }

    @Component
    static class EnglishGreeter implements Greeter {
        public String greet() { return "Hello"; }
    }

    @Component
    static class Welcome {
        @Autowired
        Greeter greeter;                      // two Greeter beans — which one goes here?
    }

    public static void main(String[] args) {
        try (var context = new AnnotationConfigApplicationContext()) {
            context.register(KoreanGreeter.class, EnglishGreeter.class, Welcome.class);
            context.refresh();
            // ...
        }
        catch (BeansException ex) {
            Throwable root = NestedExceptionUtils.getMostSpecificCause(ex);
            System.out.println(root.getClass().getSimpleName() + ": " + root.getMessage());
        }
    }
}

Run it and, after one WARN log line from the container, this is printed (every output in this post omits that one log line).

NoUniqueBeanDefinitionException: No qualifying bean of type 'ex.u03.NoUniqueExample$Greeter' available: expected single matching bean but found 2: noUniqueExample.KoreanGreeter,noUniqueExample.EnglishGreeter

Exactly the flow above. Two candidates are collected in Step 4b, Step 5 has nothing to choose by, and resolveNotUnique() throws. The "expected single matching bean but found 2" part is built by the exception's constructor (NoUniqueBeanDefinitionException lines 95–100); the "No qualifying bean of type ... available" prefix is added by its superclass NoSuchBeanDefinitionException (lines 99–103). "None" and "too many" are in an inheritance relationship (line 38).

Easy to get wrong

• The values in the candidate map may not be beans. addCandidateEntry() stores the object if the singleton already exists, but for a bean not created yet it stores only the Class (lines 2011–2028). As the source comment says, this prevents every candidate from being created ahead of choosing one. That is why Step 6 has the instanceCandidate instanceof Class check that calls getBean() only then. Candidates that were not chosen are not created because of this injection.
• You are the candidate of last resort. The self reference excluded in part 2 is tried once more at the very end, when no other candidate exists (lines 1992–2002).

3. Choosing one of several — @Primary, names, @Qualifier

This is determineAutowireCandidate(), called when two or more candidates remain. The order is written in the source comments.

	protected @Nullable String determineAutowireCandidate(Map<String, Object> candidates, DependencyDescriptor descriptor) {
		Class<?> requiredType = descriptor.getDependencyType();
		// Step 1: check primary candidate
		String primaryCandidate = determinePrimaryCandidate(candidates, requiredType);
		if (primaryCandidate != null) {
			return primaryCandidate;
		}
		// Step 2a: match bean name against declared dependency name
		String dependencyName = descriptor.getDependencyName();
		// ...
		// Step 2b: match bean name against qualifier-suggested name
		String suggestedName = getAutowireCandidateResolver().getSuggestedName(descriptor);
		// ...
		// Step 3: check highest priority candidate
		String priorityCandidate = determineHighestPriorityCandidate(candidates, requiredType);
		if (priorityCandidate != null) {
			return priorityCandidate;
		}
		// Step 4: pick unique default-candidate
		String defaultCandidate = determineDefaultCandidate(candidates);
		if (defaultCandidate != null) {
			return defaultCandidate;
		}
		// Step 5: pick directly registered dependency
		// ...
		return null;
	}

spring-beans/src/main/java/org/springframework/beans/factory/support/DefaultListableBeanFactory.java, lines 2038–2082

The selection order. @Primary comes before the name, and the name before @Priority.

@Primary is an annotation, but what the chooser looks at is not the annotation; it is the blueprint's isPrimary() flag (lines 2188–2195). Reading the annotation and copying it into the blueprint is finished at the stage where blueprints are built (the subject of Part 8). The opposite of @Primary, @Fallback (since 6.2), is checked in the same method: if every other candidate is a @Fallback, the one that is not gets chosen (lines 2116–2126, Fallback lines 25–47).

Examples 2, 3 and 4: @Primary, @Qualifier, the field name

I ran example 1 three more times, changing only Welcome and the bean declarations. The rest of the code is the same as example 1, so only the changed parts are shown.

// An example written for this post (not Spring's code) — PrimaryExample
    @Component
    @Primary                                   // "when there are several, pick me"
    static class KoreanGreeter implements Greeter {
        public String greet() { return "안녕하세요"; }
    }
    // ...
    @Component
    static class Welcome {
        @Autowired
        Greeter greeter;
    }

KoreanGreeter -> 안녕하세요

// An example written for this post (not Spring's code) — QualifierExample
    @Component("korean")                       // the bean name is set explicitly
    static class KoreanGreeter implements Greeter {
        public String greet() { return "안녕하세요"; }
    }

    @Component("english")
    static class EnglishGreeter implements Greeter {
        public String greet() { return "Hello"; }
    }

    @Component
    static class Welcome {
        @Autowired
        @Qualifier("english")                  // only candidates with this name (or this qualifier)
        Greeter greeter;
    }

EnglishGreeter -> Hello

// An example written for this post (not Spring's code) — FieldNameExample
    @Component
    static class Welcome {
        @Autowired
        Greeter korean;                        // field name = bean name "korean"

        @Autowired
        Greeter english;                       // field name = bean name "english"
    }

korean  -> 안녕하세요
english -> Hello

All three were chosen as expected, but in the source they take different roads. @Primary has two candidates collected in Step 4b and is chosen by rule ① of the table. @Qualifier("english") and the field name korean, on the other hand, equal a bean name, so they finish in the Step 3 shortcut of section 2 before any candidates are collected (lines 1697–1704). The field name comes from getDependencyName(), the @Qualifier value from getSuggestedName() (QualifierAnnotationAutowireCandidateResolver lines 394–404). Rule ② of the table is a second chance for when that shortcut could not be taken.

@Qualifier is a filter more than a chooser

The value of @Qualifier does not have to be a bean name. You can put @Qualifier("fast") on the bean class as well and write @Qualifier("fast") at the injection point. Then there is no Step 3 shortcut; instead the filtering happens in the third part of section 2, "does it qualify". QualifierAnnotationAutowireCandidateResolver.isAutowireCandidate() looks for qualifier annotations on the injection point (@Qualifier, and jakarta.inject.Qualifier if it is on the classpath, lines 76–85) and checks whether the candidate bean carries the same qualifier (lines 149–168, lines 248–328). A bean whose qualifier does not match never becomes a candidate. So with a @Qualifier, the candidates are usually already down to one before Step 5. A value equal to the bean name (or an alias) also counts as a match (lines 311–315).

Easy to get wrong

• Even when the field name matches, @Primary wins. The Step 3 shortcut has the condition !hasPrimaryConflict(dependencyName, type) (lines 1705–1707, lines 2279–2291). If another bean of the same type is @Primary, the shortcut is skipped and rule ① of Step 5 chooses the @Primary one. I tried example 4 with @Primary added to EnglishGreeter and nothing else changed (PrimaryBeatsNameExample).

korean -> EnglishGreeter / Hello

• Two @Primary beans throw. The message is "more than one 'primary' bean found among candidates" (lines 2103–2105). Strictly, that is when both are in the same container; if one is in this container and the other in the parent, this container's wins (lines 2100–2109).
• Constructor and method parameter names depend on a compiler flag. Parameter names are read reflectively by DefaultParameterNameDiscoverer, and the source comment says "Recommended approach on Java: compilation with -parameters" (lines 45–52). Without that flag, name matching (rule ②) may not work for constructor injection. Field names do not depend on any compiler flag.

4. Taking all of them — List, Map, arrays and @Order

Sometimes you want all beans of a type rather than one. Declare the injection point as List<Greeter>, Set<Greeter>, Greeter[] or Map<String, Greeter>. Step 4a of section 2, resolveMultipleBeans(), handles it (lines 1793–1846). It looks at the type and takes one of four branches.

The candidates are collected by the same findAutowireCandidates() as in section 2, except that the form is wrapped in a MultiElementDescriptor (lines 1870–1871), in which case addCandidateEntry() does not store a Class but calls getBean() for every candidate right away (lines 2014–2019). They are all going in anyway.

Sorting is done by the dependencyComparator plugged into the container (lines 1922–1931). As section 1 showed, an annotation-configured container has AnnotationAwareOrderComparator, which reads the @Order value or, failing that, the jakarta.annotation.Priority value (OrderUtils lines 118–128). Without either, the bean gets the lowest priority (Ordered.LOWEST_PRECEDENCE) (OrderComparator lines 128–135). Smaller values come first.

Example 6: List and Map, and @Order

// An example written for this post (not Spring's code)
public class ListOrderExample {

    interface Greeter {
        String greet();
    }

    @Component("korean")
    @Order(2)
    static class KoreanGreeter implements Greeter {
        public String greet() { return "안녕하세요"; }
    }

    @Component("english")
    @Order(1)
    static class EnglishGreeter implements Greeter {
        public String greet() { return "Hello"; }
    }

    @Component("japanese")                     // no @Order
    static class JapaneseGreeter implements Greeter {
        public String greet() { return "こんにちは"; }
    }

    @Component
    static class Welcome {
        @Autowired
        List<Greeter> greeters;                // every Greeter bean, in order

        @Autowired
        Map<String, Greeter> greetersByName;   // bean name -> bean
    }

    public static void main(String[] args) {
        try (var context = new AnnotationConfigApplicationContext()) {
            context.register(KoreanGreeter.class, JapaneseGreeter.class, EnglishGreeter.class, Welcome.class);
            // ... (print greeters in turn, then the keySet() of greetersByName)
        }
    }
}

EnglishGreeter -> Hello
KoreanGreeter -> 안녕하세요
JapaneseGreeter -> こんにちは
[korean, japanese, english]

The List comes out as @Order(1), @Order(2), none, which is not the registration order (korean, japanese, english). The Map's keys, however, are in registration order, because, as the table says, a Map is not sorted.

The same three candidates go into the List in @Order order and into the Map in registration order. The order is taken from Example 6's actual output.

Easy to get wrong

• @Primary has no effect on collection injection. The Javadoc of @Primary says so explicitly: arrays, collections and maps receive every type-matching bean (Primary lines 30–32).
• A Map's key must be String. With any other key type, resolveMultipleBeanMap() returns null and the injection point is not treated as "take all" (lines 1893–1896).
• A bean is not in its own collection. The self-reference exclusion from section 2 applies here too, and even the last-resort pass leaves out "that very bean" for a collection (lines 1992–2002).

5. Constructor injection — when there are several constructors

So far this has all been field injection, which happens after the object exists. Constructor injection happens inside Part 4's first step, instantiation. Two things have to be decided: which constructor to call, and what to pass as its arguments.

Which constructor — determineCandidateConstructors

Before picking a constructor, createBeanInstance() asks the post-processors "is there a constructor worth using?" (AbstractAutowireCapableBeanFactory lines 1215–1219, lines 1313–1325). The one that answers is, once again, the AutowiredAnnotationBeanPostProcessor of section 1. The rules are in the second half of its determineCandidateConstructors().

					if (!candidates.isEmpty()) {
						// Add default constructor to list of optional constructors, as fallback.
						if (requiredConstructor == null) {
							if (defaultConstructor != null) {
								candidates.add(defaultConstructor);
							}
							// ...
						}
						candidateConstructors = candidates.toArray(EMPTY_CONSTRUCTOR_ARRAY);
					}
					else if (rawCandidates.length == 1 && rawCandidates[0].getParameterCount() > 0) {
						candidateConstructors = new Constructor<?>[] {rawCandidates[0]};
					}
					else if (nonSyntheticConstructors == 2 && primaryConstructor != null &&
							defaultConstructor != null && !primaryConstructor.equals(defaultConstructor)) {
						candidateConstructors = new Constructor<?>[] {primaryConstructor, defaultConstructor};
					}
					else if (nonSyntheticConstructors == 1 && primaryConstructor != null) {
						candidateConstructors = new Constructor<?>[] {primaryConstructor};
					}
					else {
						candidateConstructors = EMPTY_CONSTRUCTOR_ARRAY;
					}

spring-beans/src/main/java/org/springframework/beans/factory/annotation/AutowiredAnnotationBeanPostProcessor.java, lines 419–446

Choosing a constructor. The grey box is the road where the post-processor chose nothing.

Read from the top, there are four rules. candidates is the list of "constructors marked @Autowired" gathered by the loop just above (lines 375–418).

1. If there are @Autowired constructors, those. Only one may have required = true (the default); two throw "Invalid autowire-marked constructor" (lines 397–412). Several with required = false are allowed, and then the default constructor, if there is one, is appended as a fallback.
2. Otherwise, if there is exactly one constructor and it takes arguments, that one. This is why a class with a single constructor gets constructor injection without any @Autowired.
3. Otherwise, the primary constructor of a record or a Kotlin class. This rule is the two else if branches in the code above: if there is a separate default constructor besides the primary one, both are returned together (lines 437–440); if the primary constructor is the only one, just that (lines 441–443). BeanUtils.findPrimaryConstructor() finds a record's canonical constructor or a Kotlin primary constructor (lines 278–296).
4. Otherwise an empty array, meaning "nothing chosen" (null) (line 451). createBeanInstance() then simply calls new through the default constructor (line 1228). If there is none, the result is "No default constructor found" (SimpleInstantiationStrategy lines 98–102).

What goes into the arguments — ConstructorResolver

When the post-processor returns one or more constructors, ConstructorResolver.autowireConstructor() takes over (lines 135–311). With several candidates it sorts them, public first and the ones with more arguments first (line 209, AutowireUtils lines 64–73), and tries to fill the arguments of each in turn. A constructor whose arguments cannot be filled is skipped for the next one (lines 243–253). This is the "constructor with the greatest number of dependencies that can be satisfied" from the Javadoc of @Autowired (Autowired lines 36–39).

Filling one argument takes the same road as field injection. A DependencyDescriptor is made for each parameter (line 789) and resolveDependency() is called (lines 900–912). Everything in sections 2 to 4 applies to constructor arguments unchanged. That line is the one Part 4, section 6, pointed at when explaining why a constructor-injection cycle cannot be resolved.

Example 5: one constructor, two constructors

// An example written for this post (not Spring's code)
public class ConstructorExample {

    @Component
    static class Engine {
        public String toString() { return "Engine"; }
    }

    /** One constructor — used even without @Autowired. */
    @Component
    static class Car {
        final Engine engine;
        Car(Engine engine) { this.engine = engine; }
    }

    /** Two constructors, no @Autowired, a default constructor exists — the default one is used. */
    @Component
    static class Bike {
        Engine engine;
        Bike() { }
        Bike(Engine engine) { this.engine = engine; }
    }

    /** Two constructors, no @Autowired, no default constructor — nothing can be chosen. */
    @Component
    static class Truck {
        Engine engine;
        Truck(Engine engine) { this.engine = engine; }
        Truck(Engine engine, int wheels) { this.engine = engine; }
    }

    public static void main(String[] args) {
        try (var context = new AnnotationConfigApplicationContext()) {
            context.register(Engine.class, Car.class, Bike.class);
            // ... (print the engine field of Car and of Bike)
        }
        try (var context = new AnnotationConfigApplicationContext()) {
            context.register(Engine.class, Truck.class);
            // ... (on an exception, print its message and the root cause)
        }
    }
}

The output:

Car.engine  = Engine
Bike.engine = null
BeanCreationException: Error creating bean with name 'constructorExample.Truck': Failed to instantiate [ex.u03.ConstructorExample$Truck]: No default constructor found
  root cause: NoSuchMethodException: ex.u03.ConstructorExample$Truck.<init>()

• Car is rule 2. One constructor, so Engine came in without any @Autowired.
• Bike is rule 4. Two constructors and no @Autowired, so the post-processor chooses nothing and the container uses the default constructor. No exception; engine just stays null. The second constructor is never used.
• Truck is rule 4 as well, but with no default constructor it ends in "No default constructor found". Putting @Autowired on one of the two constructors switches it to rule 1 and fixes it.

Easy to get wrong

• Bike is the trap. When one of two constructors is a default constructor, it is quietly used, and the field you expected to be injected is null. That is harder to notice than Truck, which throws.
• The default constructor is only a fallback. When rule 1 puts required = false @Autowired constructors and the default constructor together as candidates, ConstructorResolver tries the ones with more arguments first (among constructors of the same visibility), so the default constructor is used only if none of the others can be filled.
• An @Autowired constructor does not have to be public. The Javadoc says so (Autowired line 43), and none of the constructors in the example above is public.

6. Nothing there, or later — required, Optional, ObjectProvider, @Lazy

Finally, "what if there is no bean to inject". In Step 4b of section 2, when there were no candidates, a true isRequired(descriptor) meant an exception and a false one meant null. The answer to isRequired has two layers. DependencyDescriptor.isRequired() checks whether the type is Optional or the element is @Nullable (lines 157–168), and on top of that QualifierAnnotationAutowireCandidateResolver.isRequired() looks at @Autowired(required = false) (lines 347–365). Either way, if the answer is "not strictly required", null comes back, and as section 1 showed, null is never written into the field, so the field keeps whatever value it was declared with.

Optional, ObjectProvider and @Lazy mean more than "may be absent": they mean "do not look it up now", so resolveDependency() separates them by type before doResolveDependency() is reached. Optional goes to lines 1641–1642, ObjectFactory or ObjectProvider to lines 1644–1646, a @Lazy injection point to lines 1651–1657 (the lines 1648–1650 in between are jakarta.inject.Provider), and everything else to section 2's doResolveDependency() (line 1658).

The three grey boxes are the roads where something other than the real bean is injected.

All three methods of ObjectProvider reuse section 2's doResolveDependency(). Each tweaks the form (DependencyDescriptor) with an anonymous subclass so that isRequired() returns false, or resolveNotUnique() returns null instead of throwing, and then calls the same resolver (lines 2565–2575, lines 2599–2612).

@Lazy is the thing Part 4 named at the end as "a way to break a cycle". Put @Lazy on one constructor argument of a constructor-injection cycle and, instead of looking the other bean up at instantiation time, a proxy is injected, so the exception from Part 4, section 6, does not occur (this comes from reading the source; I did not run an example for it in this post). The proxy is built with ProxyFactory (lines 100–107), and what happens inside it is the subject of Part 10. This class lives in spring-context rather than spring-beans precisely because it needs the proxy machinery from spring-aop.

Easy to get wrong

• required = false means "may be absent", not "may be several". With two candidates, Step 5 throws NoUniqueBeanDefinitionException regardless of required (lines 1744–1747). To tolerate several, use ObjectProvider.getIfUnique() or a collection.
• The "nothing found" message includes the annotations. It has the form "expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: ..." (lines 2297–2305). That is the clue for spotting a mistyped qualifier that left zero candidates.

If you want to go deeper

Only the names and locations of what this post left out. Step 2, which resolves and converts @Value values and expressions — the expression language, SpEL, is covered in Part 15 — (lines 1675–1694, continued by Part 15 on SpEL). GenericTypeAwareAutowireCandidateResolver, which matches generic types too (from line 46; it needs ResolvableType from Part 13). Custom qualifier annotations that carry @Qualifier as a meta-annotation (checkQualifiers lines 176–221). The second attempt, the fallback match, made when the first candidate search finds nothing (lines 1981–1991, DependencyDescriptor lines 309–320). The older style of autowire="byName" and "byType" driven by blueprint settings rather than annotations (populateBean lines 1425–1437). registerResolvableDependency, which registers non-bean objects as injection candidates, and the code that puts them into the candidate map (lines 1965–1975). Receiving the InjectionPoint itself as a constructor argument (ConstructorResolver lines 903–909). The cache that reuses a resolved result from the second time on (ShortcutDependencyDescriptor, lines 910–923). And the AOT path that generates injection code ahead of time (AotContribution, from line 929, Part 16).

Recap

What to look at next

This post opened the place where Part 4 said only "fetched with getBean()". One field became a form, the form collected candidates, and the candidates were narrowed down to one.

We saw the @Autowired post-processor get its turn in two places, populateBean and createBeanInstance, and Part 4 showed the hooks around initialisation. The next question is how many places there are to get a turn while the container builds a bean, and in what order they are called. Part 6: Lifecycle Callbacks and PostProcessors — Where You Can Hook into the Container sorts out the variants of BeanPostProcessor and the order in which @PostConstruct, InitializingBean and the Aware interfaces are called.

• Part 1: How I Read It with AI, and the Map
• Part 2: The Big Map — Modules and Packages
• Part 3: The BeanFactory Hierarchy and BeanDefinition
• Part 4: How a Bean Gets Created — the Creation Flow and the Three-Level Cache