Cấp phát tĩnh và nguyên tắc công việc không đổi: Cách TigerBeetle giải quyết bài toán an toàn bộ nhớ

Trong một bài viết mới trên blog cá nhân, kỹ sư phần mềm Matklad (tác giả của ngôn ngữ Zig và TigerBeetle) đã trình bày một góc nhìn độc đáo về vấn đề an toàn bộ nhớ — không phải từ góc độ ngôn ngữ lập trình, mà từ góc độ thiết kế hệ thống. Thay vì cố gắng theo dõi vòng đời từng đối tượng bằng công cụ phức tạp, ông đề xuất hai nguyên tắc đơn giản nhưng hiệu quả: cấp phát tĩnh hoàn toàn sau khi khởi tạo và đảm bảo khối lượng công việc không đổi bất kể tải hệ thống.

Vấn đề: use-after-free không chỉ là sự bất cẩn

Bài viết bắt đầu từ một email trao đổi về trường hợp một kỹ sư gặp lỗi use-after-free trong một matching engine xử lý lệnh giới hạn (limit-order). Điều thú vị là lỗi này không hoàn toàn do "bất cẩn với vòng đời" như anh ta nghĩ, mà đến từ một pool tái sử dụng bộ nhớ — nơi các đối tượng bị hủy được đưa vào danh sách chết, sau đó cấp phát lại cho đối tượng mới.

Về bản chất, một pool như vậy hoạt động giống như một union có thẻ (tagged union) — thẻ ở đây là "thế hệ đối tượng hiện đang sống trong slot này". Tuy nhiên, hệ thống kiểu (type system) không hề theo dõi thẻ này, dẫn đến khả năng đọc dữ liệu từ một con trỏ đã trở nên lỗi thời.

Sự khác biệt giữa type confusion và use-after-free logic

Điểm mấu chốt Matklad đưa ra là sự khác biệt về tác động vật lý của lỗi:

Nếu không dùng object pool, malloc/free thông thường sẽ biến lỗi use-after-free logic thành type confusion vật lý — dễ dẫn đến thực thi mã tùy ý. Khi hai đối tượng khác kiểu chia sẻ cùng vùng nhớ, một số nguyên do người dùng kiểm soát trong đối tượng này có thể là con trỏ hàm trong đối tượng kia.

Khi có pool tách theo kiểu (type-segregated pool), lỗi vẫn xảy ra nhưng không gây type confusion. Hành vi trở nên xác định và an toàn hơn — bạn nhận kết quả sai nhưng không bị lỗ hổng bảo mật nghiêm trọng.

Kỹ thuật này hoạt động tốt nếu hàm cấp phát của bạn có thông tin về kiểu (type witness), nhưng không áp dụng được cho C vì interface allocator của C không có kiểu. Tuy nhiên, nội dung trong bài viết nghiêng về cách tránh hoàn toàn các lỗi này bằng thiết kế.

Kỹ thuật 1: Cấp phát tĩnh — không cấp phát động sau khởi tạo

Nguyên tắc đầu tiên được lấy từ bài nói chuyện của TigerStyle:

Không cấp phát bộ nhớ động sau khi khởi tạo.

Thay vì tạo và hủy order liên tục, bạn xác định số lượng tối đa tại thời điểm khởi động:

const orders: []Order = try gpa.alloc(Order, cli_args.orders_max);

Nếu vượt quá giới hạn, yêu cầu dư thừa sẽ bị từ chối. Lập luận của những người phản đối: "Nhưng tôi còn bộ nhớ dư, tại sao không thử xử lý thêm?" — Matklad đáp lại:

Nếu hệ thống có "dung lượng" mà không có giới hạn cứng, khi quá tải nó sẽ thất bại thảm hại. Cố cấp phát thêm một Order có thể khiến OOM killer của kernel giết toàn bộ matching engine — mất đi một triệu order khác.

