it-swarm-vi.com

Tại sao Bộ sưu tập rác nếu con trỏ thông minh ở đó

Những ngày này, rất nhiều ngôn ngữ là rác được thu thập. Nó thậm chí còn có sẵn cho C++ bởi các bên thứ ba. Nhưng C++ có RAII và con trỏ thông minh. Vì vậy, điểm của việc sử dụng bộ sưu tập rác là gì? Có phải nó đang làm gì đó thêm?

Và trong các ngôn ngữ khác như C #, nếu tất cả các tham chiếu được coi là con trỏ thông minh (giữ RAII sang một bên), theo đặc tả và bằng cách thực hiện, liệu có còn cần người thu gom rác không? Nếu không, tại sao điều này không phải như vậy?

69
Gulshan

Vì vậy, quan điểm của việc sử dụng bộ sưu tập rác là gì?

Tôi giả sử bạn có nghĩa là tham chiếu đếm con trỏ thông minh và tôi sẽ lưu ý rằng chúng là một dạng thu gom rác (thô sơ) vì vậy tôi sẽ trả lời câu hỏi "lợi thế của các hình thức thu gom rác khác so với con trỏ thông minh được tham chiếu là gì" thay thế.

  • Độ chính xác. Tham chiếu đếm chu kỳ rò rỉ một mình vì vậy các con trỏ thông minh đếm tham chiếu sẽ nói chung rò rỉ bộ nhớ trừ khi các kỹ thuật khác được thêm vào chu kỳ bắt. Khi các kỹ thuật đó được thêm vào, lợi ích của tính đơn giản tham chiếu đã biến mất. Ngoài ra, lưu ý rằng việc đếm và theo dõi các tham chiếu dựa trên phạm vi thu thập các giá trị tại các thời điểm khác nhau, đôi khi việc đếm tham chiếu thu thập sớm hơn và đôi khi truy tìm các GC thu thập trước đó.

  • Thông lượng. Con trỏ thông minh là một trong những hình thức thu gom rác kém hiệu quả nhất, đặc biệt là trong bối cảnh các ứng dụng đa luồng khi số lượng tham chiếu bị va chạm nguyên tử. Có các kỹ thuật đếm tham chiếu nâng cao được thiết kế để giảm bớt điều này nhưng theo dõi các GC vẫn là thuật toán được lựa chọn trong môi trường sản xuất.

  • Độ trễ. Việc triển khai con trỏ thông minh điển hình cho phép các tàu khu trục xuất hiện, dẫn đến thời gian tạm dừng không giới hạn. Các hình thức thu gom rác khác gia tăng hơn nhiều và thậm chí có thể là thời gian thực, ví dụ: Máy chạy bộ của Baker.

71
Jon Harrop

Vì không ai nhìn nó từ góc độ này, tôi sẽ viết lại câu hỏi của bạn: tại sao lại đưa thứ gì đó vào ngôn ngữ nếu bạn có thể làm điều đó trong thư viện? Bỏ qua các chi tiết thực hiện và cú pháp cụ thể, GC/smart con trỏ về cơ bản là một trường hợp đặc biệt của câu hỏi đó. Tại sao định nghĩa trình thu gom rác bằng chính ngôn ngữ nếu bạn có thể triển khai nó trong thư viện?

