Trong kỹ thuật phần mềm, các mẫu thiết kế (Design Patterns) đại diện cho những giải pháp chuẩn hóa cho các vấn đề phổ biến, giúp đội ngũ phát triển trao đổi kỹ thuật một cách chính xác và hiệu quả hơn. Ví dụ, khi nhắc đến việc sử dụng mẫu Decorator trong模块 I/O, lập trình viên có thể hình dung ngay cấu trúc code liên quan. Tuy nhiên, mục đích chính của hầu hết các mẫu thiết kế là tổ chức code chứ không phải tăng tốc độ thực thi.尽管如此，một số mẫu cụ thể như Proxy, Singleton, Flyweight hay Prototype có ảnh hưởng trực tiếp đến hiệu năng hệ thống.

Phân tích hiệu năng trong Dynamic Proxy

Spring Framework sử dụng rộng rãi mẫu Proxy, đặc biệt là thông qua CGLIB để tăng cường bytecode Java. Trong các dự án phức tạp, nhiều lớp AOP (Aspect-Oriented Programming) như kiểm tra quyền hạn, ghi log được áp dụng. Điều này tiện lợi cho việc phát triển nhưng đôi khi gây khó khăn cho việc xác định nguyên nhân gây chậm trễ nếu không nắm rõ cấu trúc project.

Sử dụng công cụ Arthas là một phương pháp hiệu quả để định vị điểm nghẽn hiệu năng trong các logic được proxy hóa mà không cần đọc sâu source code. Dưới đây là ví dụ minh họa quy trình này.

Đầu tiên, khởi tạo một Service đơn giản:

@Service
public class PaymentProcessor {
    public void execute() {
        System.out.println("Processing payment...");
    }
}

Tiếp theo, định nghĩa một Aspect để mô phỏng độ trễ trong phương thức trước khi thực thi logic chính:

@Aspect
@Component
public class PerformanceMonitor {
    @Pointcut("execution(* com.example.service.PaymentProcessor.*(..))")
    public void monitorPoint() {}

