Trong Java, ngay khi một đối tượng không còn bất kỳ tham chiếu nào nữa, nó sẽ trở thành đủ điều kiện để xóa, nhưng JVM quyết định khi nào đối tượng thực sự bị xóa. Để sử dụng thuật ngữ Objective-C, tất cả các tham chiếu Java vốn đã "mạnh". Tuy nhiên, trong Objective-C, nếu một đối tượng không còn tham chiếu mạnh nữa, đối tượng sẽ bị xóa ngay lập tức. Tại sao đây không phải là trường hợp trong Java?

Trước hết, Java có các tài liệu tham khảo yếu và một loại nỗ lực tốt nhất khác gọi là tài liệu tham khảo mềm. Tham chiếu yếu so với tham chiếu mạnh là một vấn đề hoàn toàn tách biệt với đếm tham chiếu so với thu gom rác.

Thứ hai, có những kiểu sử dụng bộ nhớ có thể giúp việc thu gom rác hiệu quả hơn theo thời gian bằng cách hy sinh không gian. Ví dụ, các đối tượng mới hơn có nhiều khả năng bị xóa hơn các đối tượng cũ hơn. Vì vậy, nếu bạn chờ một chút giữa các lần quét, bạn có thể xóa hầu hết thế hệ bộ nhớ mới, đồng thời chuyển một vài người sống sót sang lưu trữ lâu dài. Lưu trữ dài hạn có thể được quét ít thường xuyên hơn. Xóa ngay lập tức thông qua quản lý bộ nhớ thủ công hoặc đếm tham chiếu dễ bị phân mảnh hơn nhiều.

Nó giống như sự khác biệt giữa đi mua hàng tạp hóa một lần cho mỗi lần trả lương và mỗi ngày để có đủ thực phẩm cho một ngày. Một chuyến đi lớn của bạn sẽ mất nhiều thời gian hơn một chuyến đi nhỏ, nhưng nhìn chung bạn sẽ tiết kiệm được thời gian và tiền bạc.

Bởi vì biết chính xác một cái gì đó không còn được tham chiếu là không dễ dàng. Thậm chí không gần dễ dàng.

Nếu bạn có hai đối tượng tham chiếu lẫn nhau thì sao? Họ có ở lại mãi mãi không? Mở rộng dòng suy nghĩ đó để giải quyết bất kỳ cấu trúc dữ liệu tùy ý nào và bạn sẽ sớm thấy lý do tại sao JVM hoặc các công cụ thu gom rác khác buộc phải sử dụng các phương pháp tinh vi hơn để xác định những gì vẫn cần và những gì có thể đi.

AFAIK, đặc tả JVM (viết bằng tiếng Anh) không đề cập đến khi chính xác một đối tượng (hoặc một giá trị) nên bị xóa và để lại cho việc thực hiện (tương tự như vậy đối với R5RS ). Nó bằng cách nào đó yêu cầu hoặc đề xuất một trình thu gom rác nhưng để lại các chi tiết để thực hiện. Và tương tự như vậy đối với đặc tả Java.

Hãy nhớ rằng ngôn ngữ lập trình là thông số kỹ thuật (về cú pháp , ngữ nghĩa , v.v ...), không phải triển khai phần mềm. Một ngôn ngữ như Java (hoặc JVM của nó) có nhiều triển khai. Đặc điểm kỹ thuật của nó được xuất bản , có thể tải xuống (vì vậy bạn có thể nghiên cứu nó) và viết bằng tiếng Anh. §2,5.3 Heap của đặc tả JVM đề cập đến trình thu gom rác:

Lưu trữ heap cho các đối tượng được thu hồi bởi một hệ thống quản lý lưu trữ tự động (được gọi là bộ thu gom rác); các đối tượng không bao giờ được giải quyết rõ ràng. Máy ảo Java giả định không có loại hệ thống quản lý lưu trữ tự động cụ thể nào

(nhấn mạnh là của tôi; quyết toán BTW được đề cập trong §12.6 của thông số Java và một mô hình bộ nhớ nằm trong §17.4 của thông số Java)