Có một vài câu trả lời cho câu hỏi đó. Điều quan trọng nhất đầu tiên:

  1. Bạn đảm bảo rằng tất cả mã có thể sử dụng nó để tương tác. Đây là, tôi nghĩ, lý do lớn tại sao mã sử dụng lại và mã chia sẻ không thực sự cất cánh cho đến khi Java/C #/Python/Ruby. Các thư viện cần giao tiếp và ngôn ngữ chia sẻ đáng tin cậy duy nhất họ có là những gì trong chính ngôn ngữ đó (và, ở một mức độ nào đó, thư viện chuẩn của nó). Nếu bạn đã từng cố gắng sử dụng lại các thư viện trong C++, thì có khả năng bạn đã trải qua nỗi đau khủng khiếp mà không có ngữ nghĩa bộ nhớ tiêu chuẩn nào gây ra. Tôi muốn truyền một cấu trúc cho một số lib. Tôi có vượt qua một tài liệu tham khảo? Con trỏ? scoped_ptr? smart_ptr? Tôi có được quyền sở hữu hay không? Có cách nào để chỉ ra điều đó? Nếu lib cần phân bổ thì sao? Tôi có phải cung cấp cho nó một phân bổ? Bằng cách không biến quản lý bộ nhớ thành ngôn ngữ, C++ buộc mỗi cặp thư viện phải đàm phán chiến lược cụ thể của riêng họ ở đây và thật khó để khiến tất cả đồng ý. GC làm cho nó không thành vấn đề.

  2. Bạn có thể thiết kế cú pháp xung quanh nó. Vì C++ không tự đóng gói quản lý bộ nhớ, nên nó phải cung cấp một loạt các cú pháp cú pháp để cho phép mã cấp độ người dùng thể hiện tất cả các chi tiết. Bạn có con trỏ, tham chiếu, const, toán tử dereferences, toán tử gián tiếp, địa chỉ, v.v. Nếu bạn cuộn quản lý bộ nhớ vào chính ngôn ngữ, cú pháp có thể được thiết kế xung quanh đó. Tất cả các toán tử đó biến mất và ngôn ngữ trở nên sạch sẽ và đơn giản hơn.

  3. Bạn nhận được lợi tức đầu tư cao. Giá trị mà bất kỳ đoạn mã nào được tạo ra được nhân với số người sử dụng nó. Điều này có nghĩa là bạn càng có nhiều người dùng, bạn càng có đủ khả năng chi tiêu cho một phần mềm. Khi bạn di chuyển một tính năng sang ngôn ngữ, tất cả người dùng ngôn ngữ sẽ sử dụng ngôn ngữ đó. Điều này có nghĩa là bạn có thể phân bổ nhiều nỗ lực hơn nó cho một thư viện chỉ được sử dụng bởi một tập hợp con của những người dùng đó. Đây là lý do tại sao các ngôn ngữ như Java và C # hoàn toàn có máy ảo hạng nhất và trình thu gom rác chất lượng cao tuyệt vời: chi phí phát triển chúng được khấu hao trên hàng triệu người dùng.

66
munificent

Bộ sưu tập rác về cơ bản chỉ có nghĩa là các đối tượng được phân bổ của bạn sẽ tự động được phát hành tại một số điểm sau khi chúng không thể truy cập được nữa.

Chính xác hơn, chúng được phát hành khi chúng trở thành không thể truy cập cho chương trình, vì các đối tượng được tham chiếu theo vòng tròn sẽ không bao giờ được phát hành theo cách khác.

Con trỏ thông minh chỉ cần tham khảo bất kỳ cấu trúc nào hoạt động giống như một con trỏ thông thường nhưng có thêm một số chức năng bổ sung. Những bao gồm nhưng không giới hạn đối với giao dịch, mà còn sao chép trên ghi, kiểm tra ràng buộc, ...

Bây giờ, như bạn đã nói, con trỏ thông minh có thể được sử dụng để thực hiện một hình thức thu gom rác.

Nhưng đoàn tàu tư tưởng đi theo con đường sau:

  1. Bộ sưu tập rác là một thứ tuyệt vời để có, vì nó tiện lợi và tôi phải chăm sóc ít thứ hơn
  2. Do đó: Tôi muốn thu gom rác bằng ngôn ngữ của mình
  3. Bây giờ, làm thế nào có thể đưa GC vào ngôn ngữ của tôi?

Tất nhiên, bạn có thể thiết kế nó như thế này từ đầu. C # được được thiết kế thành rác được thu thập, vì vậy chỉ cần new đối tượng của bạn và nó sẽ được giải phóng khi các tham chiếu nằm ngoài phạm vi. Làm thế nào điều này được thực hiện là tùy thuộc vào trình biên dịch.

Nhưng trong C++, không có bộ sưu tập rác dự định. Nếu chúng ta phân bổ một số con trỏ int* p = new int; Và nó nằm ngoài phạm vi, p chính nó sẽ bị xóa khỏi ngăn xếp, nhưng không ai quan tâm đến bộ nhớ được phân bổ.

Bây giờ, thứ duy nhất bạn có từ đầu là hàm hủy xác định . Khi một đối tượng rời khỏi phạm vi mà nó đã được tạo, hàm hủy của nó được gọi. Kết hợp với các mẫu và nạp chồng toán tử, bạn có thể thiết kế một đối tượng trình bao bọc hoạt động giống như một con trỏ, nhưng sử dụng chức năng hủy để dọn sạch các tài nguyên được gắn vào nó (RAII). Bạn gọi đây là con trỏ thông minh .

Đây là tất cả đặc thù của C++: Quá tải toán tử, mẫu, hàm hủy, ... Trong tình huống ngôn ngữ cụ thể này, bạn đã phát triển các con trỏ thông minh để cung cấp cho bạn GC mà bạn muốn.

