Circular dependency — ba dạng vòng lặp và cơ chế three-level cache

TL;DR: Circular dependency xảy ra khi A cần B và B cần A. Spring giải được vòng lặp field/setter bằng three-level cache — ba map trong DefaultSingletonBeanRegistry: singletonObjects (instance hoàn chỉnh), earlySingletonObjects (instance chưa inject xong), singletonFactories (factory tạo early reference). Constructor circular không giải được vì bean chưa tồn tại để expose early reference trước khi constructor trả về. Spring Boot 2.6+ tắt tính năng giải vòng lặp mặc định — fix đúng là refactor hoặc dùng @Lazy.

Trong bài IoC & DI ta đã thấy ba dạng circular và cách fix bề mặt. Bài này đào sâu vào cơ chế bên dưới: Spring làm gì khi gặp A→B→A? Ba cái map nằm ở đâu trong heap? Tại sao constructor injection không hưởng lợi từ cơ chế đó? Hiểu cơ chế này là hiểu tại sao Spring Boot đổi default ở 2.6, và khi nào @Lazy thực sự an toàn.

1. Ba dạng circular dependency

Cùng một vòng A → B → A, nhưng cách inject quyết định Spring có giải được không:

2. Three-level cache — ba map trong DefaultSingletonBeanRegistry

Spring quản lý singleton qua ba map nằm trong DefaultSingletonBeanRegistry (superclass của DefaultListableBeanFactory, đã đề cập trong BeanFactory vs ApplicationContext):

DefaultSingletonBeanRegistry
  singletonObjects      : ConcurrentHashMap<String, Object>
      -- instance HOAN CHINH: da inject xong, lifecycle callback xong, san sang dung
  earlySingletonObjects : ConcurrentHashMap<String, Object>
      -- instance CHUA HOAN CHINH: constructor da chay, nhung chua inject dependency
  singletonFactories    : HashMap<String, ObjectFactory<?>>
      -- factory tao ra "early reference" (co the la AOP proxy) khi can

Đây là ba "tầng" của cache — mỗi tầng phục vụ một giai đoạn khác nhau trong vòng đời tạo bean:

Tại sao cần ba cấp thay vì một? Vì AOP proxy. Nếu A được wrap bởi AOP proxy (@Transactional, @Async), early reference phải là chính proxy đó, không phải raw object. singletonFactories giữ logic tạo proxy lười — chỉ gọi khi thực sự có circular request. Nếu không có circular, factory không bao giờ được gọi và earlySingletonObjects không bao giờ populated.

3. Cơ chế bên dưới — luồng giải vòng lặp field injection

Xét hai bean dùng field injection:

@Service
public class A {
    @Autowired private B b;
}

@Service
public class B {
    @Autowired private A a;
}

Luồng thực tế khi Spring khởi tạo (giả sử A được tạo trước) chính là bốn bước ở sơ đồ trên. Bước then chốt là bước 3: khi container đang tạo B và cần inject field a, nó gọi getSingleton("a"). Method này tra lần lượt L1 → L2 → L3. L1 chưa có (A chưa hoàn chỉnh), L2 chưa có (chưa ai hỏi A trước), L3 có ObjectFactory của A. Factory được gọi, trả về early reference của A (có thể là AOP proxy nếu A được proxy), đặt vào L2. B nhận được early reference này, inject xong, chuyển lên L1.

Sau đó container quay lại tiếp tục tạo A: inject field b = B đã hoàn chỉnh lấy từ L1. A hoàn chỉnh, xóa khỏi L2/L3, đặt vào L1.

4. Tại sao constructor injection không giải được circular

Với constructor injection:

@Service public class A { public A(B b) { /* ... */ } }
@Service public class B { public B(A a) { /* ... */ } }

Container cần tạo A nên gọi constructor A; constructor này cần B, container quay sang tạo B; constructor B lại cần A — nhưng A đang trong quá trình tạo và chưa có gì để trả lại.

Vấn đề nằm ở thứ tự: new A(b) đòi hỏi b phải tồn tại trước khi constructor A chạy. Constructor Java là nguyên tử — không có điểm nào giữa chừng để expose this ra ngoài (đó cũng là lý do this leak trong constructor là anti-pattern). Không có early reference thì không có gì để đặt vào singletonFactories — L3 trống, getSingleton("a") trả về null, và Spring không còn cách nào thoát vòng.

Chuỗi chết này là đúng cột trái của sơ đồ ở section 1. Spring phát hiện vòng bằng cách kiểm tra singletonsCurrentlyInCreation (một Set<String> track những bean đang được tạo). Khi container thử tạo A lần thứ hai trong khi A đang trong set này, nó throw ngay.

5. Spring Boot 2.6 thay đổi default

Trước Spring Boot 2.6, tính năng giải vòng lặp field/setter circular luôn bật. Từ Boot 2.6+, default là:

spring.main.allow-circular-references=false

Ý nghĩa: DefaultSingletonBeanRegistry sẽ không đặt ObjectFactory vào singletonFactories trong quá trình tạo bean. Nếu có circular — bất kể field hay setter — container throw ngay.

Lý do thay đổi: circular dependency là design smell, không phải feature nên tự động hỗ trợ. Cơ chế giải âm thầm che giấu vấn đề thiết kế, khiến developer không biết có vòng lặp cho đến khi gặp bug tinh tế. Tắt default buộc developer xử lý tường minh.

Bật lại bằng spring.main.allow-circular-references=true chỉ là band-aid — không nên làm trong code production mới.

6. Hai cách fix đúng

6.1 Refactor — tách logic chung sang class C

