Tại sao thu gom 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ậy quan điểm của việc sử dụng bộ sưu tập rác là gì? Là nó làm một cái 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 điểm kỹ thuậ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?

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 hình thức 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 theo dõi 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ụ như máy chạy bộ của Baker.

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 việc thực hiện cụ thể và chi tiết cú pháp, GC / con trỏ thông minh 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 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ả các mã có thể sử dụng nó để tương tác. Tôi nghĩ, đây là lý do lớn khiến việc sử dụng lại mã và chia sẻ mã không thực sự phát huy 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ó thông qua 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ỏ, tài liệu tham khảo, consttoán tử hội thảo, toán tử gián tiếp, địa chỉ, v.v. Nếu bạn cuộn quản lý bộ nhớ vào 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 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 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 nó. Đ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à bộ 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.

Về cơ bản, bộ sưu tập rác chỉ có nghĩa là các đối tượng được phân bổ của bạn sẽ tự động được giải phóng 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 không thể truy cập được vào 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ập đến bất kỳ cấu trúc nào hoạt động như một con trỏ bình thường nhưng có một số chức năng bổ sung kèm theo. Chúng bao gồm nhưng không giới hạn ở việc phân bổ, mà còn sao chép khi viết, 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 thiết kế để trở 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 phát hành 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ó ý định thu gom rác. 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, pnó 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ờ điều duy nhất bạn có từ đầu là các 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à một 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ó lẽ sẽ không thể có 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 một .Dispose()số đối tượng nhất định). Các tài nguyên không được ước tính 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 tích hợp sâu vào ngôn ngữ hơn các con trỏ thông minh, được đặt lên trên ngôn ngữ, .NET GC có thể ví dụ trì hoãn các hoạt động của 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 các đối tượng được truy cập.

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ó.

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.

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 được 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 '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'

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 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 một 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.

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 có được một "phá vỡ" tham chiếu vòng tròn (ví dụ: sử dụng weak_ptrtrong 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 bài 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 mà chúng tham chiếu, 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à không thể truy cập A, B và C , 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.

Đó 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 để không phân bổ bộ nhớ, xem các chướng ngại vật . Phải chú ý, tôi không có kinh nghiệm với chướng ngại vật, tôi không bao giờ sử dụng chúng.

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 loạt hoạt động phân bổ lớn vào một lúc nào đó. Nếu GC không được thiết kế đúng, đ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 (không 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 điều gì đó mà khả năng phản hồi quan trọng, 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, vì vậy 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 làm việc xung quanh sự 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.

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ỏ mà 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.

Đó là một quang phổ .

Nếu bạn không kiểm soát chặt chẽ về hiệu suất và chuẩn bị đưa vào hoạt động, bạn sẽ kết thúc hội nghị 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 nó 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ó.

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 các 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ế.