Nhưng nếu bạn thiết kế một ngôn ngữ với GC từ đầu, đây chỉ là một chi tiết triển khai. Bạn chỉ cần nói đối tượng sẽ được dọn sạch và trình biên dịch sẽ làm điều này cho bạn.

Các con trỏ thông minh như trong C++ có thể thậm chí không khả dụng trong các ngôn ngữ như C #, vốn không có sự phá hủy xác định nào cả (C # hoạt động xung quanh điều này bằng cách cung cấp đường cú pháp để gọi .Dispose() trên một số đối tượng nhất định). Các tài nguyên không được ước tính sẽ cuối cùng sẽ được thu hồi bởi GC, nhưng nó không được xác định khi nào chính xác điều này sẽ xảy ra.

Và điều này, đến lượt nó, có thể cho phép GC thực hiện công việc của mình hiệu quả hơn. Được xây dựng sâu hơn vào ngôn ngữ so với các con trỏ thông minh, được đặt lên trên nó, .NET GC có thể, ví dụ: trì hoãn các hoạt động bộ nhớ và thực hiện chúng trong các khối để làm cho chúng rẻ hơn hoặc thậm chí di chuyển bộ nhớ xung quanh để tăng hiệu quả dựa trên tần suất truy cập của các đối tượng.

36
Dario

Theo tôi, có hai sự khác biệt lớn, giữa bộ sưu tập rác và con trỏ thông minh được sử dụng để quản lý bộ nhớ:

  1. Con trỏ thông minh không thể thu gom rác theo chu kỳ; thu gom rác
  2. Con trỏ thông minh thực hiện tất cả các công việc tại các thời điểm tham chiếu, hội nghị và giao dịch, trên chuỗi ứng dụng; thu gom rác không cần

Điều này có nghĩa là GC sẽ thu gom rác mà con trỏ thông minh sẽ không; nếu bạn đang sử dụng con trỏ thông minh, bạn phải tránh tạo loại rác này hoặc sẵn sàng xử lý thủ công.

Điều thứ hai có nghĩa là cho dù con trỏ thông minh thông minh như thế nào, hoạt động của chúng sẽ làm chậm các luồng làm việc trong chương trình của bạn. Bộ sưu tập rác có thể trì hoãn công việc, và di chuyển nó đến các chủ đề khác; cho phép nó hoạt động tổng thể hiệu quả hơn (thực tế, chi phí thời gian chạy của một GC hiện đại ít hơn một hệ thống malloc/miễn phí bình thường, ngay cả khi không có thêm chi phí cho các con trỏ thông minh), và làm những gì nó vẫn cần làm mà không cần vào cách của các chủ đề ứng dụng.

Bây giờ, lưu ý rằng các con trỏ thông minh, là các cấu trúc lập trình, có thể được sử dụng để thực hiện tất cả các loại điều thú vị khác - xem câu trả lời của Dario - hoàn toàn nằm ngoài phạm vi thu gom rác. Nếu bạn muốn làm những điều đó, bạn sẽ cần con trỏ thông minh.

Tuy nhiên, với mục đích quản lý bộ nhớ, tôi không thấy bất kỳ triển vọng nào về con trỏ thông minh thay thế bộ sưu tập rác. Họ chỉ đơn giản là không giỏi về nó.

4
Tom Anderson

Thuật ngữ thu gom rác ngụ ý có bất kỳ rác để thu thập. Trong C++, con trỏ thông minh có nhiều hương vị, quan trọng nhất là unique_ptr. Unique_ptr về cơ bản là một cấu trúc sở hữu và phạm vi duy nhất. Trong một đoạn mã được thiết kế tốt, hầu hết các công cụ được phân bổ heap thường nằm sau các con trỏ thông minh unique_ptr và quyền sở hữu các tài nguyên đó sẽ luôn được xác định rõ. Hầu như không có bất kỳ chi phí nào trong unique_ptr và unique_ptr loại bỏ hầu hết các vấn đề quản lý bộ nhớ thủ công mà theo truyền thống đã đưa mọi người đến các ngôn ngữ được quản lý. Giờ đây, khi nhiều lõi chạy đồng thời đang trở nên phổ biến hơn, các nguyên tắc thiết kế hướng mã sử dụng quyền sở hữu duy nhất và được xác định rõ ràng tại bất kỳ thời điểm nào trở nên quan trọng hơn đối với hiệu suất. Việc sử dụng mô hình tính toán diễn viên cho phép xây dựng các chương trình với lượng trạng thái chia sẻ tối thiểu giữa các luồng và quyền sở hữu duy nhất đóng vai trò chính trong việc làm cho các hệ thống hiệu suất cao sử dụng hiệu quả nhiều lõi mà không cần sử dụng chung giữa dữ liệu chủ đề và các yêu cầu mutex ngụ ý.