Vì vậy (trong Java) bạn không nên quan tâm khi một đối tượng bị xóa và bạn có thể viết mã như - nếu điều đó không xảy ra (bằng cách suy luận một cách trừu tượng trong đó bạn bỏ qua điều đó). Tất nhiên bạn cần quan tâm đến việc tiêu thụ bộ nhớ và tập hợp các đối tượng sống, đó là một câu hỏi khác nhau . Trong một số trường hợp đơn giản (nghĩ về chương trình "xin chào thế giới"), bạn có thể chứng minh - hoặc tự thuyết phục bản thân - rằng bộ nhớ được phân bổ khá nhỏ (ví dụ: ít hơn một gigabyte), và sau đó bạn không quan tâm xóa các đối tượng riêng lẻ . Trong nhiều trường hợp hơn, bạn có thể thuyết phục bản thân rằng các vật thể sống(hoặc những người có thể tiếp cận, là một siêu thay đổi - lý do hơn là về những người sống) không bao giờ vượt quá giới hạn hợp lý (và sau đó bạn dựa vào GC, nhưng bạn không quan tâm đến việc thu gom rác diễn ra như thế nào và khi nào). Đọc về sự phức tạp không gian .

Tôi đoán rằng trên một số triển khai JVM chạy chương trình Java có thời gian ngắn như thế giới xin chào, trình thu gom rác hoàn toàn không được kích hoạt và không xảy ra xóa. AFAIU, một hành vi như vậy phù hợp với nhiều thông số kỹ thuật Java.

Hầu hết các triển khai JVM sử dụng các kỹ thuật sao chép thế hệ (ít nhất là đối với hầu hết các đối tượng Java, những đối tượng không sử dụng hoàn thiện hoặc tham chiếu yếu ; và hoàn thiện không được đảm bảo xảy ra trong một thời gian ngắn và có thể bị hoãn lại, vì vậy đây chỉ là một tính năng hữu ích mà mã của bạn không nên phụ thuộc nhiều vào) trong đó khái niệm xóa một đối tượng riêng lẻ không có ý nghĩa gì (vì một khối lớn các vùng nhớ chứa bộ nhớ cho nhiều đối tượng-, có thể vài megabyte cùng một lúc, được giải phóng cùng một lúc).

Nếu đặc tả JVM yêu cầu mỗi đối tượng phải được xóa chính xác càng sớm càng tốt (hoặc đơn giản là đặt nhiều ràng buộc hơn vào việc xóa đối tượng), các kỹ thuật GC thế hệ hiệu quả sẽ bị cấm và các nhà thiết kế Java và JVM đã khôn ngoan tránh điều đó.

BTW, có thể là một JVM ngây thơ không bao giờ xóa các đối tượng và không giải phóng bộ nhớ có thể phù hợp với thông số kỹ thuật (chữ cái, không phải tinh thần) và chắc chắn có thể chạy một điều thế giới xin chào trong thực tế (chú ý rằng hầu hết các chương trình Java nhỏ và ngắn có lẽ không phân bổ nhiều hơn một vài gigabyte bộ nhớ). Tất nhiên một JVM như vậy không đáng để đề cập và chỉ là một thứ đồ chơi (giống như việc triển khai nàymalloc cho C). Xem Epsilon NoOp GC để biết thêm. Các JVM ngoài đời thực là những phần mềm rất phức tạp và trộn lẫn một số kỹ thuật thu gom rác.

Ngoài ra, Java không giống như JVM và bạn có các triển khai Java đang chạy mà không có JVM (ví dụ: các trình biên dịch Java trước thời hạn , thời gian chạy Android ). Trong một số trường hợp (chủ yếu là học thuật), bạn có thể tưởng tượng (được gọi là kỹ thuật "thu gom rác thời gian biên dịch") rằng chương trình Java không phân bổ hoặc xóa trong thời gian chạy (ví dụ: vì trình biên dịch tối ưu hóa đủ thông minh để chỉ sử dụng gọi ngăn xếp và biến tự động ).

Tại sao các đối tượng Java không bị xóa ngay lập tức sau khi chúng không còn được tham chiếu?

Bởi vì các đặc tả Java và JVM không yêu cầu điều đó.

Đọc cẩm nang GC để biết thêm (và thông số JVM ). Lưu ý rằng việc tồn tại (hoặc hữu ích cho tính toán trong tương lai) cho một đối tượng là thuộc tính toàn chương trình (không phải mô-đun).

