An toàn bộ nhớ trong Zig

Khi các nhà phát triển thảo luận về an toàn bộ nhớ trong các hệ thống lập trình hiện đại, cuộc trò chuyện gần như luôn xoay quanh Rust và bộ kiểm tra mượn (borrow checker) nổi tiếng của nó. Rust cung cấp các đảm bảo tại thời điểm biên dịch giúp loại bỏ toàn bộ các lớp lỗi bộ nhớ, chẳng hạn như các lỗ hổng sử dụng sau khi giải phóng (use-after-free) và giải phóng hai lần (double-free). Tuy nhiên, Zig—một ngôn ngữ lập trình hệ thống tương đối mới, nhưng đang phát triển nhanh chóng—lại có một cách tiếp cận hoàn toàn khác để đạt được an toàn bộ nhớ. Thay vì dựa vào một hệ thống kiểu phức tạp và các quy tắc bí danh nghiêm ngặt tại thời điểm biên dịch, Zig nhấn mạnh việc cấp phát rõ ràng, công cụ hóa thời gian chạy và quyền kiểm soát của nhà phát triển. Bài đăng này khám phá các sắc thái kỹ thuật của an toàn bộ nhớ trong Zig, đối chiếu nó với các ngôn ngữ hệ thống khác và xem xét cách nó đạt được các đảm bảo an toàn mạnh mẽ thông qua sự kết hợp của các tính năng ngôn ngữ và công cụ.

Triết lý quản lý bộ nhớ rõ ràng

Triết lý cốt lõi của Zig là không có luồng điều khiển ẩn và không có cấp phát bộ nhớ ẩn. Không giống như C hoặc C++, nơi các hàm thư viện chuẩn thường cấp phát bộ nhớ một cách ngầm định bằng cách sử dụng malloc bên dưới, Zig yêu cầu lập trình viên phải truyền một bộ cấp phát (allocator) một cách rõ ràng cho bất kỳ hàm nào cần cấp phát bộ nhớ.

const std = @import("std");

pub fn main() !void {
    // We explicitly create an allocator
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();
    const allocator = gpa.allocator();

    // The allocator is passed as an argument
    var list = std.ArrayList(i32).init(allocator);
    defer list.deinit();

    try list.append(42);
}

Sự rõ ràng này buộc các nhà phát triển phải suy nghĩ về vòng đời của mọi đối tượng được cấp phát và giúp dễ dàng hoán đổi các bộ cấp phát cho các trường hợp sử dụng khác nhau. Trong bối cảnh an toàn bộ nhớ, điều này có nghĩa là việc sử dụng bộ nhớ được cục bộ hóa và minh bạch, giảm khả năng rò rỉ hoặc quản lý sai do hành vi thư viện không rõ ràng.

An toàn bộ nhớ không gian: Kiểm tra giới hạn và con trỏ

An toàn bộ nhớ không gian đề cập đến việc đảm bảo rằng một chương trình không truy cập bộ nhớ bên ngoài giới hạn của một đối tượng được cấp phát. Trong C, việc kiểm tra giới hạn mảng hầu như không tồn tại, dẫn đến các lỗ hổng tràn bộ đệm (buffer overflow) khét tiếng. Zig giải quyết vấn đề này thông qua việc kiểm tra giới hạn mạnh mẽ và một hệ thống con trỏ tinh tế hơn.

Trong Zig, các mảng và slice vốn dĩ biết độ dài của chúng. Khi bạn truy cập một phần tử của một slice, Zig thực hiện kiểm tra giới hạn. Trong các chế độ xây dựng Debug và ReleaseSafe, việc truy cập một chỉ mục ngoài giới hạn sẽ dẫn đến một lỗi panic được xử lý một cách xác định, thay vì hành vi không xác định (UB).

const array = [_]i32{ 1, 2, 3 };
// This will panic at runtime in Safe modes:
// const out_of_bounds = array[5]; 

Hơn nữa, Zig phân biệt giữa con trỏ một mục (*T), con trỏ nhiều mục ([*]T) và slice ([]T). Một con trỏ một mục không thể được sử dụng cho số học con trỏ. Nếu bạn cần lặp qua bộ nhớ, bạn phải sử dụng một slice, nó mang thông tin độ dài và cho phép các hoạt động được kiểm tra giới hạn. Lựa chọn thiết kế này hạn chế nghiêm ngặt khả năng xảy ra lỗi số học con trỏ, vốn là một nguồn chính gây ra các vi phạm bộ nhớ không gian trong C và C++.

An toàn bộ nhớ thời gian: GeneralPurposeAllocator

An toàn bộ nhớ thời gian đảm bảo rằng bộ nhớ không bị truy cập sau khi nó đã được giải phóng (use-after-free) và bộ nhớ không bị giải phóng nhiều lần (double-free). Rust giải quyết vấn đề này tại thời điểm biên dịch bằng cách theo dõi vòng đời. Zig dựa vào công cụ hóa thời gian chạy, chủ yếu thông qua GeneralPurposeAllocator (GPA) của nó.

GPA trong Zig không chỉ là một cơ chế để yêu cầu bộ nhớ từ hệ điều hành; nó là một công cụ gỡ lỗi mạnh mẽ. Khi chạy ở chế độ Debug, GPA theo dõi tất cả các cấp phát và giải phóng. Nó có thể phát hiện rò rỉ bộ nhớ khi hủy khởi tạo và, quan trọng hơn, nó có thể phát hiện lỗi use-after-free.