    @Before("monitorPoint()")
    public void recordTime() {
        System.out.println("Start monitoring");
        try {
            Thread.sleep(500); // Giả lập độ trễ
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

Tạo một Controller để gọi service và đo thời gian phản hồi:

@RestController
public class PaymentController {
    @Autowired
    private PaymentProcessor processor;

    @GetMapping("/pay")
    public String process() {
        long start = System.currentTimeMillis();
        processor.execute();
        long duration = System.currentTimeMillis() - start;
        return processor.getClass().getName() + " | Time: " + duration + "ms";
    }
}

Khi truy cập endpoint, kết quả cho thấy đối tượng bean thực tế là một lớp proxy sinh bởi CGLIB và thời gian thực thi tăng lên đáng kể do logic trong Aspect. Để tìm chính xác phương thức nào gây tốn thời gian, ta sử dụng lệnh trace trong Arthas:

trace com.example.service.PaymentProcessor execute

Kết quả trace sẽ hiển thị chi tiết thời gian tiêu tốn tại từng bước, giúp xác định nhanh chóng các đoạn code AOP đang làm chậm hệ thống.

So sánh hiệu năng Proxy: JDK vs CGLIB

Java hỗ trợ hai cơ chế tạo proxy động chính: JDK Dynamic Proxy (dựa trên interface) và CGLIB (dựa trên kế thừa class). JDK Proxy sử dụng InvocationHandler, trong khi CGLIB sử dụng MethodInterceptor và Enhancer.

Các kiểm thử hiệu năng (benchmark) trên các phiên bản Java mới cho thấy sự chênh lệch tốc độ thực thi giữa hai phương thức này không quá lớn như các đồn đoán trước đây. Thậm chí, trong một số trường hợp, JDK Proxy còn có throughput cao hơn. Tuy nhiên, về tốc độ khởi tạo proxy, JDK thường vượt trội hơn so với CGLIB. Spring lựa chọn CGLIB chủ yếu vì khả năng proxy được các class thông thường không cần interface, chứ không phải vì lý do hiệu năng thuần túy.

Mẫu Singleton và vấn đề đồng thời

Trong Spring, scope mặc định của bean là singleton, nghĩa là chỉ có một instance duy nhất trong container. Khi triển khai singleton thủ công trong Java, cần lưu ý cơ chế加载 class của JVM. Các khối static và biến static được khởi tạo trong giai đoạn initialization của class, đảm bảo tính thread-safe.

Mô hình "Eager Initialization" (khởi tạo sớm) đơn giản nhưng có thể lãng phí tài nguyên nếu đối tượng không bao giờ được sử dụng. Để tối ưu, người ta thường dùng "Lazy Initialization" (khởi tạo lười). Tuy nhiên, việc này đòi hỏi xử lý đồng thread cẩn thận.

Mẫu Double-Checked Locking (DCL) từng rất phổ biến để đảm bảo hiệu năng và an toàn thread. Cơ chế này bao gồm:

• Kiểm tra instance null lần thứ nhất để tránh đồng bộ hóa không cần thiết.
• Sử dụng khóa synchronized trên class.
• Kiểm tra null lần thứ hai trong khối synchronized để đảm bảo chỉ một thread tạo instance.
• Sử dụng từ khóa volatile cho biến instance để ngăn chặn instruction reordering, đảm bảo đối tượng được khởi tạo hoàn chỉnh trước khi được truy cập bởi thread khác.

Mặc dù DCL thể hiện hiểu biết sâu về concurrency, nó khá phức tạp và dễ sai sót. Cách tiếp cận hiện đại và an toàn hơn là sử dụng Initialization-on-demand holder idiom:

public class ConfigManager {
    private ConfigManager() {}

    private static class Holder {
        private static final ConfigManager INSTANCE = new ConfigManager();
    }

    public static ConfigManager getInstance() {
        return Holder.INSTANCE;
    }
}

Cách này tận dụng cơ chế加载 class của JVM để đảm bảo thread-safe mà không cần synchronized hay volatile.

Mẫu Flyweight và tái sử dụng đối tượng

Flyweight là một trong số ít các mẫu thiết kế tập trung trực tiếp vào tối ưu hiệu năng thông qua việc chia sẻ đối tượng. Nguyên tắc cốt lõi là sử dụng một khóa duy nhất để xác định và trả về đối tượng đã tồn tại thay vì tạo mới, thường được lưu trữ trong các cấu trúc dữ liệu như HashMap.

Khái niệm này tương đồng với việc pool hóa đối tượng hoặc tái sử dụng các object lớn. Ranh giới giữa các mẫu thiết đôi khi khá mong manh. Ví dụ, một Map lưu trữ các đối tượng xử lý logic có thể được xem là Flyweight nếu mục đích là tiết kiệm bộ nhớ, nhưng cũng có thể được coi là Strategy Pattern nếu mục đích là thay đổi hành vi động dựa trên khóa.

Map<String, CommandHandler> registry = new ConcurrentHashMap<>();
registry.put("CREATE", new CreateCommand());
registry.put("DELETE", new DeleteCommand());

Việc phân loại phụ thuộc vào ngữ cảnh sử dụng và ý đồ thiết kế của lập trình viên.

Mẫu Prototype và thách thức khi sao chép

Mẫu Prototype dựa trên ý tưởng tạo đối tượng mới bằng cách sao chép một instance mẫu có sẵn. Trong Java, phương thức clone() của class Object là hiện thân điển hình của mẫu này. Tuy nhiên, việc sử dụng clone() trong thực tế hạn chế do cơ chế shallow copy (chỉ sao chép tham chiếu đối tượng con) mặc định của nó.

Để thực hiện deep copy (sao chép toàn bộ trạng thái đối tượng và các đối tượng con), lập trình viên phải ghi đè phương thức clone và xử lý thủ công từng trường dữ liệu, điều này phức tạp và dễ gây lỗi hơn so với việc gọi constructor mới. Các giải pháp thay thế cho deep copy bao gồm sử dụng cơ chế Serialization hoặc chuyển đổi đối tượng qua định dạng trung gian như JSON rồi khôi phục lại.

Do đó, trong phát triển hiện đại, Prototype thường được xem như một tư duy thiết kế về việc tái sử dụng trạng thái đối tượng hơn là một công cụ cụ thể để tăng tốc độ khởi tạo object.