Tôi biết lý do JVM GC thích đối tượng sống ngắn vì nó có thể được thu thập trong GC nhỏ. Nhưng tại sao JVM GC lại yêu các vật thể bất biến?Tại sao những objec bất biến được yêu thích bởi GC của JVM?
EDIT: Charlie Hunt nói rằng GC yêu vật không thay đổi trong số presentation của mình.
Cảm ơn
Nếu GC có thể biết rằng một đối tượng không chứa bất kỳ tham chiếu nào đến bất kỳ đối tượng gen0 nào, thì nó có thể bỏ qua khi thực hiện bộ sưu tập gen0. Tương tự như vậy nếu một đối tượng không chứa bất kỳ tham chiếu đến bất kỳ đối tượng gen0 hoặc gen1, nó có thể bị bỏ qua khi thực hiện một bộ sưu tập gen1. Có thể bỏ qua nhiều đối tượng hơn trong bộ sưu tập, bộ sưu tập sẽ nhanh hơn.
Nếu một đối tượng sống sót sau gen0 GC, có thể chắc chắn rằng bất kỳ đối tượng gen0 nào mà đối tượng đã tổ chức tham chiếu sẽ được thăng cấp thành gen1; tương tự như vậy nếu một đối tượng không chứa bất kỳ tham chiếu gen0 nào tồn tại một gen gen1, bất kỳ tham chiếu gen1 nào chứa đối tượng đó sẽ được thăng hạng thành gen2. Vì vậy, một khi một đối tượng đã được kiểm tra trong một bộ sưu tập gen0, nó không cần phải được kiểm tra lại cho đến bộ sưu tập gen1 tiếp theo, trừ khi nó được sửa đổi. Tương tự như vậy, một đối tượng được kiểm tra trong bộ sưu tập gen1 không cần được kiểm tra cho đến bộ sưu tập gen2 tiếp theo trừ khi nó được sửa đổi.
Biết liệu các đối tượng đã được sửa đổi có phải là một chủ đề khó khăn hay không, nhưng điểm mấu chốt là nó rất thuận lợi cho GC nếu các đối tượng chưa được.
Cảm ơn bạn, @supercat. Tôi có câu hỏi: a) Có "bỏ qua" có nghĩa là nó không theo dõi đối tượng xa hơn? b) Gen0, gen1 và gen2 là gì? Bạn có nghĩa là thế hệ trẻ và già? c) Liệu GC có biết các đối tượng đã được sửa đổi hay không? – Jacky
@Jacky: Bởi "bỏ qua" tôi thực sự có nghĩa là "có nghĩa là không theo dõi thêm". Tôi chủ yếu sử dụng .net mà số thế hệ 0-2; Tôi nghĩ rằng việc triển khai Java có nhiều hơn chỉ là một thế hệ "trẻ" và "cũ", nhưng tôi không biết chi tiết. Để cho GC tận dụng các thế hệ trong giai đoạn "đánh dấu", nó phải biết những đối tượng nào có thể đã được sửa đổi kể từ GC cuối cùng cho mỗi thế hệ. Các cơ chế cho điều đó khá phức tạp. Nếu có một phương tiện đặc biệt để khai báo các đối tượng bất biến mà yêu cầu nội dung phải được chỉ định trước khi tham chiếu có thể là ... – supercat
... được chuyển ra khỏi phạm vi thực hiện hiện tại, các đối tượng đó sẽ không cần phải có các cơ chế liên quan họ đã thay đổi (vì họ đơn giản là không thay đổi); Ngoài ra, trên bất kỳ hệ thống nào hỗ trợ các cơ chế bộ nhớ ảo đủ tinh vi để theo dõi các thay đổi đối với các đối tượng có thể thay đổi (và thậm chí nhiều cơ chế VM bị hạn chế hơn nhiều), các cơ chế tương tự có thể được sử dụng để đảm bảo rằng các đối tượng bất biến không thể thay đổi bằng mã "rogue". – supercat
Cảm ơn link..found nó đẹp :)
Từ trình bày: GC thích đối tượng bất biến nhỏ và các đối tượng sống ngắn.
Edit:
nhỏ đối tượng có bộ nhớ ngắn có nghĩa là sau khi bộ sưu tập sẽ không có nhiều chi phí vào bộ nhớ nén (Memory nén là chậm đối với đối tượng lớn khi họ rời khỏi lỗ bộ nhớ lớn hơn sau khi họ nhận được khai hoang bởi GC). Và các vật thể sống ngắn cũng tốt khi chúng được thu thập trong các chu kỳ GC nhỏ.
Đối tượng lớn có thể được quảng bá cho thế hệ cũ trực tiếp nếu nó không thể phù hợp với khu vực sinh tồn trong thời gian gc nhỏ. Một trường hợp tồi tệ hơn, nó có thể được quảng bá vào thế hệ cũ trực tiếp khi nó được tạo ra nếu nó không thể phù hợp với không gian trống của thế hệ trẻ. – Jacky
Đối tượng không thay đổi có nhiều lợi ích. Tôi nghĩ GC có thể dễ dàng tìm thấy tất cả các đối tượng bất biến trong quá trình truy tìm. Tôi đã không tìm ra cách nó có thể làm giảm chi phí để chăm sóc chúng. Tôi tin rằng có một số lý do khiến Hunt nhắc đến điều đó. – Jacky
Vâng, có đối tượng bất biến nhỏ hơn là trường hợp lý tưởng cho hiệu suất tối ưu nhưng ông không bao giờ nhấn mạnh rằng GC ủng hộ các đối tượng không thay đổi. –
Tôi đã tìm thấy câu trả lời từ số article của Brian Goetz.
Trong hầu hết các trường hợp, khi đối tượng chủ được cập nhật để tham chiếu một đối tượng khác, tham chiếu mới là đối tượng trẻ. Nếu chúng ta cập nhật một MutableHolder bằng cách gọi setValue(), chúng ta đã tạo ra một tình huống mà một đối tượng cũ tham chiếu đến một đối tượng trẻ hơn. Mặt khác, bằng cách tạo một đối tượng ImmutableHolder mới thay vào đó, một đối tượng trẻ hơn đang tham chiếu một đối tượng cũ hơn. Tình huống thứ hai, nơi hầu hết các đối tượng trỏ đến các đối tượng cũ hơn, nhẹ nhàng hơn nhiều trên một bộ thu gom rác thế hệ. Nếu một MutableHolder tồn tại trong thế hệ cũ bị đột biến, tất cả các đối tượng trên thẻ có chứa MutableHolder phải được quét cho các tham chiếu cũ để trẻ ở bộ sưu tập nhỏ tiếp theo. Việc sử dụng các tài liệu tham khảo có thể thay đổi cho các đối tượng container tồn tại lâu sẽ làm tăng công việc được thực hiện để theo dõi các tham chiếu cũ đến lúc thu thập.
Tôi tự hỏi liệu có bất kỳ khung công tác GC đáng chú ý nào có một đống riêng biệt cho các đối tượng có thể thay đổi và không thay đổi được, với điều kiện rằng đống không thay đổi sẽ không cần đến các bảng thẻ. Thật vậy, nếu người ta đang cố gắng cho một khung nhỏ gọn, tôi nghĩ người ta có thể có được hiệu suất tốt mà không cần bất kỳ bảng thẻ nào nếu các đối tượng có thể thay đổi gen1/gen2 được quét (nhưng không di chuyển) trên mọi bộ sưu tập nhưng không thể thay đổi được. – supercat
Ai nói JVM GC yêu các đối tượng bất biến？ – lichengwu
Cảm ơn, @lichengwu, tôi đã chỉnh sửa câu hỏi bằng cách thêm nguồn. – Jacky