Dependency Injection is one of those concepts every Java developer uses long before they understand what's actually happening beneath it. You annotate a field or constructor, Spring quietly hands you a fully wired object, and the application just works. But behind that simplicity is a surprisingly intricate machine involving reflection, proxies, and a carefully orchestrated container lifecycle. Understanding what happens under the hood makes debugging, performance tuning, and architectural decisions far easier. These core Spring concepts are explored in Java Training in Chennai at FITA Academy, helping developers build robust and scalable enterprise applications. 

The Core Idea Behind Dependency Injection

At its heart, Dependency Injection is about inversion of control. Instead of a class creating its own dependencies, something external creates them and hands them over. Spring's IoC container is that external party. It reads your configuration, whether through annotations, XML, or Java config classes, and builds a graph of objects called beans, wiring them together based on their declared relationships.

The real value here isn't just convenience. It decouples classes from the responsibility of instantiating their collaborators, which makes testing easier, swapping implementations trivial, and the overall system more modular.

The Application Context and the Bean Factory

Everything starts with the ApplicationContext, which is Spring's central interface for managing beans. Underneath it sits the BeanFactory, the actual engine responsible for instantiating, configuring, and assembling objects.

When your application starts, Spring performs a process often called component scanning. It walks through the specified packages looking for classes marked with stereotype annotations. For each one it finds, it doesn't create the object immediately. Instead, it registers a BeanDefinition, essentially a blueprint containing metadata about the class, its scope, its dependencies, and how it should be instantiated.

This separation between defining a bean and actually creating it is important. It allows Spring to resolve the entire dependency graph before instantiating anything, catching circular dependencies and misconfigurations early.

Reflection Is Doing the Heavy Lifting

Once Spring knows what beans exist and how they relate to each other, it needs to actually construct them. This is where Java reflection comes in. Spring inspects constructors, fields, and setter methods at runtime to figure out what needs to be injected and where.

For constructor injection, Spring examines the constructor's parameter types, resolves matching beans from the container, and invokes the constructor reflectively. For field injection, it uses reflection to bypass normal access modifiers and set private fields directly. This is part of why field injection, despite being convenient, is often discouraged. It hides dependencies from the class's public API and relies more heavily on reflection tricks that can complicate testing outside the container.

The Bean Lifecycle

Bean creation isn't a single step. Spring beans go through a defined lifecycle involving multiple phases: instantiation, populating properties, calling aware interfaces if implemented, invoking BeanPostProcessors, calling initialization callbacks, and finally making the bean available for use.

BeanPostProcessors deserve special attention because they are the mechanism many Spring features are built on. Annotations like PostConstruct, transactional behavior, and even the creation of proxies for AOP all hook into this stage. A post processor can inspect a bean after it's created and return a modified or entirely different object, which leads directly into how Spring implements proxying.

Proxies and Why They Matter

Many Spring features, including transaction management and security, rely on proxies rather than modifying your actual class. When a bean needs additional behavior wrapped around its methods, Spring doesn't rewrite your code. Instead, it generates a proxy object at runtime that intercepts method calls, executes any necessary logic beforehand or afterward, and then delegates to the real object.

Spring typically chooses between two proxying strategies. If your bean implements an interface, it uses a JDK dynamic proxy, which implements that interface at runtime. If there's no interface, it falls back to CGLIB, which generates a subclass of your actual class to intercept calls. This is also why self invocation within a class, calling one method from another on the same object, often doesn't trigger expected proxy behavior. The call never passes back through the proxy, so features like transactions silently don't apply.

Scopes and Singleton Management

By default, Spring beans are singletons, but that doesn't mean one instance for the entire JVM. It means one instance per Spring container. The container keeps a cache of fully initialized singleton beans and returns the same instance whenever it's requested, avoiding the enormous overhead of repeatedly resolving dependencies and running through the entire lifecycle again.

Other scopes, like prototype or request scoped beans, change this behavior. Prototype beans are created fresh every time they're requested, while web scoped beans hook into the request or session lifecycle, often coordinated behind the scenes through additional proxy layers so a singleton controller can safely reference a shorter lived scoped bean.

Knowing what's happening internally changes how you approach problems. Circular dependency errors make more sense once you understand that Spring is trying to resolve a graph before instantiation completes. Proxy related quirks, like transactions not applying to internal method calls, stop feeling like mysterious bugs. And decisions like preferring constructor injection over field injection start to feel less like stylistic opinions and more like practical choices grounded in how the container actually works.

Spring's Dependency Injection system feels like magic on the surface, but it's really a well engineered combination of reflection, metadata processing, and dynamic proxying, all working together to keep your application code clean while the container handles the wiring.