Objective-C ủng hộ cách tiếp cận đếm tham chiếu đến quản lý bộ nhớ . Và điều đó cũng có những cạm bẫy (ví dụ, lập trình viên Objective-C phải quan tâm đến các tham chiếu vòng tròn bằng cách khám phá các tham chiếu yếu, nhưng một JVM xử lý các tham chiếu vòng tròn độc đáo trong thực tế mà không cần sự chú ý từ lập trình viên Java).

Không có Silver Bullet trong lập trình và thiết kế ngôn ngữ lập trình (lưu ý vấn đề Ngừng ; nói chung là một đối tượng sống hữu ích là không thể giải quyết được ).

Bạn cũng có thể đọc SICP , Lập trình ngôn ngữ lập trình , Sách rồng , Lisp trong các mảnh nhỏ và hệ điều hành: Ba mảnh dễ dàng . Chúng không phải là về Java, nhưng chúng sẽ mở mang đầu óc của bạn và sẽ giúp hiểu được JVM nên làm gì và nó có thể hoạt động như thế nào (với các phần khác) trên máy tính của bạn. Bạn cũng có thể dành nhiều tháng (hoặc vài năm) để nghiên cứu mã nguồn phức tạp của các triển khai JVM nguồn mở hiện có (như OpenJDK , có vài triệu dòng mã nguồn).

Để sử dụng thuật ngữ Objective-C, tất cả các tham chiếu Java vốn đã "mạnh".

Điều đó không chính xác - Java có cả các tham chiếu yếu và mềm, mặc dù các tham chiếu này được triển khai ở cấp đối tượng thay vì từ khóa ngôn ngữ.

Trong Objective-C, nếu một đối tượng không còn tham chiếu mạnh nữa, đối tượng sẽ bị xóa ngay lập tức.

Điều đó cũng không hẳn đúng - một số phiên bản của Objective C thực sự đã sử dụng trình thu gom rác thế hệ. Các phiên bản khác không có bộ sưu tập rác nào cả.

Đúng là các phiên bản mới hơn của Objective C sử dụng tính năng tham chiếu tự động (ARC) thay vì GC dựa trên dấu vết và điều này (thường) dẫn đến việc đối tượng bị "xóa" khi số tham chiếu đó bằng không. Tuy nhiên, lưu ý rằng việc triển khai JVM cũng có thể được tuân thủ và hoạt động chính xác theo cách này (quái gì, nó có thể tuân thủ và không có GC nào cả.)

Vậy tại sao hầu hết các triển khai JVM không làm điều này và thay vào đó sử dụng các thuật toán GC dựa trên dấu vết?

Nói một cách đơn giản, ARC không phải là không tưởng như lúc đầu:

• Bạn phải tăng hoặc giảm số lượt truy cập mỗi khi tham chiếu được sao chép, sửa đổi hoặc đi ra khỏi phạm vi, điều này mang lại một chi phí hiệu năng rõ ràng.
• ARC không thể dễ dàng xóa các tham chiếu theo chu kỳ, vì tất cả chúng đều có tham chiếu với nhau, do đó, số tham chiếu của chúng không bao giờ bằng không.

Tất nhiên ARC có lợi thế - việc thực hiện và thu thập đơn giản mang tính quyết định. Nhưng những nhược điểm ở trên, trong số những thứ khác, là lý do phần lớn các triển khai JVM sẽ sử dụng một GC dựa trên thế hệ, theo dõi.

Java không xác định chính xác khi nào đối tượng được thu thập bởi vì điều đó cho phép triển khai tự do chọn cách xử lý bộ sưu tập rác.

Có nhiều cơ chế thu gom rác khác nhau, nhưng các cơ chế đảm bảo rằng bạn có thể thu thập một đối tượng ngay lập tức gần như hoàn toàn dựa trên việc đếm tham chiếu (tôi không biết về bất kỳ thuật toán nào phá vỡ xu hướng này). Đếm tham chiếu là một công cụ mạnh mẽ, nhưng nó có chi phí duy trì số tham chiếu. Trong mã singlethreaded, không có gì khác hơn là tăng và giảm, do đó, việc gán một con trỏ có thể tốn chi phí theo thứ tự gấp 3 lần mã được tham chiếu so với mã được tính không tham chiếu (nếu trình biên dịch có thể nướng mọi thứ xuống máy mã).