Ngay cả trong một chương trình được thiết kế tốt, đặc biệt là trong môi trường đa luồng, không phải mọi thứ đều có thể được thể hiện mà không có cấu trúc dữ liệu chia sẻ và đối với những cấu trúc dữ liệu thực sự yêu cầu, các luồng cần phải giao tiếp. RAII trong c ++ hoạt động khá tốt đối với các mối quan tâm trọn đời trong một thiết lập luồng đơn, trong một thiết lập đa luồng, thời gian tồn tại của các đối tượng có thể không được xác định hoàn toàn theo thứ bậc. Đối với những tình huống này, việc sử dụng shared_ptr cung cấp một phần lớn của giải pháp. Bạn tạo quyền sở hữu chung cho một tài nguyên và điều này trong C++ là nơi duy nhất chúng ta thấy rác, nhưng với số lượng nhỏ như vậy, chương trình c ++ được thiết kế phù hợp nên được xem xét nhiều hơn để thực hiện bộ sưu tập 'xả rác với chia sẻ ptr so với thu gom rác đầy đủ như thực hiện bằng các ngôn ngữ khác. C++ đơn giản là không có nhiều 'rác' để thu thập.

Như đã nói bởi những người khác, con trỏ thông minh được tính tham chiếu là một dạng thu gom rác và đối với đó có một vấn đề chính. Ví dụ được sử dụng chủ yếu như nhược điểm của các hình thức thu gom rác được tham chiếu là vấn đề với việc tạo ra các cấu trúc dữ liệu mồ côi được kết nối với các con trỏ thông minh với nhau để tạo ra các cụm đối tượng không bị thu thập lẫn nhau. Mặc dù trong một chương trình được thiết kế theo mô hình tính toán của diễn viên, các cấu trúc dữ liệu thường không cho phép các cụm không thể thu được như vậy xuất hiện trong C++, khi bạn sử dụng phương pháp chia sẻ dữ liệu rộng rãi để lập trình đa luồng, như được sử dụng chủ yếu trong phần lớn của ngành công nghiệp, những cụm mồ côi này có thể nhanh chóng trở thành hiện thực.

Vì vậy, để tổng hợp tất cả, nếu sử dụng con trỏ dùng chung, bạn có nghĩa là việc sử dụng unique_ptr rộng rãi kết hợp với mô hình tiếp cận tính toán của lập trình cho lập trình đa luồng và sử dụng shared_ptr hạn chế, hơn các hình thức thu gom rác khác không mua cho bạn thêm lợi ích. Tuy nhiên, nếu cách tiếp cận mọi thứ được chia sẻ sẽ khiến bạn kết thúc với shared_ptr ở mọi nơi, thì bạn nên xem xét chuyển đổi mô hình đồng thời hoặc chuyển sang ngôn ngữ được quản lý theo hướng chia sẻ quyền sở hữu rộng hơn và truy cập đồng thời vào cấu trúc dữ liệu.

4
user1703394

Hầu hết các con trỏ thông minh được thực hiện bằng cách sử dụng đếm tham chiếu. Nghĩa là, mỗi con trỏ thông minh tham chiếu đến một đối tượng sẽ tăng số tham chiếu đối tượng. Khi số đó về 0, đối tượng được giải phóng.

Vấn đề là nếu bạn có tài liệu tham khảo tròn. Nghĩa là, A có tham chiếu đến B, B có tham chiếu đến C và C có tham chiếu đến A. Nếu bạn đang sử dụng con trỏ thông minh, thì để giải phóng bộ nhớ liên quan đến A, B & C, bạn cần phải thủ công vào trong đó "phá vỡ" tham chiếu vòng tròn (ví dụ: sử dụng weak_ptr trong C++).

Bộ sưu tập rác (thường) hoạt động khá khác nhau. Hầu hết những người thu gom rác ngày nay đều sử dụng kiểm tra khả năng tiếp cận. Đó là, nó xem xét tất cả các tham chiếu trên ngăn xếp và các tham chiếu có thể truy cập toàn cầu và sau đó theo dõi mọi đối tượng mà các tham chiếu đó tham chiếu và các đối tượng chúng tham khảo, v.v. Mọi thứ khác đều là rác .

