Ở bài viết trước chúng ta biết về khái niệm quyền sở hữu trong Rust. Nhờ có nó, Rust biết khi nào một biến là không dùng nữa và giải phóng giá trị khỏi bộ nhớ. Bằng cách sử dụng &
trước tên biến, chúng ta khai báo với Rust rằng chỉ “mượn” tạm giá trị mà không chuyển quyền sở hữu nên biến được mượn vẫn tồn tại sau khi mượn, chỉ có điều nó mất đi một số quyền.
Bài viết ngày hôm nay sẽ đi sâu vào cách Rust hoạt động với hành vi mượn dữ liệu. Làm thế nào để nó ngăn chặn được hành vi “không chuẩn mực” với dữ liệu được mượn và bị mượn trong thời gian biên dịch chứ không phải là thời gian chạy (runtime).
Đầu tiên hãy xem qua cách mà Rust xử lý bộ nhớ trong chương trình này.
let mut v: Vec<i32> = vec![1, 2, 3];
v.push(4);
Tại L2, hành động thêm một phần tử vào một danh sách đã gây nên đột biến, nhưng thay vì thêm 4
vào ô nhớ tiếp theo thì Rust đã sao chép toàn bộ dữ liệu sang một vùng nhớ khác, điều đó khiến cho dữ liệu tại heap của v
tại L1 đã bị giải phóng, v
lúc này trỏ đến một ô nhớ khác.
Nếu như vậy thì điều gì sẽ xảy ra với chương trình dưới đây.
let mut v: Vec<i32> = vec![1, 2, 3];
let num: &i32 = &v[2];
v.push(4);
println!("Third element is {}", *num);
Chúng ta thấy num
đang mượn giá trị tại vị trí thứ 2 của v
thông qua cách gọi &v[2]
. Nhưng sau hành động push
, giá trị heap của v
ban đầu đã bị hủy bỏ, vậy thì num
lúc này trỏ đến đâu? Bạn nghĩ đúng rồi đấy, chương trình trên báo lỗi.
Do đó, Rust phát biểu nguyên tắc an toàn của con trỏ: Dữ liệu không bao giờ được đặt bí danh (vay mượn) và thay đổi cùng một lúc.
Vì sinh ra cơ chế vay mượn, cho nên Rust cần tạo nên các quy tắc để đảm bảo "Nguyên tắc an toàn của con trỏ", đó chính là công cụ kiểm tra vay mượn (borrow checker).
Ý tưởng cốt lõi Rust sinh ra loại 3 quyền sở hữu dữ liệu của một biến.
Các quyền này chỉ tồn tại tại thời điểm biên dịch, tức là trình biên dịch "tự biên tự diễn" ra các quyền này để kiểm tra trương trình của bạn có hợp lệ hay không trước khi build thành binary.
Mặc định một biến có các quyền R, O trên dữ liệu của nó. Nếu một biến khai báo với mut
, nó sẽ có thêm quyền W.
Hãy xem xét cách Rust kiểm tra quyền dữ liệu của biến trong chương trình sau.
Đầu tiên, v
được khai báo với mut
nên nó có 3 quyền R, O, W. Sau đó num
mượn giá trị của v
, lúc này v
bị mất 2 quyền W, O, bù lại num
có quyền R, O trên dữ liệu mà nó mới mượn được. *num
là biến đọc giá trị tại nơi vay mượn, nó chỉ có quyền R.
Ngay sau lệnh println!
, num
được giải phóng do đó v
được khôi phục lại tất cả các quyền còn num
và *num
mất hết quyền trên dữ liệu mà nó mượn.
Sau lệnh push
, v không còn được dùng nữa cho nên nó cũng mất hết quyền trên dữ liệu của nó.
Rust gọi tất cả thứ nằm bên trái của phép gán (=) là paths
. Từ đó, quyền sở hữu dữ liệu được xác định trên paths
chứ không đơn thuần là trên các biến nữa. paths
bao gồm:
a
.*a
.a[0]
.a.0
của Tuble hoặc a.field
của Structs.*((*a)[0].1)
!?Vậy thì một biến mượn dữ liệu của biến khác, nó có thay đổi được dữ liệu đó không? Hãy nhớ lại khái niệm: “Dữ liệu không bao giờ được đặt bí danh (vay mượn) và thay đổi cùng một lúc”, tức là chỉ 1 trong 2 được phép xảy ra cùng một lúc.
let mut v: Vec<i32> = vec![1, 2, 3];
let num: &mut i32 = &mut v[2];
*num += 1;
println!("Third element is {}", *num);
println!("Vector is now {:?}", v);
Thay vì &v[2]
, giờ đây chúng ta khai báo &mut v[2]
để thông báo rằng num
có quyền O với dữ liệu nó mượn. Biến *num
đọc thẳng dữ liệu trong heap và tăng nó lên 1. Đến cuối cùng, v
cũng bị thay đổi theo num
.
So với ví dụ ban đầu, v
bị mất hoàn toàn tất cả quyền khi num
mượn một dữ liệu có quyền O. Điều này đảm bảo an toàn dữ liệu và tuân thủ nguyên tắc “Dữ liệu không bao giờ được đặt bí danh (vay mượn) và thay đổi cùng một lúc”.
Hãy bắt đầu với một ví dụ:
let s = String::from("Hello world");
let s_ref = &s;
drop(s);
println!("{}", s_ref);
Đoạn mã trên đang cố gắng xóa s
trong khi s_ref
thì đang mượn giá trị của s
. Nhớ lại kiến thức ở trên, s
lúc này tạm thời bị mất quyền O cho nên drop
không làm gì được vì nó yêu cầu phải có quyền O mới được phép. Chính vì thế chương trình trên báo lỗi.
Chúng ta, cũng như Rust có thể nhận biết được thời gian tồn tại của s
bằng mắt thường một cách nhanh chóng, tuy nhiên, chương trình không phải lúc nào cũng đơn giản, buộc Rust phải có cách nhận biết được thời gian tồn tại đủ lâu của một biến trong chương trình để tránh trường hợp như trên.
Hãy xem xét ví một hàm này.
fn first_or(strings: &Vec<String>, default: &String) -> &String {
if strings.len() > 0 {
&strings[0]
} else {
default
}
}
Hàm có thể trả về String
đầu tiên của tham số strings
hoặc cũng có thể trả về tham số default
. Sẽ ra sao nếu như chúng ta gọi hàm như thế này.
fn main() {
let strings = vec![];
let default = String::from("default");
let s = first_or(&strings, &default);
drop(default);
println!("{}", s);
}
strings
là rỗng, nên s
bằng tham chiếu của default
, tuy nhiên một lệnh drop(default)
được gọi trước khi in ra s
. Do đó chương trình này là không an toàn và nó bị lỗi.
Một ví dụ khác về chương trình không an toàn.
fn return_a_string() -> &String {
let s = String::from("Hello world");
let s_ref = &s;
s_ref
}
s_ref
đang cố gắng mượn giá trị của s
, tuy nhiên kết thúc hàm thì s
sẽ được giải phóng, việc trả về s_ref
lúc này là vô nghĩa vì thế chương trình trên báo lỗi.
Vậy là kết thúc bài viết nói về quyền sở hữu và cách Rust kiểm tra quyền vay mượn dữ liệu. Theo cảm nhận của tôi thì đây là phần khái niệm khó hiểu nhất của Rust, nhưng nó lại là khái niệm quan trọng nếu muốn viết và gỡ lỗi chương trình. Bạn đọc có thể tiếp tục đọc thêm bài viết Fixing Ownership Errors để biết cách sửa một số lỗi thường gặp với quyền sở hữu.
Xin chào, tôi tên là Hoài - một anh Dev kể chuyện bằng cách viết ✍️ và làm sản phẩm 🚀. Với nhiều năm kinh nghiệm lập trình, tôi đã đóng góp một phần công sức cho nhiều sản phẩm mang lại giá trị cho người dùng tại nơi đang làm việc, cũng như cho chính bản thân. Sở thích của tôi là đọc, viết, nghiên cứu... Tôi tạo ra trang Blog này với sứ mệnh mang đến những bài viết chất lượng cho độc giả của 2coffee.dev.Hãy theo dõi tôi qua các kênh LinkedIn, Facebook, Instagram, Telegram.
Bình luận (2)