Trong mã đa luồng, chi phí cao hơn. Nó hoặc yêu cầu tăng / giảm nguyên tử hoặc khóa, cả hai đều có thể đắt tiền. Trên một bộ xử lý hiện đại, một hoạt động nguyên tử có thể đắt hơn 20 lần so với một hoạt động đăng ký đơn giản (rõ ràng thay đổi từ bộ xử lý đến bộ xử lý). Điều này có thể làm tăng chi phí.

Vì vậy, với điều này, chúng ta có thể xem xét sự đánh đổi được thực hiện bởi một số mô hình.

• Objective-C tập trung vào ARC - đếm tham chiếu tự động. Cách tiếp cận của họ là sử dụng tính tham khảo cho tất cả mọi thứ. Không có phát hiện chu kỳ (mà tôi biết), vì vậy các lập trình viên dự kiến ​​sẽ ngăn chặn các chu kỳ xảy ra, làm mất thời gian phát triển. Lý thuyết của họ là các con trỏ không được chỉ định thường xuyên và trình biên dịch của chúng có thể xác định các tình huống trong đó số lượng tham chiếu tăng / giảm không thể làm cho một đối tượng chết và loại bỏ hoàn toàn các mức tăng / giảm đó. Vì vậy, họ giảm thiểu chi phí đếm tham khảo.

• CPython sử dụng cơ chế lai. Họ sử dụng số lượng tham chiếu, nhưng họ cũng có một trình thu gom rác xác định các chu kỳ và giải phóng chúng. Điều này cung cấp lợi ích của cả hai thế giới, với chi phí của cả hai phương pháp. CPython phải duy trì số lượng tham chiếu vàlàm sổ sách để phát hiện chu kỳ. CPython thoát khỏi điều này theo hai cách. Cái nắm tay là CPython thực sự không đa luồng. Nó có một khóa được gọi là GIL giới hạn đa luồng. Điều này có nghĩa là CPython có thể sử dụng các mức tăng / giảm bình thường thay vì tăng nguyên tử, nhanh hơn nhiều. CPython cũng được hiểu, có nghĩa là các hoạt động như gán cho một biến đã có một số hướng dẫn thay vì chỉ 1. Chi phí bổ sung để thực hiện tăng / giảm, được thực hiện nhanh chóng trong mã C, ít xảy ra sự cố vì chúng tôi ' đã trả chi phí này.

• Java đi xuống cách tiếp cận không đảm bảo một hệ thống đếm tham chiếu nào cả. Thật vậy, đặc tả không nói gì về cách các đối tượng được quản lý ngoài việc sẽ có một hệ thống quản lý lưu trữ tự động. Tuy nhiên, đặc điểm kỹ thuật cũng gợi ý mạnh mẽ cho giả định rằng đây sẽ là rác được thu thập theo cách xử lý các chu kỳ. Bằng cách không chỉ định khi các đối tượng hết hạn, java có quyền tự do sử dụng các trình thu thập mà không lãng phí thời gian tăng / giảm thời gian. Thật vậy, các thuật toán thông minh như người thu gom rác thế hệ thậm chí có thể xử lý nhiều trường hợp đơn giản mà không cần nhìn vào dữ liệu đang được thu hồi (họ chỉ phải xem dữ liệu vẫn đang được tham chiếu).

Vì vậy, chúng ta có thể thấy cả ba người này đã phải đánh đổi. Sự đánh đổi nào là tốt nhất phụ thuộc rất lớn vào bản chất của cách sử dụng ngôn ngữ.

Mặc dù finalizeđược hỗ trợ dựa trên GC của Java, bộ sưu tập rác ở lõi của nó không quan tâm đến các vật thể chết, mà là những vật thể sống. Trên một số hệ thống GC (có thể bao gồm một số triển khai Java), điều duy nhất phân biệt một bó bit đại diện cho một đối tượng từ một kho lưu trữ không được sử dụng cho bất cứ điều gì có thể là sự tồn tại của các tham chiếu đến trước đây. Trong khi các đối tượng có bộ hoàn thiện được thêm vào một danh sách đặc biệt, các đối tượng khác có thể không có bất cứ nơi nào trong vũ trụ nói rằng bộ lưu trữ của chúng được liên kết với một đối tượng ngoại trừ các tham chiếu được giữ trong mã người dùng. Khi tham chiếu cuối cùng như vậy được ghi đè, mẫu bit trong bộ nhớ sẽ ngay lập tức không còn được nhận dạng như một đối tượng, cho dù có bất kỳ thứ gì trong vũ trụ nhận thức được điều đó hay không.

