Nhược điểm của quản lý bộ nhớ dựa trên phạm vi

Tôi thực sự thích quản lý bộ nhớ dựa trên phạm vi (SBMM), hoặc RAII , vì nó phổ biến hơn (gây nhầm lẫn?) Được đề cập bởi cộng đồng C ++. Theo như tôi biết, ngoại trừ C ++ (và C), ngày nay không có ngôn ngữ chính nào được sử dụng để biến SBMM / RAII thành cơ chế quản lý bộ nhớ chính của họ, và thay vào đó họ thích sử dụng bộ sưu tập rác (GC).

Tôi thấy điều này khá khó hiểu, vì

1. SBMM làm cho các chương trình mang tính quyết định hơn (bạn có thể biết chính xác khi nào một đối tượng bị phá hủy);
2. trong các ngôn ngữ sử dụng GC, bạn thường phải thực hiện quản lý tài nguyên thủ công (ví dụ, xem các tệp đóng trong Java), phần nào đánh bại mục đích của GC và cũng dễ bị lỗi;
3. bộ nhớ heap cũng có thể (rất thanh lịch, imo) bị giới hạn phạm vi (xem std::shared_ptrtrong C ++).

Tại sao SBMM không được sử dụng rộng rãi hơn? Nhược điểm của nó là gì?

Hãy bắt đầu bằng cách quy định rằng bộ nhớ là phổ biến (hàng chục, hàng trăm hoặc thậm chí hàng nghìn lần) phổ biến hơn tất cả các tài nguyên khác cộng lại. Mỗi biến, đối tượng, thành viên đối tượng cần một số bộ nhớ được cấp phát cho nó và giải phóng sau này. Đối với mỗi tệp bạn mở, bạn tạo hàng chục đến hàng triệu đối tượng để lưu trữ dữ liệu được rút ra khỏi tệp. Mỗi luồng TCP đi cùng với một số chuỗi byte tạm thời không giới hạn được tạo để ghi vào luồng. Có phải chúng ta trên cùng một trang ở đây? Tuyệt quá.

Để RAII hoạt động (ngay cả khi bạn có con trỏ thông minh đã sẵn sàng cho mọi trường hợp sử dụng dưới ánh mặt trời), bạn cần có quyền sở hữu . Bạn cần phân tích ai nên sở hữu đối tượng này hoặc đối tượng đó, ai không nên và khi nào nên chuyển quyền sở hữu từ A sang B. Chắc chắn, bạn có thể sử dụng quyền sở hữu chung cho mọi thứ , nhưng sau đó bạn sẽ mô phỏng một GC thông qua con trỏ thông minh. Tại thời điểm đó , việc xây dựng GC thành ngôn ngữ trở nên dễ dàng và nhanh chóng hơn nhiều .

Bộ sưu tập rác giải phóng bạn khỏi mối quan tâm này đối với tài nguyên, bộ nhớ được sử dụng phổ biến nhất. Chắc chắn, bạn vẫn cần đưa ra quyết định tương tự cho các tài nguyên khác, nhưng những tài nguyên đó ít phổ biến hơn (xem ở trên) và quyền sở hữu phức tạp (ví dụ như được chia sẻ) cũng ít phổ biến hơn. Gánh nặng tinh thần giảm đáng kể.

Bây giờ, bạn đặt tên cho một số nhược điểm để làm cho tất cả các giá trị rác được thu thập. Tuy nhiên, việc tích hợp cả hai loại giá trị và an toàn bộ nhớ với RAII vào một ngôn ngữ là vô cùng khó khăn, vì vậy có lẽ tốt hơn là nên số hóa các giao dịch này thông qua các phương tiện khác?

Sự mất đi tính quyết định hóa ra không phải là xấu trong thực tế, bởi vì nó chỉ ảnh hưởng đến tuổi thọ của đối tượng xác định . Như được mô tả trong đoạn tiếp theo, hầu hết các tài nguyên (ngoài bộ nhớ, rất dồi dào và có thể được tái chế khá lười biếng) không bị ràng buộc với tuổi thọ của đối tượng trong các ngôn ngữ này. Có một vài trường hợp sử dụng khác, nhưng chúng rất hiếm trong kinh nghiệm của tôi.

