3 Java/SpringBoot Interview Questions: From Memorizing to Mastering Internals

1. Java String Operation Classes: String, StringBuffer, StringBuilder

Candidate's typical answer: lists three classes, states String immutable, StringBuffer thread-safe, StringBuilder fast. But misses root causes and practical implications.

Root Cause of Immutability

String : Backed by private final char[] value (JDK 9+ uses byte[]). The final modifier locks the array reference, and no public methods modify the array content. Operations like concat or substring create new String objects.

StringBuffer/StringBuilder : Use a non-final char[] value with smart expansion (default capacity 16, expands to old*2+2). Modifications operate directly on the array without creating new objects.

Thread Safety Mechanisms

StringBuffer : All key methods (e.g., append) are synchronized, ensuring safety under concurrent modification but incurring lock contention overhead.

StringBuilder : No synchronization; single-threaded performance is higher, but multi-threaded use causes data corruption.

String : Immutable by nature, thus inherently thread-safe; "modifications" simply create new objects.

Performance Comparison and Selection Guidelines

Single-threaded frequent concatenation (SQL building, log assembly): prefer StringBuilder , which can be 30% faster than StringBuffer.

Multi-threaded environments: must use StringBuffer or dedicated concurrent containers.

String constants or rarely modified strings: use String for clarity.

Critical Pitfall : Never use String concatenation in a loop ( s += i); it generates massive temporary objects, creating a performance bomb.

2. @SpringBootApplication Annotation: What Lies Beneath

Candidate answer: identifies @SpringBootApplication and @ComponentScan, but treats them as black boxes.

Source Code Structure

@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan
public @interface SpringBootApplication { ... }

Three Components Explained

@SpringBootConfiguration : Meta-annotation for @Configuration, marking the class as a configuration source where @Bean methods can be defined, replacing legacy XML configuration.

@ComponentScan : By default scans the package of the startup class and its sub-packages, automatically registering @Service, @Controller, etc. If components reside outside this hierarchy, specify basePackages manually (e.g., @ComponentScan(basePackages = "com.xxx")).

@EnableAutoConfiguration (Core) : The magic behind "convention over configuration". It auto-configures beans based on starter dependencies (e.g., spring-boot-starter-web brings Tomcat, Spring MVC). Unwanted auto-configurations can be excluded via

@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)

.

Common Pitfall

Placing service classes outside the startup class's package tree causes injection failures because they are not scanned. Fix by explicitly declaring the scan path.

3. Can @Autowired Inject a Mapper into a @Component Class?

Candidate answer: confidently says yes, because @Component gets scanned and @Autowired works. Misses the crucial MyBatis integration detail.

Why It Fails by Default

Spring dependency injection requires the bean to be registered in the container. While @Component registers the enclosing class, a bare Mapper interface is not automatically implemented or registered by Spring. Without a proxy implementation, @Autowired throws NoSuchBeanDefinitionException.

Two Correct Approaches

Annotate each Mapper interface with @Mapper : Explicitly tells MyBatis to generate a proxy implementation and hand it to Spring.

Add @MapperScan("com.xxx.mapper") on the startup class (recommended) : Batch-scans the specified package, registering all Mapper interfaces at once, reducing omissions.

Pitfall Avoidance

Do not substitute @Repository for @Mapper. @Repository is only a Spring stereotype for persistence components; it does not trigger MyBatis proxy generation, so injection still fails. Remember: MyBatis Mappers are special beans that must be registered via @Mapper or @MapperScan, independent of the @Component scanning mechanism.

Closing Thoughts

These "basic" questions are not trivial trivia; they test the depth of your technical foundation. Interviewers use them to quickly gauge problem-solving ability and understanding of underlying principles. Dismissing them as "useless eight-legged essays" is a misconception. When frameworks misbehave or requirements exceed conventions, solid fundamentals—thread scheduling, memory management, network protocols—become the decisive factor. Strong basics are not constraints; they are the scaffolding that supports a higher, more stable technical career.

Postscript : The first question was actually asked in a real interview; the candidate later faced the same question at another company.

Interview Preparation Strategy

For structured preparation, refer to the following strategy chart covering different assessment dimensions: