Chủ đề giảm/giảm không an toàn - tại sao chủ yếu là tích cực?

Question

Tôi đang tự hỏi về kết quả của decrementing không an toàn/incrementing trong chủ đề java, do đó chương trình của tôi:

lớp chính:

public class Start { 

    public static void main(String[] args) { 

     int count = 10000000, pos = 0, neg = 0, zero = 0; 

     for (int x=0; x<10000; x++) { 

      Magic.counter = 0; 

      Thread dec = new Thread(new Magic(false, count)); 
      Thread inc = new Thread(new Magic(true, count)); 

      dec.start(); 
      inc.start(); 

      try { 
       inc.join(); 
       dec.join(); 
      } catch (InterruptedException e) { 
       System.out.println("Error"); 
      } 

      if (Magic.counter == 0) 
       zero++; 
      else if (Magic.counter > 0) 
       pos++; 
      else 
       neg++; 
     } 

     System.out.println(Integer.toString(neg) + "\t\t\t" + Integer.toString(pos) + "\t\t\t" + Integer.toString(zero)); 
    } 
} 

Chủ đề lớp:

public class Magic implements Runnable { 

    public static int counter = 0; 

    private boolean inc; 
    private int countTo; 

    public Magic(boolean inc, int countTo) { 
     this.inc = inc; 
     this.countTo = countTo; 
    } 

    @Override 
    public void run() { 

     for (int i=0;i<this.countTo;i++) { 

      if (this.inc) 
       Magic.counter++; 
      else 
       Magic.counter--; 
     } 

    } 
} 

tôi đã chạy chương trình vài lần, và luôn luôn nhận được kết quả tích cực hơn nhiều sau đó tiêu cực. Tôi cũng đã cố gắng thay đổi trật tự của chủ đề nào bắt đầu nhưng điều này không thay đổi gì cả. Một số kết quả:

Number of results < 0 | Number of results > 0 | Number of results = 0 

1103    8893    4 
3159    6838    3 
2639    7359    2 
3240    6755    5 
3264    6728    8 
2883    7112    5 
2973    7021    6 
3123    6873    4 
2882    7113    5 
3098    6896    6 

Answer 1

Tôi đặt cược bạn sẽ thấy những hành vi hoàn toàn ngược lại với sự thay đổi sau đây (có nghĩa là, đảo ngược các ngành mà không thay đổi bất cứ điều gì khác):

if (this.inc) 
    Magic.counter--; // note change, and lie about `this.inc` 
else 
    Magic.counter++; 

Nếu đúng, những gì có thể điều này cho biết điều này cho biết về các tương tác luồng?

Bây giờ, để giải trí, hãy làm cho Magic.counter dễ bay hơi - [cách] các kết quả thay đổi như thế nào?

Điều gì về việc xóa volatile và xung quanh if/else bằng một số lock? (A lock đảm bảo một hàng rào bộ nhớ đầy đủ và thiết lập một khu vực quan trọng. Nó phải luôn mang lại kết quả hoàn hảo.)

Happy coding.

---

Những điều cần xem xét:

1. Mã này chỉ nhìn vào nhỏ hơn hoặc lớn hơn số không, không phải tổng thể trôi dạt/biến thể: a +1 hoặc -1 là tất cả những gì cần thiết để tip quy mô. (Nó có thể hữu ích hơn để mở rộng dữ liệu được thu thập.)
2. Phải mất nhiều thời gian hơn để thực hiện nhánh "khác" như là một bước nhảy được yêu cầu; bình thường, đây không phải là vấn đề, nhưng hơn 10 triệu chu kỳ ... một hoặc hai là không nhiều.
3. Thiếu hàng rào dễ bay hơi/bộ nhớ cho nhiều lee-way trong khả năng hiển thị biến số Magic.counter. (Tôi tin rằng một JVM phù hợp thực sự có thể mang lại kết quả tồi tệ hơn nhiều ...)
4. Các nhà điều hành ++ và -- vốn không phải là nguyên tử.
5. Xen kẽ chủ đề thường "không xác định"; ít hơn nếu thực hiện trên nhiều lõi.

Answer 2

Nói chung, điều này là do cách thức hoạt động của mô hình bộ nhớ Java. Bạn đang truy cập các biến được chia sẻ trong hai chuỗi riêng biệt mà không cần đồng bộ hóa. Không phải là biến khai báo dễ bay hơi, cũng không phải bạn đang chạy các hoạt động nguyên tử. Sự vắng mặt của các biến phối hợp và nguyên tử hoặc biến động sẽ dẫn đến tối ưu hóa nội bộ của mã luồng được thực hiện bởi JVM khi thực hiện. Ngoài ra, các biến không dễ bay hơi không vượt qua hàng rào bộ nhớ (tức là synchronized) sẽ dẫn đến các giá trị được lưu trong mỗi luồng - và do đó có hai bản sao chủ đề xung đột trong bộ đệm của chúng.

Do không có mô hình nhất quán tuần tự trong Java, tối ưu hóa thời gian chạy phức tạp và đặc thù của JVM đã sử dụng và hệ thống cơ bản (đơn hoặc đa lõi, siêu phân luồng), không thể dự đoán kết quả theo định thức - chỉ vì nó đang vi phạm một số quy ước đa luồng cho mô hình ngôn ngữ Java. Việc chạy chính xác cùng một mã trên cùng một máy vẫn có thể dẫn đến kết quả tương tự, nhưng do tác động của việc lập lịch trình chuỗi, việc sử dụng CPU của các quá trình hệ điều hành khác, v.v ... chúng sẽ không giống chính xác.

Dưới đây là một số tài nguyên về JMM: http://www.cs.umd.edu/~pugh/java/memoryModel/