Điểm thứ hai của bạn, quản lý tài nguyên thủ công, hiện được xử lý thông qua một câu lệnh thực hiện dọn dẹp dựa trên phạm vi, nhưng không kết hợp việc này với thời gian sống của đối tượng (do đó không tương tác với an toàn bộ nhớ và bộ nhớ). Đây là usingtrong C #, withtrong Python, try-với tài nguyên trong các phiên bản Java gần đây.

RAII cũng xuất phát từ quản lý bộ nhớ đếm tham chiếu tự động, ví dụ như được sử dụng bởi Perl. Mặc dù việc đếm tham chiếu rất dễ thực hiện, có tính xác định và khá hiệu quả, nhưng nó không thể xử lý các tham chiếu vòng tròn (chúng gây rò rỉ), đó là lý do tại sao nó không được sử dụng phổ biến.

Các ngôn ngữ được thu gom rác không thể sử dụng RAII trực tiếp, nhưng thường cung cấp cú pháp với hiệu quả tương đương. Trong Java, chúng tôi có câu lệnh try-with-ressource

try (BufferedReader br = new BufferedReader(new FileReader(path))) { ... }

tự động gọi .close()tài nguyên trên khối thoát. C # có IDisposablegiao diện, cho phép .Dispose()được gọi khi để lại một using (...) { ... }câu lệnh. Python có withtuyên bố:

with open(filename) as f:
    ...

hoạt động theo cách tương tự. Trong một vòng quay thú vị về điều này, phương pháp mở tệp của Ruby nhận được một cuộc gọi lại. Sau khi gọi lại đã được thực hiện, tập tin được đóng lại.

File.open(name, mode) do |f|
    ...
end

Tôi nghĩ Node.js sử dụng cùng một chiến lược.

Theo tôi, ưu điểm thuyết phục nhất của bộ sưu tập rác là nó cho phép khả năng kết hợp . Tính đúng đắn của quản lý bộ nhớ là một thuộc tính cục bộ trong môi trường thu gom rác. Bạn có thể xem xét từng phần một cách riêng biệt và xác định xem nó có thể rò rỉ bộ nhớ hay không. Kết hợp bất kỳ số lượng các bộ phận chính xác bộ nhớ và chúng vẫn đúng.

Khi bạn dựa vào số tham chiếu, bạn sẽ mất tài sản đó. Liệu ứng dụng của bạn có thể rò rỉ bộ nhớ trở thành một tài sản toàn cầu của toàn bộ ứng dụng hay không bằng cách tham chiếu. Mỗi tương tác mới giữa các bộ phận có khả năng sử dụng quyền sở hữu sai và phá vỡ quản lý bộ nhớ.

Nó có tác dụng rất rõ ràng đối với việc thiết kế các chương trình bằng các ngôn ngữ khác nhau. Các chương trình trong các ngôn ngữ GC có xu hướng nhiều hơn một chút các đối tượng có nhiều tương tác, trong khi trong các ngôn ngữ không có GC, người ta có xu hướng thích các phần có cấu trúc với các tương tác được kiểm soát chặt chẽ và hạn chế giữa chúng.

Đóng cửa là một tính năng thiết yếu của khá nhiều ngôn ngữ hiện đại. Chúng rất dễ thực hiện với GC và rất khó (mặc dù không phải là không thể) để có được quyền với RAII, vì một trong những tính năng chính của chúng là chúng cho phép bạn trừu tượng trong suốt vòng đời của các biến!

C ++ chỉ có họ 40 năm sau khi mọi người khác làm, và phải mất rất nhiều công sức của rất nhiều người thông minh để làm cho họ đúng. Ngược lại, nhiều ngôn ngữ kịch bản được thiết kế và triển khai bởi những người không có kiến ​​thức về thiết kế và triển khai ngôn ngữ lập trình có chúng.

