Buộc thu gom rác không hiệu quả và không cần thiết trong hầu hết các trường hợp ... nếu bạn đã viết chương trình của mình một cách chính xác.
tham khảo:
Nó chỉ ra rằng nếu bạn kiểm soát sự ra đời của JVM mà sẽ chạy ứng dụng của bạn (hoặc Applet hay servlet hoặc bất cứ điều gì) sau đó bạn có thể đảm bảo rằng gọi System.gc() sẽ chạy GC. Hoặc ít nhất, đó là trường hợp với Sun/Oracle JVM ... nơi hành vi được kiểm soát thông qua tùy chọn -XX trên lệnh java.
Điểm mà javadoc tạo ra là điều này phụ thuộc vào nền tảng và ứng dụng di động không thể dựa vào nó.
Đối với câu hỏi của bạn:
TẠI SAO JVM được thiết kế theo một cách mà nó không hỗ trợ quân Garbage Collection?
Để JVM có thể được bảo vệ khỏi tác động hiệu suất của mã được viết sai; ví dụ. trong các ứng dụng, plugin, thư viện của bên thứ ba, v.v.
(Và tôi tưởng tượng một phần vì các kỹ sư Sun ban đầu có chút chán nản với những người phàn nàn rằng "Java chậm" khi vấn đề thực sự là các cuộc gọi không cần thiết System.gc() ...)
1 - Nhưng không phải lúc nào. Ví dụ: gọi System.gc() vào thời điểm thuận tiện có thể là cách tránh tạm dừng liên quan đến GC vào thời điểm bất tiện. Tuy nhiên, nếu mã của bạn chỉ hoạt động nếu bạn chạy GC tại một số điểm nhất định, thì bạn đang làm điều gì đó sai.
Nguồn
2015-06-07 05:36:43
tại sao phải không? Làm thế nào là hữu ích để buộc một bộ sưu tập rác? – Henry
A * cụ thể * triển khai JVM * có thể * chọn để đảm bảo như vậy sẽ thực hiện một GC. Oracle/Open JDKs thì không. Có câu hỏi ở đây là sau đó: "Đối với những gì * lý do thực hiện * hiện' gc' không ngay lập tức buộc một GC dừng trong JVM tiêu chuẩn? " – user2864740
Giả sử bạn muốn tránh tạm dừng GC vào những thời điểm không thích hợp, bạn có thể chống lại chúng bằng cách sử dụng bộ thu gom tạm dừng thấp (như CMS hoặc G1) và có các nhóm đối tượng cho các loại đối tượng cần thiết liên tục.Điều đó sẽ giảm thiểu các sự kiện _stop-the-world_ ở mức tối thiểu, vì các nhóm đối tượng nên chống lại sự phân mảnh heap, đó là gót chân achilles cho CMS và G1. – mucaho