Chứng minh mã sau không an toàn

Question

Làm thế nào tôi có thể nhanh chóng chứng minh rằng lớp sau không an toàn cho luồng (vì nó sử dụng Khởi tạo Lười biếng và không sử dụng đồng bộ hóa) bằng cách viết một số mã? Nói cách khác, nếu tôi đang thử nghiệm lớp sau cho an toàn luồng, làm thế nào tôi có thể thất bại?

public class LazyInitRace { 
    private ExpensiveObject instance = null; 

    public ExpensiveObject getInstance() { 
    if (instance == null) 
     instance = new ExpensiveObject(); 
    return instance; 
    } 
} 

Answer 1

Vâng ... Kết quả của mã này sẽ là sai, nơi bạn mong đợi cho một sự thật.

import java.util.concurrent.Callable; 
import java.util.concurrent.ExecutionException; 
import java.util.concurrent.FutureTask; 

public class LazyInitRace { 

    public class ExpensiveObject { 
     public ExpensiveObject() { 
      try { 
       Thread.sleep(1000); 
      } catch (InterruptedException e) { 
      } 
     } 
    } 

    private ExpensiveObject instance = null; 

    public ExpensiveObject getInstance() { 
     if (instance == null) 
      instance = new ExpensiveObject(); 
     return instance; 
    } 

    public static void main(String[] args) { 
     final LazyInitRace lazyInitRace = new LazyInitRace(); 

     FutureTask<ExpensiveObject> target1 = new FutureTask<ExpensiveObject>(
       new Callable<ExpensiveObject>() { 

        @Override 
        public ExpensiveObject call() throws Exception { 
         return lazyInitRace.getInstance(); 
        } 
       }); 
     new Thread(target1).start(); 

     FutureTask<ExpensiveObject> target2 = new FutureTask<ExpensiveObject>(
       new Callable<ExpensiveObject>() { 

        @Override 
        public ExpensiveObject call() throws Exception { 
         return lazyInitRace.getInstance(); 
        } 
       }); 
     new Thread(target2).start(); 

     try { 
      System.out.println(target1.get() == target2.get()); 
     } catch (InterruptedException e) { 
     } catch (ExecutionException e) { 
     } 
    } 
} 

Answer 2

Bạn có thể buộc ExpensiveObject mất nhiều thời gian để xây dựng trong thử nghiệm không? Nếu vậy, chỉ cần gọi getInstance() hai lần từ hai luồng khác nhau, trong một khoảng thời gian đủ ngắn mà hàm tạo đầu tiên sẽ không hoàn thành trước khi thực hiện cuộc gọi thứ hai. Bạn sẽ kết thúc với hai trường hợp khác nhau đang được xây dựng, đó là nơi bạn nên thất bại.

Làm cho khóa kiểm tra hai lần không được kiểm tra sẽ khó hơn, hãy nhớ bạn ... (mặc dù không an toàn nếu không chỉ định volatile cho biến).

Answer 3

Vâng, nó không phải là chủ đề an toàn. Proofing của chủ đề an toàn là ngẫu nhiên mà là đơn giản:

1. Hãy ExpensiveObject constructor hoàn toàn an toàn:

   đồng bộ ExpensiveObject() {...

2. Nơi để xây dựng mã mà kiểm tra nếu một bản sao khác của đối tượng tồn tại - sau đó tăng ngoại lệ.

3. Tạo chủ đề phương pháp an toàn để xóa 'dụ' biến

4. Nơi mã tuần tự của getInstance/clearInstance để lặp để thực hiện bởi nhiều chủ đề và chờ ngoại lệ từ (2)

Answer 4

Theo định nghĩa , điều kiện chủng tộc không thể được kiểm tra xác định, trừ khi bạn kiểm soát bộ lập lịch trình (mà bạn không). Điều gần nhất bạn có thể làm là thêm độ trễ có thể định cấu hình theo phương thức getInstance() hoặc viết mã nơi có sự cố có thể hiển thị và chạy hàng nghìn lần trong một vòng lặp.

BTW, không có điều nào trong số này thực sự tạo thành "bằng chứng". Formal Verification sẽ, nhưng rất, rất khó làm, ngay cả đối với số lượng mã tương đối nhỏ.

Answer 5

Đặt một tính toán rất dài trong constructor:

public ExpensiveObject() 
{ 
    for(double i = 0.0; i < Double.MAX_VALUE; ++i) 
    { 
     Math.pow(2.0,i); 
    } 
} 

Bạn có thể muốn giảm điều kiện chấm dứt để Double.MAX_VALUE/2.0 hoặc chia cho một số lượng lớn nếu MAX_VALUE là dùng quá lâu cho ý thích của bạn.

Answer 6

Vì đây là Java, bạn có thể sử dụng thư viện thread-weaver để tạm dừng hoặc ngắt mã và kiểm soát nhiều chuỗi thực thi. Bằng cách này bạn có thể nhận được một hàm tạo chậm ExpensiveObject mà không cần phải sửa đổi mã của hàm tạo, như cách khác đã đề xuất (chính xác).

Answer 7

Điều này không sử dụng mã, nhưng đây là ví dụ về cách tôi chứng minh điều đó.Tôi quên định dạng chuẩn cho các sơ đồ thực hiện như thế này, nhưng ý nghĩa phải đủ rõ ràng.

| Thread 1    | Thread 2    | 
|-----------------------|-----------------------| 
| **start**    |      | 
| getInstance()   |      | 
| if(instance == null) |      | 
| new ExpensiveObject() |      | 
| **context switch ->** | **start**    | 
|      | getInstance()   | 
|      | if(instance == null) | //instance hasn't been assigned, so this check doesn't do what you want 
|      | new ExpensiveObject() | 
| **start**    | **<- context switch** | 
| instance = result  |      | 
| **context switch ->** | **start**    | 
|      | instance = result  | 
|      | return instance  | 
| **start**    | **<- context switch** | 
| return instance  |      | 

Answer 8

Bạn có thể chứng minh điều đó dễ dàng với trình gỡ lỗi.

1. Viết chương trình gọi getInstance() trên hai chủ đề riêng biệt .
2. Đặt điểm ngắt trên công trình xây dựng của ExpensiveObject. Đảm bảo rằng trình gỡ lỗi sẽ chỉ tạm dừng chủ đề chứ không phải máy ảo.
3. Sau đó, khi chuỗi đầu tiên dừng lại trên điểm ngắt, hãy để nó dừng lại.
4. Khi chuỗi thứ hai dừng lại, bạn chỉ cần tiếp tục.
5. Nếu bạn kiểm tra kết quả cuộc gọi getInstance() cho cả hai chủ đề, , chúng sẽ đề cập đến các trường hợp khác nhau.

Lợi thế khi thực hiện theo cách này, là bạn không thực sự cần ExpensiveObject, bất kỳ đối tượng nào trên thực tế cũng sẽ tạo ra kết quả tương tự. Bạn chỉ đơn giản là sử dụng trình gỡ rối để lên lịch thực hiện dòng mã cụ thể đó và do đó tạo ra một kết quả xác định.