1. SBMM làm cho các chương trình mang tính quyết định hơn (bạn có thể biết chính xác khi nào một đối tượng bị phá hủy);

Đối với hầu hết các lập trình viên, HĐH là không xác định, cấp phát bộ nhớ của họ là không xác định và hầu hết các chương trình họ viết là đồng thời và do đó, vốn không mang tính quyết định. Thêm các ràng buộc rằng một hàm hủy được gọi chính xác ở cuối phạm vi thay vì hơi trước hoặc sau một chút không phải là một lợi ích thực tế đáng kể cho đại đa số các lập trình viên.

2. trong các ngôn ngữ sử dụng GC, bạn thường phải thực hiện quản lý tài nguyên thủ công (ví dụ, xem các tệp đóng trong Java), phần nào đánh bại mục đích của GC và cũng dễ bị lỗi;

Xem usingtrong C # và usetrong F #.

3. bộ nhớ heap cũng có thể (rất thanh lịch, imo) bị giới hạn phạm vi (xem std :: shared_ptr trong C ++).

Nói cách khác, bạn có thể lấy một đống là một giải pháp cho mục đích chung và thay đổi nó thành chỉ hoạt động trong một trường hợp cụ thể bị hạn chế nghiêm trọng. Đó là sự thật, tất nhiên, nhưng vô dụng.

Tại sao SBMM không được sử dụng rộng rãi hơn? Nhược điểm của nó là gì?

SBMM giới hạn những gì bạn có thể làm:

1. SBMM tạo ra vấn đề thú vị đi lên với các lần đóng từ vựng hạng nhất, đó là lý do tại sao các lần đóng là phổ biến và dễ sử dụng trong các ngôn ngữ như C # nhưng hiếm và khó trong C ++. Lưu ý rằng có một xu hướng chung đối với việc sử dụng các cấu trúc chức năng trong lập trình.

2. SBMM yêu cầu các hàm hủy và chúng cản trở các cuộc gọi đuôi bằng cách thêm nhiều việc phải làm trước khi một chức năng có thể trở lại. Các cuộc gọi đuôi rất hữu ích cho các máy trạng thái mở rộng và được cung cấp bởi những thứ như .NET.

3. Một số cấu trúc dữ liệu và thuật toán nổi tiếng là khó thực hiện khi sử dụng SBMM. Về cơ bản bất cứ nơi nào mà chu kỳ là tự nhiên. Đáng chú ý nhất là các thuật toán đồ thị. Bạn thực sự kết thúc việc viết GC của riêng bạn.

4. Lập trình đồng thời khó hơn vì dòng điều khiển và do đó, tuổi thọ đối tượng vốn không mang tính quyết định ở đây. Các giải pháp thực tế trong các hệ thống chuyển tin nhắn có xu hướng sao chép sâu các thông điệp và sử dụng tuổi thọ quá dài.

5. SBMM giữ cho các đối tượng tồn tại cho đến khi kết thúc phạm vi của chúng trong mã nguồn thường dài hơn mức cần thiết và có thể dài hơn mức cần thiết. Điều này làm tăng lượng rác trôi nổi (các vật thể không thể tiếp cận đang chờ tái chế). Ngược lại, truy tìm bộ sưu tập rác có xu hướng giải phóng các đối tượng ngay sau khi tham chiếu cuối cùng về chúng biến mất có thể sớm hơn nhiều. Xem huyền thoại quản lý bộ nhớ: nhanh chóng .

SBMM hạn chế đến mức các lập trình viên cần một lối thoát cho các tình huống mà thời gian sống không thể được thực hiện để làm tổ. Trong C ++, shared_ptrcung cấp một lối thoát nhưng nó có thể chậm hơn ~ 10 lần so với truy tìm bộ sưu tập rác . Vì vậy, sử dụng SBMM thay vì GC sẽ khiến hầu hết mọi người sai lầm trong hầu hết thời gian. Tuy nhiên, điều đó không có nghĩa là nó vô dụng. SBMM vẫn có giá trị trong bối cảnh các hệ thống và lập trình nhúng nơi tài nguyên bị hạn chế.