Theo cách đó, các tham chiếu vòng tròn không còn quan trọng nữa - miễn là cả A, B và C đều không có thể truy cập, bộ nhớ có thể được lấy lại.

Có những lợi thế khác để thu gom rác "thực sự". Ví dụ, phân bổ bộ nhớ là cực kỳ rẻ: chỉ cần tăng con trỏ đến "kết thúc" của khối bộ nhớ. Giao dịch có chi phí khấu hao không đổi là tốt. Nhưng tất nhiên các ngôn ngữ như C++ cho phép bạn thực hiện quản lý bộ nhớ theo bất kỳ cách nào bạn muốn, do đó bạn có thể đưa ra một chiến lược phân bổ thậm chí còn nhanh hơn.

Tất nhiên, trong C++, lượng bộ nhớ được phân bổ heap thường ít hơn một ngôn ngữ nặng tham chiếu như C # /. NET. Nhưng đó không thực sự là vấn đề thu gom rác so với con trỏ thông minh.

Trong mọi trường hợp, vấn đề không phải là cắt và khô là tốt hơn so với vấn đề khác. Họ đều có ưu điểm và nhược điểm.

2
Dean Harding

Đó là về hiệu suất . Bộ nhớ unallocating đòi hỏi rất nhiều quản trị. Nếu unallocation chạy trong nền, hiệu suất của quá trình tiền cảnh tăng lên. Thật không may, phân bổ bộ nhớ không thể lười biếng (các đối tượng được phân bổ sẽ được sử dụng tại thời điểm tiếp theo thánh), nhưng việc giải phóng các đối tượng có thể.

Hãy thử trong C++ (w/o bất kỳ GC) để phân bổ một nhóm lớn các đối tượng, in "xin chào", sau đó xóa chúng. Bạn sẽ ngạc nhiên khi mất bao lâu để các đối tượng miễn phí.

Ngoài ra, GNU libc cung cấp các công cụ hiệu quả hơn để hủy phân bổ bộ nhớ, xem chướng ngại vật . Phải lưu ý, tôi không có kinh nghiệm với các chướng ngại vật, tôi chưa bao giờ sử dụng chúng.

2
ern0

Việc thu gom rác có thể hiệu quả hơn - về cơ bản là 'xử lý' chi phí quản lý bộ nhớ và thực hiện tất cả cùng một lúc. Nói chung, điều này sẽ dẫn đến việc CPU ít được sử dụng cho việc phân bổ bộ nhớ, nhưng điều đó có nghĩa là bạn sẽ có một sự bùng nổ lớn của hoạt động phân bổ lại tại một số điểm. Nếu GC không được thiết kế đúng cách, điều này có thể hiển thị cho người dùng dưới dạng 'tạm dừng' trong khi GC cố gắng phân bổ lại bộ nhớ. Hầu hết các GC hiện đại rất giỏi trong việc giữ điều này vô hình cho người dùng ngoại trừ trong các điều kiện bất lợi nhất.

Con trỏ thông minh (hoặc bất kỳ sơ đồ đếm tham chiếu nào) có lợi thế là chúng xảy ra chính xác khi bạn mong đợi khi xem mã (con trỏ thông minh nằm ngoài phạm vi, điều sẽ bị xóa). Bạn nhận được một chút bùng nổ của phân bổ ở đây và đó. Nhìn chung, bạn có thể sử dụng nhiều thời gian CPU hơn cho việc phân bổ lại, nhưng vì nó trải rộng trên tất cả những điều xảy ra trong chương trình của bạn, nên ít có khả năng (loại bỏ phân bổ cấu trúc dữ liệu quái vật) để hiển thị cho người dùng của bạn.

Nếu bạn đang làm một cái gì đó mà khả năng đáp ứng là vấn đề, tôi sẽ đề xuất rằng con trỏ/số đếm thông minh cho bạn biết chính xác khi nào mọi thứ đang xảy ra, để bạn có thể biết trong khi mã hóa những gì có khả năng hiển thị cho người dùng của bạn. Trong cài đặt GC, bạn chỉ có quyền kiểm soát nhanh nhất đối với trình thu gom rác và chỉ cần cố gắng xử lý mọi việc.

Mặt khác, nếu thông lượng tổng thể là mục tiêu của bạn, một hệ thống dựa trên GC có thể là lựa chọn tốt hơn nhiều, vì nó giảm thiểu các tài nguyên cần thiết để thực hiện quản lý bộ nhớ.

