EasySpring Boot#38 min readJul 11, 2026
Features of Spring Boot.
practice
Practice modeTest yourself instead of reading straight through
Hook: Spring Boot is the shortcut that turns a pile of Spring pieces into a running app with sensible defaults.
Question: What are the features of Spring Boot?
Answer: Spring Boot gives you starter dependencies, auto-configuration, embedded servers, externalized configuration, and production-ready tools like Actuator. It also reduces manual setup by choosing sensible defaults for things like web servers, logging, and application wiring. In simple words, it helps you build and run Spring apps faster with less boilerplate.
Interview-Ready Answer: Spring Boot features include starter dependencies, auto-configuration, embedded servers like Tomcat, externalized configuration, and production-ready support through Actuator. My mental model is that Spring Boot does the wiring and setup work for me, so I can focus on business code. A useful detail is that Boot can package the app as a standalone JAR, which makes deployment much simpler.
%22%20stroke%3D%22%234f46e5%22%20stroke-width%3D%221.5%22%2F%3E%3Ctext%20x%3D%22500%22%20y%3D%22308%22%20text-anchor%3D%22middle%22%20font-size%3D%2215%22%20font-weight%3D%22bold%22%20fill%3D%22%23ffffff%22%20font-family%3D%22Segoe%20UI%2C%20Arial%2C%20sans-serif%22%3ESpring%20Boot%3C%2Ftext%3E%3C%2Fsvg%3E)
What Spring Boot actually gives you
- Starter dependencies: A starter is a curated bundle of dependencies for a job, such as
spring-boot-starter-webfor REST APIs orspring-boot-starter-testfor testing. The big win is version compatibility: Boot chooses a known-good set so you do not spend time matching library versions by hand. - Auto-configuration: Boot watches the classpath, the beans you already defined, and the properties you set. Then it creates default beans only when they are needed, using conditions such as
@ConditionalOnClassand@ConditionalOnMissingBean. - Embedded servers: For web apps, Boot can start Tomcat, Jetty, or Undertow inside your app. That means you usually run a standalone JAR instead of deploying a WAR to an external application server.
- Externalized configuration: Settings can live in
application.properties,application.yml, environment variables, command-line arguments, or profile-specific files. This keeps the same binary usable in dev, test, and production. - Production-ready features: Actuator exposes endpoints such as
/actuator/healthand/actuator/metricsso ops teams can monitor the app. This is a practical feature, not just a framework feature. - Developer productivity: DevTools can restart the app faster during development, and Boot also integrates strongly with testing so slices and full-context tests are easier to write.
How it works under the hood
- SpringApplication.run() starts the app and creates the application context, which is the container that holds and wires beans.
- Component scanning finds classes under the package of your main class. A bean is just an object managed by Spring, such as a controller or service.
- Auto-configuration evaluates conditions. If Boot sees Spring MVC on the classpath and no custom web configuration that blocks it, it sets up the usual web stack automatically.
- Embedded server startup happens if a web starter is present. By default, Boot commonly runs on port
8080, and you can override that withserver.port. - Property binding loads configuration from the highest-precedence source first, then fills the rest from lower-priority sources. In practice, command-line args beat environment variables, which beat files.
- Context refresh completes the bean lifecycle and the app becomes ready to serve requests.
Boot vs traditional Spring
| Area | Traditional Spring | Spring Boot |
|---|---|---|
| Setup | More manual | Mostly automatic |
| Dependencies | Pick many versions yourself | Use starters |
| Server | External app server often needed | Embedded server by default |
| Config | More explicit wiring | Sensible defaults + overrides |
| Ops | Add monitoring separately | Actuator built in |
When and why to use it
- Use Boot when you want to build REST APIs, microservices, background jobs, or traditional web apps quickly.
- Use it when you want a clean path from code to runnable artifact, especially in Docker or cloud deployments.
- Use it when your team values convention over configuration, because the defaults remove a lot of repetitive setup.
Performance, defaults, and edge cases
- Startup work is roughly proportional to the number of classes and auto-configurations inspected, so think of it as
O(N)for startup scanning rather than a heavy per-request penalty. - Runtime request handling is mostly the cost of the underlying web stack; Boot itself adds a thin layer of glue, but the embedded server and loaded beans do use memory.
- Spring Boot 3.x requires Java 17 or newer and uses
jakarta.*namespaces, while Boot 2.x usedjavax.*. - If your main class is placed too deep or too high in the package tree, component scanning may miss beans or scan too much. The safest habit is to keep the main class at the root package.
- When you define your own bean, Boot usually backs off from creating the default one. That is a feature, not a bug: custom beans win over defaults.
- Default embedded Tomcat settings are practical, but if you need a random port for tests, use
server.port=0.
Memory-style summary: Spring Boot is not a different framework; it is Spring with the setup, server, and defaults already wired in.
Real-World Story: Imagine a checkout service in an e-commerce system. The team uses spring-boot-starter-web for REST APIs, Actuator for health checks, and externalized config for payment gateway URLs and timeouts. In Kubernetes, the app starts as a standalone JAR on port 8080, and ops can check /actuator/health before sending traffic.
Now the bug: one deployment accidentally used the wrong profile, so the health endpoint was not exposed and the app listened on a different port than the service expected. The symptoms were repeated pod restarts, Connection refused errors, and checkout requests timing out. From the user side, carts looked fine, but payment submission failed at peak traffic because the load balancer thought the app was unhealthy.
The lesson is simple: Spring Boot features are not just convenience; they are what make deployment predictable. Externalized configuration, embedded servers, and Actuator together prevent a lot of avoidable outages.
Spring Boot
package com.example.bootfeatures;
import java.util.LinkedHashMap;
import java.util.Map;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.boot.CommandLineRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
@SpringBootApplication
@RestController
public class SpringBootFeaturesDemoApplication {
// Externalized configuration: if app.title is not set anywhere,
// Boot uses the default value below. This is one reason Boot is easy to run in every environment.
@Value("${app.title:Spring Boot Demo}")
private String appTitle;
public static void main(String[] args) {
// One line is enough because Boot auto-configures the application context and embedded server.
SpringApplication.run(SpringBootFeaturesDemoApplication.class, args);
}
@Bean
CommandLineRunner startupMessage() {
// This runs after the context starts, which is a simple way to prove the app booted.
return args -> System.out.println("Started " + appTitle + " successfully.");
}
@GetMapping("/hello")
public ResponseEntity<?> hello(@RequestParam(required = false) String name) {
// Edge case: blank input should not be treated as a valid user name.
// Returning 400 is better than silently producing a misleading response.
if (name == null || name.isBlank()) {
Map<String, Object> error = new LinkedHashMap<>();
error.put("error", "name query parameter is required");
error.put("example", "/hello?name=Anita");
return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(error);
}
Map<String, Object> body = new LinkedHashMap<>();
body.put("app", appTitle);
body.put("message", "Hello, " + name + "!");
return ResponseEntity.ok(body);
}
}
Follow-up & Tricky Questions:
- What is auto-configuration in Spring Boot? It is Boot’s rule-based setup system that creates beans only when the classpath and your custom beans make it appropriate. The key idea is conditional configuration, so Boot helps without forcing unnecessary beans into the context.
- What is the difference between
@SpringBootApplicationand@EnableAutoConfiguration?@SpringBootApplicationis a convenience annotation that combines component scanning, auto-configuration, and configuration support. In most apps you use it on the main class instead of adding the lower-level annotations one by one. - Why are Spring Boot starters useful? They reduce dependency guesswork by grouping compatible libraries for a task. For example, the web starter pulls in Spring MVC and an embedded server setup, so you do not manually assemble the stack.
- How do you change the embedded server port? Set
server.port=9090in properties or pass--server.port=9090at startup. This is a classic example of externalized configuration overriding defaults. - What is Actuator used for? It exposes operational endpoints for health, metrics, and application info. This matters in production because observability is often the difference between a fast fix and a long outage.
- What happens if Boot finds two competing configurations? Boot usually backs off when you define your own bean, but if two libraries define the same type you may need to exclude one starter or provide a primary bean.
- Does Spring Boot replace Spring Framework? No. Boot sits on top of Spring Framework and makes Spring easier to bootstrap, configure, and deploy.
- Does Boot only work for web apps? No. It also supports batch jobs, messaging apps, CLI tools, and scheduled background services.
- Is
server.port=0a random bug? No, it is intentional. It tells the OS to choose a free ephemeral port, which is very useful in tests and parallel runs.
Tricky / gotcha questions:
- Does Boot always create every bean automatically? No. It creates beans only when its conditions match and your own configuration has not already provided one. That conditional behavior is the core of auto-configuration.
- Can you use Spring Boot without web dependencies? Yes. If you do not include a web starter, Boot can run as a non-web application, such as a batch process or a CLI utility.
- Is the default port always 8080? Commonly yes for a web app, but it is configurable and can even be randomized with
server.port=0. Interviewers often check whether you know defaults are just defaults.
Common Mistakes:
- Thinking Boot is a separate framework. Correction: it is Spring plus opinionated defaults, starters, and auto-configuration.
- Confusing starters with libraries that add new behavior. Correction: starters mainly simplify dependency selection and version alignment.
- Ignoring package structure. Correction: keep the main class at the root package so component scanning finds your beans.
- Forgetting production features. Correction: mention Actuator, metrics, and health checks, not just startup convenience.
Memory Hook: Think of Spring Boot as a car that already has the engine, dashboard, and GPS installed. You do not build the car from scratch; you just turn the key and drive.
Cheat Sheet:
- Starters = curated dependency bundles.
- Auto-configuration = smart defaults based on classpath and beans.
- Embedded server = standalone JAR, usually port 8080 by default.
- Externalized config = properties, YAML, env vars, profiles, command-line args.
- Actuator = health, metrics, and operational endpoints.
- Boot 3.x = Java 17+ and
jakarta.*.
Practice Tasks:
- Create a tiny REST API with
spring-boot-starter-weband verify it runs without an external server. - Add
app.titletoapplication.propertiesand see how it changes the response without changing code. - Expose Actuator health and test how a health check endpoint behaves when the app is running on a different port.