Khi bộ nhớ được giải phóng, GPA có thể "đầu độc" vùng bộ nhớ đó. Nếu một con trỏ lơ lửng sau đó được tham chiếu, bộ nhớ bị đầu độc sẽ gây ra một sự cố nghiêm trọng hoặc một lỗi có thể phát hiện được, thay vì âm thầm làm hỏng dữ liệu hoặc cho phép thực thi mã tùy ý. Hành vi "fail-fast" này rất quan trọng để xác định các lỗi bộ nhớ trong chu kỳ phát triển.

test "use after free detection" {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer std.testing.expect(gpa.deinit() == .ok) catch @panic("leak");
    const allocator = gpa.allocator();

    const ptr = try allocator.create(i32);
    ptr.* = 100;
    
    // Free the memory
    allocator.destroy(ptr);

    // This use-after-free will trigger a crash in Debug mode
    // ptr.* = 200; 
}

Vai trò của defer và errdefer

Quản lý tài nguyên trong Zig phụ thuộc nhiều vào các câu lệnh defer và errdefer. Các cấu trúc này đảm bảo rằng mã dọn dẹp được thực thi bất kể một khối mã thoát ra như thế nào, tương tự như RAII trong C++ nhưng không có ngữ nghĩa hủy ngầm.

Câu lệnh defer lên lịch một đoạn mã để chạy vào cuối phạm vi hiện tại. Điều này thường được sử dụng để giải phóng bộ nhớ hoặc giải phóng tài nguyên (ví dụ: đóng các file handle).

Câu lệnh errdefer thậm chí còn mạnh mẽ hơn cho việc xử lý lỗi. Nó lên lịch mã dọn dẹp để chạy chỉ khi khối hiện tại thoát ra với một lỗi. Điều này là vô giá khi xây dựng các đối tượng phức tạp yêu cầu nhiều cấp phát. Nếu một cấp phát sau đó thất bại, errdefer có thể dọn dẹp sạch sẽ đối tượng được xây dựng một phần, ngăn chặn rò rỉ bộ nhớ trong các đường dẫn lỗi.

pub fn createComplexObject(allocator: std.mem.Allocator) !*ComplexObject {
    const obj = try allocator.create(ComplexObject);
    errdefer allocator.destroy(obj);

    obj.buffer1 = try allocator.alloc(u8, 1024);
    errdefer allocator.free(obj.buffer1);

    // If this fails, buffer1 and obj will be cleanly freed
    obj.buffer2 = try allocator.alloc(u8, 2048);

    return obj;
}

Cách tiếp cận có cấu trúc này đối với quản lý tài nguyên làm giảm đáng kể gánh nặng nhận thức cho nhà phát triển và giảm thiểu rủi ro lỗi bộ nhớ thời gian do logic xử lý lỗi phức tạp.

Đánh đổi và con đường phía trước

Cách tiếp cận của Zig đối với an toàn bộ nhớ phụ thuộc nhiều vào kỷ luật của nhà phát triển trong việc sử dụng defer một cách chính xác và kiểm tra kỹ lưỡng mã trong các chế độ Debug hoặc ReleaseSafe. Nó không cung cấp các đảm bảo chặt chẽ, có thể chứng minh bằng toán học mà bộ kiểm tra mượn của Rust mang lại. Một nhà phát triển quyết tâm hoặc bất cẩn vẫn có thể viết một lỗi use-after-free trong Zig mà có thể lọt vào một bản dựng ReleaseFast (nơi các kiểm tra an toàn bị vô hiệu hóa để đạt hiệu suất).

Tuy nhiên, sự đánh đổi này đi kèm với những lợi thế rõ rệt. Đường cong học tập của Zig có thể nói là nông hơn Rust, vì các nhà phát triển không phải vật lộn với bộ kiểm tra mượn. Các cấu trúc dữ liệu nổi tiếng là khó triển khai trong Rust an toàn (như danh sách liên kết đôi hoặc đồ thị) lại dễ dàng triển khai trong Zig.

Hơn nữa, các bộ cấp phát rõ ràng của Zig mở ra cánh cửa cho các kỹ thuật quản lý bộ nhớ tiên tiến. Ví dụ, các bộ cấp phát arena có thể cấp phát một lượng lớn bộ nhớ cho một tác vụ cụ thể và giải phóng tất cả cùng một lúc bằng cách loại bỏ arena, hoàn toàn bỏ qua nhu cầu gọi destroy hoặc free riêng lẻ. Điều này loại bỏ các lỗi bộ nhớ thời gian trong ngữ cảnh của arena, vì các đối tượng riêng lẻ không bao giờ được giải phóng một cách rõ ràng.

Tóm lại, Zig cung cấp một cách tiếp cận thực dụng và hiệu quả cao đối với an toàn bộ nhớ. Bằng cách kết hợp cấp phát rõ ràng, kiểm tra thời gian chạy mạnh mẽ trong các bản dựng gỡ lỗi, an toàn không gian mạnh mẽ thông qua slice và quản lý tài nguyên sạch sẽ thông qua defer, Zig trao quyền cho các nhà phát triển viết mã hệ thống an toàn, hiệu suất cao mà không phải hy sinh quyền kiểm soát hoặc đối phó với các ràng buộc biên dịch phức tạp. Nó đại diện cho một lựa chọn thay thế hấp dẫn trong sự phát triển không ngừng của các ngôn ngữ lập trình hệ thống.

Bạn cũng có thể thích

• Biên dịch chương trình C với Make: Những điều tôi ước mình đã biết
• Các quy tắc bất thành văn của chương trình Terminal
• Tại sao các pipe đôi khi bị "kẹt": đệm
• SSH và SCP: Hai công cụ mà mọi nhà phát triển thực sự nên hiểu