Mục đích của việc thu gom rác không phải là để tiêu diệt các đối tượng mà không có tài liệu tham khảo nào tồn tại mà là để thực hiện ba điều:

1. Vô hiệu hóa các tham chiếu yếu xác định các đối tượng không có bất kỳ tham chiếu nào có thể truy cập mạnh được liên kết với chúng.

2. Tìm kiếm danh sách các đối tượng của hệ thống với bộ hoàn thiện để xem liệu có bất kỳ đối tượng nào không có bất kỳ tài liệu tham khảo nào có thể truy cập mạnh liên quan đến chúng không.

3. Xác định và hợp nhất các vùng lưu trữ không được sử dụng bởi bất kỳ đối tượng nào.

Lưu ý rằng mục tiêu chính của GC là # 3 và càng chờ đợi lâu trước khi thực hiện nó, càng có nhiều cơ hội hợp nhất thì càng có nhiều cơ hội. Thật hợp lý khi làm số 3 trong trường hợp người ta sẽ sử dụng ngay cho việc lưu trữ, nhưng nếu không thì sẽ có ý nghĩa hơn để trì hoãn nó.

Hãy để tôi đề nghị viết lại và khái quát hóa câu hỏi của bạn:

Tại sao Java không đảm bảo mạnh mẽ về quy trình GC của nó?

Với ý nghĩ đó, hãy lướt nhanh qua các câu trả lời ở đây. Có bảy cho đến nay (không tính cái này), với khá nhiều chủ đề bình luận.

Đó là câu trả lời của bạn.

GC là khó. Có rất nhiều cân nhắc, rất nhiều sự đánh đổi khác nhau, và cuối cùng, rất nhiều cách tiếp cận rất khác nhau. Một số trong những cách tiếp cận đó làm cho nó khả thi đối với một đối tượng ngay khi không cần thiết; những người khác thì không. Bằng cách giữ cho hợp đồng lỏng lẻo, Java cung cấp cho người triển khai nhiều tùy chọn hơn.

Tất nhiên, có một sự đánh đổi ngay cả trong quyết định đó: bằng cách giữ cho hợp đồng lỏng lẻo, Java chủ yếu * lấy đi khả năng của các lập trình viên dựa vào các hàm hủy. Đây là điều mà các lập trình viên C ++ đặc biệt thường bỏ lỡ ([cần dẫn nguồn];)), vì vậy nó không phải là một sự đánh đổi không đáng kể. Tôi chưa thấy một cuộc thảo luận nào về quyết định meta cụ thể đó, nhưng có lẽ những người Java đã quyết định rằng lợi ích của việc có nhiều tùy chọn GC hơn nhiều so với lợi ích của việc có thể nói cho các lập trình viên biết chính xác khi nào một đối tượng sẽ bị phá hủy.

* Có finalizephương pháp, nhưng vì nhiều lý do nằm ngoài phạm vi của câu trả lời này, thật khó và không nên dựa vào nó.

Có hai chiến lược xử lý bộ nhớ khác nhau mà không có mã rõ ràng được viết bởi nhà phát triển: Thu gom rác và đếm tham chiếu.

Bộ sưu tập rác có lợi thế là nó "hoạt động" trừ khi nhà phát triển làm điều gì đó ngu ngốc. Với việc đếm tham chiếu, bạn có thể có các chu kỳ tham chiếu, điều đó có nghĩa là nó "hoạt động" nhưng nhà phát triển đôi khi phải khéo léo. Vì vậy, đó là một điểm cộng cho bộ sưu tập rác.

Khi đếm tham chiếu, đối tượng sẽ biến mất ngay lập tức khi số tham chiếu giảm xuống không. Đó là một lợi thế để đếm tham khảo.

Theo tốc độ, bộ sưu tập rác sẽ nhanh hơn nếu bạn tin rằng người hâm mộ của bộ sưu tập rác và việc đếm tham chiếu sẽ nhanh hơn nếu bạn tin rằng người hâm mộ đếm tham chiếu.

Đó chỉ là hai phương thức khác nhau để đạt được cùng một mục tiêu, Java đã chọn một phương thức, Objective-C đã chọn một phương thức khác (và thêm rất nhiều hỗ trợ trình biên dịch để thay đổi nó từ một công cụ khó khăn thành một công việc ít làm cho các nhà phát triển).

