Spring Core
& IoC/DI trong một trang

Ba trụ cột cần nhớ

• Container — BeanFactory / ApplicationContext: nơi chứa và quản lý bean
• DI — cơ chế nối các bean lại với nhau
• AOP — tách cross-cutting concern (log, tx, security) khỏi business code

Luồng gọi điển hình: AppConfig → container khởi tạo → nạp @Component/@Bean → inject → sẵn sàng dùng.

Module chính của Spring Framework

“Spring Core” ở đây gồm core + beans + context + aop. Web, Data, Security là các module khác (file riêng).

Spring Framework 6 — điểm khác

• Yêu cầu Java 17+
• Namespace chuyển từ javax.* sang jakarta.*
• @PostConstruct/@PreDestroy lấy từ jakarta.annotation, không còn javax.annotation
• Hỗ trợ AOT + GraalVM native image (build-time processing)
• Observation API + Micrometer cho tracing/metrics (Spring Boot 3)
• @MockBean deprecate → dùng @MockitoBean (Spring Boot 3.4+)

Bốn câu mở đầu hay gặp

1. Spring là gì, IoC và DI khác nhau thế nào?
2. Bean là gì, làm sao khai báo?
3. BeanFactory và ApplicationContext khác gì?
4. Constructor, setter và field injection nên dùng loại nào?

Gợi ý: trả lời ngắn gọn rồi dẫn sang một ví dụ bạn đã dùng thật — điều này tạo ấn tượng hơn kể tên.

Khởi tạo context

Trong Spring Boot, bạn hiếm khi tự new context — SpringApplication.run() làm việc đó, tạo ServletWebServerApplicationContext.

Context hierarchy

• Context con nhìn thấy bean của context cha
• Context cha không thấy bean của con
• Spring Boot thường chỉ dùng một context duy nhất

getBean và lỗi tương ứng

Bean registry — chuyện bên trong

• Mỗi bean có một BeanDefinition (class, scope, lazy, init/destroy, dependencies…)
• Bean được lưu trong DefaultListableBeanFactory
• singletonObjects (level-1 cache) giữ instance đã khởi tạo xong
• Bean name mặc định: tên method (@Bean) hoặc tên class viết thường chữ đầu (@Component)

Stereotype annotation

Ba annotation kia đều được meta-annotated bằng @Component — về chức năng như nhau, khác ở ngữ nghĩa và xử lý riêng.

@Component vs @Bean

@Configuration full vs lite mode

Full mode: class @Configuration bị CGLIB subclass để chặn lời gọi @Bean chéo, đảm bảo trả về cùng singleton.

@ComponentScan

• Mặc định quét từ package của class config trở xuống
• @SpringBootApplication đã bọc sẵn @ComponentScan
• Quét quá rộng → chậm start; quét hẹp → thiếu bean

Tên bean, alias và đụng độ

• Tên mặc định: class CreditCardPayment → creditCardPayment
• Hai bean cùng tên → bean định nghĩa sau ghi đè (hoặc lỗi nếu allow-bean-definition-overriding=false)
• Hai bean cùng type mà không có @Primary/@Qualifier → lỗi lúc inject

@Autowired phân giải thế nào

1. Tìm bean theo type
2. Nhiều ứng viên → khớp theo name (tên field/tham số)
3. Vẫn mơ hồ → dùng @Primary hoặc @Qualifier
4. Không có bean → NoSuchBeanDefinitionException (trừ khi required=false)

@Qualifier và @Primary

@Qualifier nhận tên bean (mặc định là tên class viết thường chữ đầu). Có thể tạo qualifier tùy biến bằng @Qualifier trên annotation khác.

Optional, collection và lazy

Muốn tiêm theo thứ tự, đánh @Order(n) trên từng bean — Spring sắp xếp collection theo đó.

Vì sao constructor injection tốt hơn

• Field có thể final → immutable, an toàn
• Dependency bắt buộc hiện rõ trong chữ ký
• Test bằng new OrderService(mock) không cần Spring
• Lỗi thiếu dependency nổ ngay lúc khởi động
• Tránh reflection và NPE của field injection

@Resource và @Inject (JSR)

Trong dự án Spring, cứ dùng @Autowired + constructor cho nhất quán; JSR annotation chỉ khi cần chuẩn chung với CDI.

Các scope

Web scope

Web scope cần proxy vì singleton (controller) tham chiếu tới bean ngắn hạn. Nếu không có proxy sẽ lỗi ngay lúc khởi tạo.

Singleton có thread-safe không?

• Singleton là 1 instance chia sẻ cho mọi thread
• Spring không tự đồng bộ — thread-safety là trách nhiệm của bạn
• Nguyên tắc: bean singleton nên stateless (không giữ state mutable)
• Có state → dùng scope ngắn hơn hoặc tự đồng bộ/immutable

Callback khởi tạo / hủy

Thứ tự chi tiết