Chu kỳ: Tôi không coi vấn đề của chu kỳ là một vấn đề quan trọng. Trong một hệ thống mà bạn có con trỏ thông minh, bạn có xu hướng hướng đến các cấu trúc dữ liệu không có chu kỳ hoặc đơn giản là bạn cẩn thận về cách bạn từ bỏ những thứ đó. Nếu cần thiết, các đối tượng thủ môn biết cách phá vỡ các chu kỳ trong các đối tượng sở hữu có thể được sử dụng để tự động bảo đảm sự phá hủy thích hợp. Trong một số lĩnh vực lập trình, điều này có thể quan trọng, nhưng đối với hầu hết các công việc hàng ngày, điều đó không liên quan.

2
Michael Kohne

Hạn chế số một của con trỏ thông minh là chúng không luôn giúp chống lại các tham chiếu vòng tròn. Ví dụ: bạn có đối tượng A lưu trữ một con trỏ thông minh vào đối tượng B và đối tượng B đang lưu trữ một con trỏ thông minh vào đối tượng A. Nếu chúng được đặt lại với nhau mà không đặt lại một trong hai con trỏ chúng sẽ không bị hủy.

Điều này xảy ra bởi vì một con trỏ thông minh phải thực hiện một hành động cụ thể sẽ không được xem xét trong kịch bản trên vì cả hai đối tượng đều không thể truy cập được vào chương trình. Bộ sưu tập rác sẽ đối phó - nó sẽ xác định chính xác rằng các đối tượng không thể truy cập được vào chương trình và chúng sẽ được thu thập.

1
sharptooth

Đó là một quang phổ.

Nếu bạn không bị ràng buộc chặt chẽ về hiệu suất và sẵn sàng đưa Grind vào, bạn sẽ kết thúc tại hội hoặc c, với tất cả trách nhiệm để bạn đưa ra quyết định đúng đắn và tất cả tự do để làm điều đó, nhưng với nó , tất cả tự do để làm hỏng nó:

"Tôi sẽ cho bạn biết phải làm gì, bạn làm điều đó. Hãy tin tôi".

Thu gom rác là đầu kia của quang phổ. Bạn có rất ít quyền kiểm soát, nhưng nó được chăm sóc cho bạn:

"Tôi sẽ nói với bạn những gì tôi muốn, bạn thực hiện nó".

Điều này có rất nhiều lợi thế, chủ yếu là bạn không cần phải đáng tin khi biết chính xác khi nào tài nguyên không còn cần thiết nữa, nhưng (mặc dù một số câu trả lời trôi nổi ở đây) không tốt cho hiệu suất, và khả năng dự đoán của hiệu suất. (Giống như tất cả mọi thứ, nếu bạn được kiểm soát và làm điều gì đó ngu ngốc, bạn có thể có kết quả tồi tệ hơn. Tuy nhiên, để gợi ý rằng biết tại thời điểm biên dịch các điều kiện để có thể giải phóng bộ nhớ, không thể sử dụng làm chiến thắng hiệu suất là ngoài ngây thơ).

RAII, phạm vi, đếm ref, , v.v đều là những người trợ giúp cho bạn di chuyển xa hơn dọc theo quang phổ đó nhưng không phải là tất cả. Tất cả những điều này vẫn yêu cầu sử dụng tích cực. Họ vẫn cho phép và yêu cầu bạn tương tác với quản lý bộ nhớ theo cách mà bộ sưu tập rác không có.

1
drjpizzle

Xin nhớ rằng cuối cùng, mọi thứ đều sôi sục theo hướng dẫn thực thi CPU. Theo hiểu biết của tôi, tất cả các CPU cấp tiêu dùng đều có các tập lệnh yêu cầu bạn phải lưu trữ dữ liệu ở một vị trí nhất định trong bộ nhớ và bạn có con trỏ tới dữ liệu đã nói. Đó là tất cả những gì bạn có ở cấp độ cơ bản.

Tất cả mọi thứ trên hết với bộ sưu tập rác, tham chiếu đến dữ liệu có thể đã được di chuyển, nén heap, v.v. đang thực hiện công việc trong giới hạn được đưa ra bởi mô hình "bộ nhớ với con trỏ địa chỉ" ở trên. Điều tương tự với con trỏ thông minh - bạn VẪN phải làm cho mã chạy trên phần cứng thực tế.

0
user1249