Tại sao các biến trong Java dễ bay hơi theo mặc định?

Question

câu hỏi Có thể tương tự:

Do you ever use the volatile keyword in Java?

---

Hôm nay tôi đã gỡ lỗi trò chơi của tôi; Nó có một vấn đề rất khó khăn mà sẽ xuất hiện sau mỗi vài phút, nhưng rất khó để tái sản xuất. Vì vậy, đầu tiên tôi thêm từ khóa synchronized vào mỗi phương pháp của tôi. Điều đó không hiệu quả. Sau đó, tôi đã thêm từ khóa volatile vào mọi trường. Vấn đề dường như chỉ sửa chữa chính nó.

Sau một số thử nghiệm, tôi thấy rằng trường chịu trách nhiệm là đối tượng GameState theo dõi trạng thái hiện tại của trò chơi của tôi, có thể phát hoặc bận. Khi bận, trò chơi sẽ bỏ qua đầu vào của người dùng. Những gì tôi có là một chuỗi liên tục thay đổi biến số state, trong khi chuỗi sự kiện đọc biến số state. Tuy nhiên, sau khi một chủ đề thay đổi biến, phải mất vài giây để chuỗi khác nhận ra các thay đổi, điều này cuối cùng gây ra sự cố.

Nó đã được sửa bằng cách tạo biến trạng thái volatile.

Tại sao các biến trong Java volatile theo mặc định và lý do không sử dụng từ khóa volatile là gì?

Answer 1

Để tạo một câu chuyện dài, các biến dễ bay hơi - chúng trong Java hoặc C# - không bao giờ được lưu trong bộ nhớ cache cục bộ trong chuỗi. Điều này không có nhiều ngụ ý trừ khi bạn đang xử lý CPU đa bộ xử lý/đa lõi với các luồng thực thi trên các lõi khác nhau, vì chúng sẽ xem xét cùng một bộ nhớ cache. Khi bạn khai báo một biến là dễ bay hơi, tất cả các lần đọc và ghi đến thẳng và đi thẳng đến vị trí bộ nhớ chính thực tế; không có bộ nhớ cache nào liên quan. Điều này có ý nghĩa khi nói đến tối ưu hóa, và làm như vậy một cách không cần thiết (khi hầu hết các biến không cần phải dễ bay hơi) sẽ gây ra một hình phạt hiệu suất (ít khi nó có thể hoặc có thể không) cho một mức tăng tương đối nhỏ.

Answer 2

Bởi vì trình biên dịch không thể tối ưu hóa biến dễ bay hơi.

volatile cho trình biên dịch biết rằng biến có thể thay đổi bất kỳ lúc nào. Vì vậy, nó không thể giả định rằng biến sẽ không thay đổi và tối ưu hóa cho phù hợp.

Answer 3

Tuyên bố biến dễ bay hơi thường có tác động rất lớn đến hiệu suất. Trên các hệ thống đơn luồng truyền thống, nó tương đối dễ dàng để biết những gì cần thiết để dễ bay hơi; đó là những thứ truy cập phần cứng.

Trên đa luồng có thể phức tạp hơn một chút, nhưng tôi thường khuyến khích sử dụng thông báo và hàng đợi sự kiện để xử lý dữ liệu truyền giữa các lệnh trong các biến ma thuật. Trong Java nó có thể không quan trọng nhiều; trong C/C++ bạn sẽ gặp rắc rối khi các biến đó không thể được thiết lập bằng phần cứng cơ bản.

Answer 4

Trong khi những người khác là chính xác trong việc chỉ ra lý do tại sao nó sẽ là một ý tưởng tồi để mặc định để dễ bay hơi, có một điểm khác để thực hiện: có rất có thể là một lỗi trong mã của bạn. Biến hiếm khi cần phải biến động: luôn có cách để đồng bộ hóa quyền truy cập vào các biến (hoặc bằng từ khóa được đồng bộ hóa hoặc sử dụng đối tượng AtomicXxx từ java.util.concurrency): ngoại lệ sẽ bao gồm mã JNI thao tác (không bị ràng buộc bởi chỉ thị đồng bộ hóa).

Vì vậy, thay vì thêm biến động, bạn có thể muốn tìm ra TẠI SAO nó giải quyết được sự cố. Nó không phải là cách duy nhất để giải quyết nó, và có lẽ là một cách tốt hơn.

Answer 5

Các chất dễ bay hơi chỉ thực sự cần thiết khi bạn đang cố viết mã an toàn, không có khóa ở mức độ thấp. Hầu hết mã của bạn có thể không được là hoặc an toàn chủ đề hoặc không có khóa. Theo kinh nghiệm của tôi, lập trình không có khóa chỉ đáng để thử sau khi bạn thấy rằng phiên bản đơn giản hơn mà thực hiện việc khóa đang phát sinh hiệu suất đáng kể do khóa.

Cách thay thế dễ chịu hơn là sử dụng các khối xây dựng khác trong java.util.concurrent, một số trong số đó không có khóa nhưng không gây rối với đầu của bạn nhiều như cố gắng tự làm ở mức thấp.

Biến động có chi phí hiệu suất của riêng nó và không có lý do gì khiến mã hầu hết phải chịu các chi phí đó.

Answer 6

Cá nhân tôi cho rằng các trường phải được đặt ở vị trí cuối cùng theo mặc định và chỉ có thể thay đổi bằng từ khóa bổ sung, nhưng thuyền đó đã đi thuyền buồm cùng lúc trước. ;)