FWIW bạn có thể muốn xem Forth và Ada, và đọc về tác phẩm của Nicolas Wirth.

Nhìn vào một số chỉ số phổ biến như TIOBE (tất nhiên là có thể tranh cãi, nhưng tôi đoán đối với loại câu hỏi của bạn có thể sử dụng câu hỏi này), trước tiên bạn thấy rằng ~ 50% trong số 20 ngôn ngữ hàng đầu là "ngôn ngữ kịch bản" hoặc "phương ngữ SQL ", Trong đó" dễ sử dụng "và phương tiện trừu tượng có tầm quan trọng hơn nhiều so với hành vi xác định. Từ các ngôn ngữ "được biên dịch" còn lại, có khoảng 50% ngôn ngữ có SBMM và ~ 50% không có ngôn ngữ. Vì vậy, khi lấy các ngôn ngữ kịch bản ra khỏi tính toán của bạn, tôi sẽ nói rằng giả định của bạn là sai, trong số các ngôn ngữ được biên dịch, các ngôn ngữ có SBMM phổ biến như các ngôn ngữ không có.

Một lợi thế lớn của hệ thống GC mà chưa ai đề cập đến là tham chiếu trong hệ thống GC được đảm bảo giữ nguyên danh tính của nó miễn là nó tồn tại . Nếu một cuộc gọi IDisposable.Dispose(.NET) hoặc AutoCloseable.Close(Java) trên một đối tượng trong khi các bản sao của tham chiếu tồn tại, các bản sao đó sẽ tiếp tục tham chiếu đến cùng một đối tượng. Đối tượng sẽ không còn hữu ích cho bất cứ điều gì nữa, nhưng cố gắng sử dụng nó sẽ có hành vi dự đoán được kiểm soát bởi chính đối tượng. Ngược lại, trong C ++, nếu mã gọi deletevào một đối tượng và sau đó cố gắng sử dụng nó, toàn bộ trạng thái của hệ thống sẽ hoàn toàn không được xác định.

Một điều quan trọng khác cần lưu ý là quản lý bộ nhớ dựa trên phạm vi hoạt động rất tốt cho các đối tượng có quyền sở hữu được xác định rõ ràng. Nó hoạt động kém hơn nhiều, và đôi khi hết sức tệ hại, với các đối tượng không có quyền sở hữu được xác định. Nói chung, các đối tượng có thể thay đổi nên có chủ sở hữu, trong khi các đối tượng không thay đổi thì không cần, nhưng có một nếp nhăn: việc sử dụng mã của một loại biến đổi để giữ dữ liệu bất biến là rất phổ biến, bằng cách đảm bảo rằng không có tham chiếu nào được hiển thị mã có thể làm thay đổi thể hiện. Trong kịch bản như vậy, các thể hiện của lớp có thể thay đổi có thể được chia sẻ giữa nhiều đối tượng bất biến và do đó không có quyền sở hữu rõ ràng.

Trước hết, điều rất quan trọng để nhận ra rằng việc đánh đồng RAII với SBMM. hoặc thậm chí đến SBRM. Một trong những phẩm chất cần thiết nhất (và ít được biết đến nhất hoặc được đánh giá cao nhất) của RAII là thực tế rằng nó làm cho 'trở thành một tài nguyên' trở thành một tài sản KHÔNG chuyển tiếp thành phần.

Bài đăng trên blog sau đây thảo luận về khía cạnh quan trọng này của RAII và đối chiếu nó với sự thay đổi tài nguyên trong các ngôn ngữ của GC sử dụng GC không xác định.

http://minorfs.wordpress.com/2011/04/29/why-garbage-collection-is-anti-productive/

Điều quan trọng cần lưu ý là mặc dù RAII chủ yếu được sử dụng trong C ++, Python (cuối cùng là phiên bản không dựa trên VM) có các hàm hủy và GC xác định cho phép RAII được sử dụng cùng với GC. Tốt nhất của cả hai thế giới nếu nó là.