BeanDefinition & BFPP: Thao Tác Siêu Dữ Liệu Trước Khi Tạo Bean

TL;DR: Khi bạn khai báo @Component hay @Bean, Spring Container chưa khởi tạo đối tượng Java ngay lập tức. Thay vào đó, container ghi nhận một bản mô tả siêu dữ liệu mang tên BeanDefinition (lưu trữ class, scope, dependency) vào bảng băm beanDefinitionMap. Thực thể đối tượng chỉ được tạo ra ở bước 11 của refresh(). Trước thời điểm đó, BeanFactoryPostProcessor (BFPP) được phép đọc và biến đổi bản vẽ siêu dữ liệu này. Phân biệt rõ: BFPP can thiệp vào bản vẽ (metadata) trước khi tạo bean, còn BeanPostProcessor (BPP) can thiệp vào instance thật sau khi đối tượng đã ra đời.

Trong bài Vòng Đời Khởi Động: Giải Mã 12 Bước Trong Phương Thức refresh(), chúng ta đã biết giai đoạn 2 (bước 5–6) là cửa sổ duy nhất để tinh chỉnh container. Bài viết này sẽ mổ xẻ cấu trúc của BeanDefinition và cơ chế mà các BFPP can thiệp vào quá trình khởi tạo ứng dụng.

Hiện tượng cấu hình bean bị biến đổi bất thường bắt nguồn từ đâu?

Xét một tình huống thực tế: Bạn khai báo @Service trên lớp ReportService với scope mặc định là Singleton. Tuy nhiên, khi kiểm tra bằng thực nghiệm, mỗi lần gọi getBean("reportService") container lại trả về một instance hoàn toàn mới (hành vi giống hệt Prototype), dù trong mã nguồn không ai chỉnh sửa chú thích.

Nguyên nhân: Một BeanFactoryPostProcessor trong thư viện phụ trợ đã can thiệp vào beanDefinitionMap tại bước 5 của refresh() và gọi phương thức:

// Can thiep sua scope truc tiep tren ban ve thiet ke
def.setScope("prototype");

Đây là cơ chế hoàn toàn hợp lệ của Spring, chứng minh rằng: Các chú thích Java chỉ là dữ liệu đầu vào ban đầu, còn hành vi thực tế tại runtime phụ thuộc vào trạng thái cuối cùng của BeanDefinition sau khi đi qua chuỗi BFPP.

BeanDefinition đại diện cho những thông tin siêu dữ liệu nào?

BeanDefinition là một giao diện cốt lõi đóng gói toàn bộ thông số kỹ thuật mà container cần để tạo lập đối tượng:

// Minh hoa cac truong thong tin co ban trong BeanDefinition
BeanDefinition def = new RootBeanDefinition();
def.setBeanClassName("com.olhub.OrderService");
def.setScope("singleton");
def.setLazyInit(false);
def.getConstructorArgumentValues()
   .addGenericArgumentValue(new RuntimeBeanReference("paymentGateway"));

Các thuộc tính chủ chốt trong BeanDefinition:

BeanFactoryPostProcessor can thiệp vào siêu dữ liệu trước khi tạo bean ra sao?

BeanFactoryPostProcessor là một Functional Interface đơn giản:

@FunctionalInterface
public interface BeanFactoryPostProcessor {
    void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)
        throws BeansException;
}

Nhờ nhận tham số ConfigurableListableBeanFactory, BFPP có thể duyệt qua toàn bộ beanDefinitionMap và tinh chỉnh cấu hình:

@Component
public class ForceLazyBFPP implements BeanFactoryPostProcessor {
    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory bf) {
        for (String name : bf.getBeanDefinitionNames()) {
            BeanDefinition def = bf.getBeanDefinition(name);
            // Chi can thiep bean nghiep vu cua ung dung
            if (def.getRole() == BeanDefinition.ROLE_APPLICATION) {
                def.setLazyInit(true); // Ep moi bean ung dung thanh lazy
            }
        }
    }
}

Các BFPP nòng cốt trong Spring Framework:

• ConfigurationClassPostProcessor: Chạy đầu tiên ở bước 5, quét toàn bộ class @Configuration, phân tích các phương thức @Bean và sinh thêm BeanDefinition tương ứng vào map.
• PropertySourcesPlaceholderConfigurer: Quét các chuỗi ${...} trong @Value trên BeanDefinition và thay thế bằng giá trị thực tế lấy từ môi trường (Environment).

Phân biệt bản chất giữa BeanFactoryPostProcessor và BeanPostProcessor?

Mặc dù có tên gọi khá tương đồng, hai interface này hoạt động ở hai giai đoạn hoàn toàn khác biệt:

Tại sao việc tách biệt pha Metadata khỏi pha Instance là nền tảng của Autoconfig?

Nếu Spring tạo đối tượng ngay khi vừa quét thấy @Component trong classpath, framework sẽ không có cơ hội điều chỉnh hành vi nếu thiếu cấu hình hoặc thư viện bên ngoài.

Nhờ việc tách biệt quy trình làm 2 pha:

1. Pha 1 (Thu thập Metadata): Toàn bộ cấu hình được số hóa thành các đối tượng BeanDefinition.
2. Pha 2 (Biến đổi Metadata qua BFPP): Các starter của Spring Boot kích hoạt điều kiện @ConditionalOnClass, @ConditionalOnMissingBean để thêm bớt hoặc ghi đè BeanDefinition trước khi bước vào cấp phát bộ nhớ.

Nhờ đó, Spring Boot có thể tự động cấu hình HikariDataSource hay SecurityFilterChain mà không bắt buộc lập trình viên phải sửa đổi mã nguồn.

Bảng tra cứu lỗi nhanh liên quan đến BeanDefinition và PostProcessor?

Tóm tắt

• BeanDefinition là bản vẽ siêu dữ liệu trong beanDefinitionMap, hoàn toàn chưa phải là instance đối tượng trên heap.
• BeanFactoryPostProcessor chạy ở bước 5 của refresh() và can thiệp trực tiếp vào bản vẽ siêu dữ liệu.
• BeanPostProcessor chạy ở bước 11 để tiêm phụ thuộc @Autowired và bọc AOP Dynamic Proxy cho instance.
• Tách riêng siêu dữ liệu cho phép Spring Boot kiểm tra điều kiện và cấu hình tự động linh hoạt trước khi cấp phát bộ nhớ.

Tự kiểm tra

Bài tiếp theo: Environment & PropertySource: Cơ Chế Cấu Hình Đa Nguồn