90% trường hợp circular dependency xảy ra vì hai class cùng cần một logic mà mỗi class giữ riêng. Giải pháp: extract logic đó ra class C.

// TRUOC: A can B, B can A -- circular
@Service
public class A {
    @Autowired private B b;
    public void processA() { b.sharedLogic(); }
}

@Service
public class B {
    @Autowired private A a;
    public void processB() { a.sharedLogic(); }
    public void sharedLogic() { /* ... */ }
}

// SAU: A va B cung can C -- khong circular
@Service
public class C {
    public void sharedLogic() { /* ... */ }   // extracted
}

@Service
public class A {
    private final C c;
    public A(C c) { this.c = c; }
    public void processA() { c.sharedLogic(); }
}

@Service
public class B {
    private final C c;
    public B(C c) { this.c = c; }
    public void processB() { c.sharedLogic(); }
}

Refactor không chỉ fix vòng lặp — nó cải thiện design: C bây giờ là module rõ ràng với trách nhiệm cụ thể.

6.2 @Lazy — phá vòng tại construction time

Khi refactor không khả thi ngay (code legacy, thời gian hạn chế), @Lazy là giải pháp hợp lý:

@Service
public class A {
    private final B b;

    public A(@Lazy B b) {
        this.b = b;   // b la CGLIB proxy, chua resolve B thuc su
    }

    public void doWork() {
        b.process();  // TAI DAY B thuc su moi duoc resolve lan dau
    }
}

@Service
public class B {
    private final A a;

    public B(A a) {
        this.a = a;
    }
}

@Lazy trên parameter constructor khiến Spring inject một CGLIB proxy thay vì bean B thực. Proxy không resolve B thực cho đến khi method đầu tiên được gọi trên nó. Điều này phá vòng tại construction time: A được tạo (với proxy), B được tạo (inject A thực), proxy của A trong B khi gọi method sẽ resolve B thực.

Trade-off của @Lazy:

• Method call đầu tiên trên proxy chậm hơn (resolve lazy).
• Overhead proxy nhỏ trên mọi lời gọi.
• Lỗi "bean không tồn tại" bị defer từ startup sang runtime.
• Code ít rõ ràng hơn — người đọc phải biết @Lazy có nghĩa gì.

Dùng @Lazy như bước trung gian trong khi refactor, không phải giải pháp cuối cùng.

7. Pitfall thường gặp

❌ Nhầm 1 — bật allow-circular-references=true để app start:

spring:
  main:
    allow-circular-references: true   # band-aid, che giau van de thiet ke

App start được nhưng thiết kế vẫn có vòng. Lần sau thêm @Transactional hoặc @Async vào một trong hai class, AOP proxy có thể gây bug tinh tế với early reference.

✅ Fix root: refactor tách class hoặc dùng @Lazy tường minh.

❌ Nhầm 2 — inject ApplicationContext để tránh circular (service locator):

@Service
public class A {
    @Autowired private ApplicationContext ctx;

    public void doWork() {
        B b = ctx.getBean(B.class);   // goi getBean runtime de tranh circular
        b.process();
    }
}

Đây là service locator anti-pattern, che giấu dependency, khó test. Circular vẫn tồn tại về mặt logic, chỉ bị defer sang runtime.

✅ Refactor hoặc @Lazy.

❌ Nhầm 3 — tưởng rằng circular field injection luôn an toàn vì app start được:

Trong constructor hoặc @PostConstruct của A, nếu bạn gọi method trên this.b — b có thể chưa được inject (chỉ là early reference chưa complete):

@Service
public class A {
    @Autowired private B b;

    @PostConstruct
    public void init() {
        b.process();   // AN TOAN: PostConstruct chay sau khi inject xong
    }

    public A() {
        // b.process();  // NGUY HIEM: b con null o day
    }
}

@PostConstruct chạy sau khi inject, nên b đã được set. Constructor thì b còn null.

8. Deep Dive — source Spring

Liên hệ các bài khác

• BeanFactory vs ApplicationContext: ba map singletonObjects, earlySingletonObjects, singletonFactories đều nằm trong DefaultListableBeanFactory (kế thừa từ DefaultSingletonBeanRegistry) — bài đó giải thích tại sao ApplicationContext compose DefaultListableBeanFactory thay vì kế thừa thẳng.
• Dependency Injection: ba dạng circular và ba cách fix ở cấp độ API — bài này là phần cơ chế bên dưới giải thích tại sao mỗi fix hoạt động.
• Bean lifecycle: @PostConstruct chạy sau inject hoàn chỉnh — liên quan trực tiếp đến pitfall "b vẫn null trong constructor" đã nêu ở mục 7; bài lifecycle mổ đầy đủ thứ tự các callback.

Tóm tắt

• Constructor circular: Spring không thể giải — throw BeanCurrentlyInCreationException tại startup. Đây là behavior tốt (fail fast).
• Field/setter circular: Spring giải bằng three-level cache trong DefaultSingletonBeanRegistry. Khi B đang tạo và cần A (đang được tạo), Spring lấy early reference của A từ singletonFactories (L3), cache vào earlySingletonObjects (L2), inject cho B. A hoàn chỉnh rồi mới vào singletonObjects (L1).
• Tại sao constructor không hưởng lợi: constructor Java không expose this trước khi trả về — không có điểm nào để đặt ObjectFactory vào L3.
• Spring Boot 2.6+ tắt tính năng giải vòng lặp mặc định — buộc developer fix tường minh.
• Fix đúng: refactor tách logic chung sang class C (90% case). @Lazy là band-aid hợp lý khi chưa refactor được.
• Bật allow-circular-references=true là che giấu design smell, không phải fix.

Tự kiểm tra

Bài tiếp theo: Tổng kết module