Cấp phát tĩnh mang lại sự an tâm: hệ thống có thể không khởi động nếu thiếu bộ nhớ, nhưng nếu khởi động được, nó sẽ xử lý quá tải một cách duyên dáng, tiếp tục phục vụ trong khi bạn chuẩn bị thêm tài nguyên.

Kỹ thuật 2: Công việc không đổi (Constant Work)

Thay vì duy trì danh sách riêng cho "order đang sống", bạn thiết kế để luôn có một số lượng cố định order, bằng cách thêm một order "trung lập" (no-op):

const Order = {
    id: u128,
    price: u32,
    count: u32,
    tag: enum { bid, ask, reserved },
    
    pub const reserved: Order = .{
        .id = 0,
        .price = 0,
        .count = 0,
        .tag = .reserved,
    };
};

Khởi tạo chỉ đơn giản là @memset(orders, .reserved).

Lợi ích nhận thức: Bạn không còn nghĩ về việc "tạo" và "hủy" order. Các order chỉ lưu thông trong hệ thống theo định luật bảo toàn số lượng. Việc theo dõi nguồn gốc và đích đến của từng order trở nên bắt buộc, giúp liệt kê đầy đủ các trạng thái chuyển tiếp và dễ dàng assert tính đúng đắn tại mọi thời điểm.

Lợi ích hiệu năng: Bạn không cần duy trì collection riêng cho "order sống". Luôn duyệt toàn bộ tập hợp, bỏ qua các order reserved. Thoạt nghe có vẻ lãng phí, nhưng hãy xem xét:

Nếu bạn cam kết phục vụ tối đa N order, liệu hệ thống có hiệu năng chấp nhận được khi đạt mức tối đa đó? Nếu không — đó là bug! Gray failure (hệ thống chậm đến mức không dùng được) là một cách khác để phá vỡ giới hạn.

Vòng lặp for (orders) |order| { process(order) } dễ dàng được compiler vector hóa và CPU cache prefetch hơn nhiều so với phiên bản dùng index:

for (orders_active) |order_index| {
    const order = orders[order_index];
    process(order);
}

Kết quả là độ trễ P100 phẳng bất kể tải — hiệu năng xấu nhất sẽ lộ ra khi bạn triển khai, không phải lúc 3 giờ sáng Black Friday.

Áp dụng trong thực tế: pattern trong code TigerBeetle

Tại TigerBeetle, nguyên tắc này được áp dụng ở quy mô nhỏ. Thay vì vòng lặp tìm kiếm với early return:

const item = for (items) |item| {
    if (predicate(item)) break item;
} else null;

Họ để vòng lặp chạy hết tự nhiên và thêm assert rằng chỉ có một phần tử khớp duy nhất.

Giới hạn và góc nhìn cân bằng

Matklad thừa nhận đây không phải giải pháp vạn năng. Nhưng như một kỹ thuật bổ sung vào kho vũ khí của lập trình viên hệ thống, nó đặc biệt hữu ích cho các hệ thống có vòng đời đối tượng phức tạp như matching engine, game server, database hay bất kỳ hệ thống nào yêu cầu độ trễ ổn định và an toàn bộ nhớ cao.

Bài học cho lập trình viên Việt Nam

Trong bối cảnh các startup Việt đang phát triển hệ thống giao dịch, fintech, và hạ tầng xử lý dữ liệu lớn, hai nguyên tắc này mang lại giá trị thực tiễn: chúng giúp giảm thiểu một lớp lỗi bảo mật nghiêm trọng mà vẫn giữ được hiệu năng dự đoán được. Khi tài nguyên hạn chế và lưu lượng tăng đột biến vào các dịp khuyến mãi hay sự kiện lớn, việc có một thiết kế "tự bảo vệ" — từ chối yêu cầu vượt quá khả năng một cách duyên dáng — đáng giá hơn nhiều so với việc cố xử lý tất cả rồi sụp đổ.