1. Bean được instatiate (constructor)
2. Inject dependencies (field/setter)
3. Gọi các Aware interface (BeanNameAware, ApplicationContextAware…)
4. BeanPostProcessor.postProcessBeforeInitialization
5. @PostConstruct / afterPropertiesSet()
6. BeanPostProcessor.postProcessAfterInitialization
7. Bean sẵn sàng; khi shutdown → @PreDestroy / destroy()

Không gọi logic phụ thuộc dependency chưa inject trong constructor — để vào @PostConstruct.

BeanPostProcessor

Nếu muốn xử lý định nghĩa bean (trước khi instance tồn tại), dùng BeanFactoryPostProcessor — ví dụ PropertySourcesPlaceholderConfigurer xử lý ${...}.

Khi nào callback không chạy

• Prototype bean: @PreDestroy không được gọi tự động
• Dùng @Bean(initMethod=...) + @Component có cả hai → chạy cả hai
• Nhầm package javax.annotation (cũ) → callback bị bỏ qua âm thầm
• Bean lười (@Lazy) chỉ chạy init khi được dùng lần đầu

@Value và SpEL

${...} là property placeholder, #{...} là SpEL. Trộn được: #{'${app.env}' + '!'}.

Thứ tự ưu tiên properties

1. Command line arguments (--app.name=x)
2. SPRING_APPLICATION_JSON
3. Java System properties
4. OS environment variables
5. application-{profile}.yml
6. application.yml
7. @PropertySource / giá trị mặc định

(Đầy đủ nhất khi dùng Spring Boot; bản chất là các PropertySource xếp chồng, nguồn trên ghi đè nguồn dưới.)

@Profile

Kích hoạt: spring.profiles.active=dev hoặc --spring.profiles.active=dev; trong test dùng @ActiveProfiles("dev").

@Conditional

Spring Boot mở rộng: @ConditionalOnProperty, @ConditionalOnClass, @ConditionalOnMissingBean — nền tảng của auto-configuration.

Environment & PropertySource

• Environment = tập PropertySource + active profiles
• PropertySource: file yml/properties, system, env vars…
• Tiêm Environment env rồi env.getProperty("app.name")
• @PropertySource("classpath:custom.properties") thêm nguồn riêng

Spring xử lý bằng 3-level cache

Khi B cần A mà A chưa xong, Spring đưa tham chiếu sớm của A (level 3 → level 2) vào B. Vì vậy setter/field cycle mới tồn tại được.

Cách xử lý

Nên tránh

• Cycle là mùi thiết kế: hai class dính chặt vào nhau
• Spring Boot 2.6+ cấm circular reference mặc định
• Giải pháp đúng là cấu trúc lại: tách responsibility, đưa logic chung ra bean thứ ba
• @Lazy chỉ là phương án tình thế, không phải kiến trúc

Thuật ngữ AOP

Pointcut thường dùng

execution là linh hoạt nhất: return-type class.method(arguments); .. = bất kỳ tham số, * = bất kỳ tên.

@Transactional nhìn từ AOP

• @Transactional được xử lý bởi TransactionInterceptor — một Advice
• Mở tx trước method, commit/rollback sau — tất cả qua proxy
• Vì vậy self-invocation, method private, gọi trên new đều mất transaction
• Chi tiết propagation/isolation/rollback → xem file Spring Data JPA & Hibernate

@TransactionalEventListener

• AFTER_COMMIT — phổ biến nhất (gửi mail, đẩy queue sau khi lưu xong)
• AFTER_ROLLBACK, BEFORE_COMMIT, AFTER_COMPLETION
• Nếu không có transaction, event bị bỏ qua (fallbackExecution=true để vẫn chạy)

Đồng bộ hay bất đồng bộ

• Mặc định: đồng bộ — cùng thread, cùng transaction với nơi publish
• Bất đồng bộ: thêm @Async + @EnableAsync
• Async listener chạy thread khác → không còn nằm trong transaction gốc
• Thứ tự nhiều listener cùng event: @Order

Khi nào nên dùng event

• Mở rộng hành vi mà không sửa code gốc (audit, thông báo, thống kê)
• Nới lỏng coupling giữa các module
• Tránh dùng cho luồng chính: event làm logic khó theo dõi, khó debug
• Không lạm dụng async event cho dữ liệu cần nhất quán tức thời

Setup context cho test

Dùng JUnit 5 + spring-test. @ContextConfiguration chỉ load đúng config bạn khai báo — nhanh hơn full context.

Mock bean

Context caching

• Spring cache context theo key: config class + profiles + properties…
• Các test dùng cùng key → dùng lại context → nhanh hơn nhiều
• Test làm “bẩn” context (đổi bean, đổi state) → @DirtiesContext để reset
• Context chỉ tạo lại khi key khác nhau

Tùy biến cho riêng test

Core vs Boot testing

Trong dự án Boot thực tế, bạn sẽ dùng @SpringBootTest là chủ yếu; mục này để phân biệt ranh giới khái niệm.

Nên

Tránh