Thay đổi Java từ bộ sưu tập rác sang đếm tham chiếu sẽ là một công việc chính, bởi vì sẽ cần rất nhiều thay đổi mã.

Về lý thuyết, Java có thể đã triển khai một hỗn hợp thu gom rác và đếm tham chiếu: Nếu số tham chiếu là 0, thì đối tượng không thể truy cập được, nhưng không nhất thiết phải theo cách khác. Vì vậy, bạn có thể giữ số tham chiếu và xóa các đối tượng khi số tham chiếu của chúng bằng 0 (và thỉnh thoảng chạy bộ sưu tập rác để bắt các đối tượng trong các chu kỳ tham chiếu không thể truy cập được). Tôi nghĩ rằng thế giới bị chia 50/50 ở những người nghĩ rằng thêm tính tham chiếu vào bộ sưu tập rác là một ý tưởng tồi và những người nghĩ rằng thêm bộ sưu tập rác vào đếm tham chiếu là một ý tưởng tồi. Vì vậy, điều này sẽ không xảy ra.

Vì vậy, Java có thể xóa các đối tượng ngay lập tức nếu số tham chiếu của chúng bằng 0 và xóa các đối tượng trong các chu kỳ không thể truy cập sau đó. Nhưng đó là một quyết định thiết kế và Java đã quyết định chống lại nó.

Tất cả các tranh luận và thảo luận về hiệu năng khác về khó hiểu khi không còn tham chiếu đến một đối tượng là chính xác mặc dù một ý tưởng khác mà tôi nghĩ đáng nói là có ít nhất một JVM (azul) xem xét một cái gì đó như thế này trong đó nó thực hiện gc song song về cơ bản có một luồng vm liên tục kiểm tra các tham chiếu để cố gắng xóa chúng, điều này sẽ hành động không hoàn toàn không giống với những gì bạn đang nói. Về cơ bản, nó sẽ liên tục nhìn xung quanh đống và cố gắng lấy lại bất kỳ bộ nhớ nào không được tham chiếu. Điều này không phải chịu một chi phí hiệu suất rất nhỏ nhưng về cơ bản dẫn đến thời gian GC không hoặc rất ngắn. (Đó là trừ khi kích thước heap liên tục mở rộng vượt quá RAM hệ thống và sau đó Azul bị nhầm lẫn và sau đó có rồng)

TLDR Một cái gì đó giống như vậy tồn tại cho JVM, nó chỉ là một jvm đặc biệt và nó có nhược điểm như bất kỳ thỏa hiệp kỹ thuật nào khác.

Tuyên bố miễn trừ trách nhiệm: Tôi không có mối quan hệ nào với Azul, chúng tôi chỉ sử dụng nó ở một công việc trước đó.

Tối đa hóa thông lượng duy trì hoặc giảm thiểu độ trễ gc là trong căng thẳng động, đó có lẽ là lý do phổ biến nhất tại sao GC không xảy ra ngay lập tức. Trong một số hệ thống, như các ứng dụng khẩn cấp 911, không đáp ứng ngưỡng độ trễ cụ thể có thể bắt đầu kích hoạt các quy trình xử lý lỗi trang web. Ở những nơi khác, như một trang web ngân hàng và / hoặc trọng tài, điều quan trọng hơn nhiều là tối đa hóa thông lượng.

Tốc độ

Tại sao tất cả những điều này đang diễn ra cuối cùng là vì tốc độ. Nếu bộ xử lý cực kỳ nhanh, hoặc (thực tế) gần với nó, ví dụ: 1.000.000.000.000.000.000.000.000.000.000.000 hoạt động mỗi giây thì bạn có thể có những điều cực kỳ dài và phức tạp xảy ra giữa mỗi nhà khai thác, chẳng hạn như đảm bảo xóa các đối tượng được tham chiếu. Vì số lượng hoạt động mỗi giây hiện tại không đúng và, vì hầu hết các câu trả lời khác giải thích nó thực sự phức tạp và tốn nhiều tài nguyên để tìm ra điều này, bộ sưu tập rác tồn tại để các chương trình có thể tập trung vào những gì chúng thực sự đang cố gắng đạt được trong một cách nhanh chóng.