Trong Java Concurrency thực hành, phần 2.4, nó nói rằng cách tiếp cận khóa nội tại, như chống lại khóa rõ ràng là một quyết định thiết kế xấu như nó gây nhầm lẫn và cũng có thể "... nó buộc JVM triển khai thực hiện sự cân bằng giữa kích thước đối tượng và khóa hiệu suất." Có thể ai đó vui lòng giải thích cách hiệu ứng kích thước đối tượng khóa hiệu suất không?Có mối quan hệ nào giữa kích thước đối tượng và hiệu suất khóa trong Java không?
Vì mọi đối tượng đều có thể bị khóa, điều này có nghĩa là mọi đối tượng phải có đủ chỗ để lưu trữ tất cả thông tin chúng tôi cần khi khóa.
Đó là khá hấp dẫn bởi vì đại đa số các đối tượng sẽ không bao giờ bị khóa vì vậy chúng tôi đang lãng phí rất nhiều không gian. Vì vậy, trong thực tế Hotspot giải quyết điều này bằng cách sử dụng 2 bit để ghi lại trạng thái của đối tượng và sử dụng lại phần còn lại của tiêu đề đối tượng tùy thuộc vào hai bit này.
Sau đó, bạn có thể bắt đầu đọc về nó here. Tài liệu Hotspot không phải là những gì tôi muốn gọi rộng rãi, nhưng khóa và đối tượng tiêu đề được đại diện tốt hơn so với hầu hết phần còn lại. Nhưng nghi ngờ: Đọc mã nguồn.
PS: Chúng tôi cũng gặp vấn đề tương tự với mã băm gốc của mọi đối tượng. "Chỉ cần sử dụng địa chỉ bộ nhớ" là không tốt nếu GC của bạn xáo trộn các đối tượng xung quanh. (Nhưng trái với khóa không có thay thế thực sự - nếu chúng ta muốn chức năng này)
cảm ơn cho thông tin, về cơ bản của nó về tất cả syncronization nguyên thủy, không phân biệt kích thước của đối tượng cụ thể được sử dụng để khóa – meer
bạn có một số chi tiết cụ thể để đi với những tuyên bố? "có nhiều khoảng trống? thông tin nào là cần thiết khi khóa? – Toby
@Toby Vâng ít nhất là TID và một truy cập đệ quy. Để biết chi tiết, bạn sẽ phải xem các lớp khóa nặng trong nguồn phát sóng. Xem xét rằng điều này được thêm vào mọi đối tượng ngay cả 1-2words là "rất nhiều không gian" mặc dù. – Voo
Ổ khóa hiệu quả nhất sử dụng kích thước từ gốc, ví dụ: Các trường 32 bit. Tuy nhiên, bạn không muốn thêm 4 byte vào mỗi đối tượng, do đó, thay vào đó, AFAIK 1 bit được sử dụng, tuy nhiên, thiết lập bit này đắt hơn để thiết lập kích thước chữ.
Hmm chúng ta có thể làm điều đó mà không có CAS ngay cả khi chúng ta sử dụng các trường có kích thước từ không? Nếu không nó về cơ bản chỉ đọc + bit xáo trộn + CAS so với CAS - có lẽ không phải là xấu, nhưng vẫn còn chậm hơn. – Voo
@Voo không phải là xấu trong kinh nghiệm của tôi như 'đồng bộ' có thể được tối ưu hóa bởi JIT là cách Khóa không. –
Tôi đang nói về việc triển khai đồng bộ hóa. Ngay cả khi chúng tôi sử dụng một tiêu đề khóa từ, chúng tôi vẫn cần một CAS mà nên thống trị các bit xáo trộn, do đó, không có nhiều sự khác biệt ở đó. Có lẽ chúng ta đang nói chuyện qua nhau. – Voo
Không nên có mối quan hệ với kích thước với ổ khóa loại 'đồng bộ' (từ kinh nghiệm của tôi thực hiện điều này), và, từ một đánh giá ngắn gọn của Java 5 khóa chương trình, tôi không tự tay xem làm thế nào có thể có một sự phụ thuộc ở đó. Nó thực tế có nhiều dung lượng lưu trữ hơn, tất nhiên, để thực hiện các đối tượng 'Lock' riêng biệt, nhưng đó phải là một chi phí cố định. –
@HotLicks thats những gì làm tôi ngạc nhiên, kích thước shudnt có bất kỳ chi phí bổ sung, nhờ! – meer