Vấn đề tương tranh thường xuyên nhất bạn gặp phải trong Java là gì? [đóng cửa]

Đây là một cuộc thăm dò ý kiến ​​về các vấn đề tương tranh phổ biến trong Java. Một ví dụ có thể là tình trạng bế tắc hoặc tình trạng đua cổ điển hoặc có lẽ là lỗi phân luồng EDT trong Swing. Tôi quan tâm đến cả hai vấn đề có thể xảy ra nhưng cũng là vấn đề phổ biến nhất. Vì vậy, vui lòng để lại một câu trả lời cụ thể về lỗi đồng thời Java cho mỗi bình luận và bỏ phiếu nếu bạn thấy lỗi bạn gặp phải.

Vấn đề tương tranh phổ biến nhất mà tôi đã thấy, là không nhận ra rằng một trường được viết bởi một luồng không được đảm bảo để được nhìn thấy bởi một luồng khác. Một ứng dụng phổ biến của điều này:

class MyThread extends Thread {
  private boolean stop = false;

  public void run() {
    while(!stop) {
      doSomeWork();
    }
  }

  public void setStop() {
    this.stop = true;
  }
}

Chừng nào dừng là không dễ bay hơi hoặc setStopvà runkhông đồng bộ này không được bảo đảm để làm việc. Sai lầm này đặc biệt tệ hại vì trong 99,999% nó sẽ không thành vấn đề trong thực tế vì chủ đề độc giả cuối cùng sẽ thấy sự thay đổi - nhưng chúng ta không biết anh ấy đã nhìn thấy nó sớm như thế nào.

Vấn đề đồng thời đau đớn nhất số 1 của tôi từng xảy ra khi hai thư viện nguồn mở khác nhau đã làm một cái gì đó như thế này:

private static final String LOCK = "LOCK";  // use matching strings 
                                            // in two different libraries

public doSomestuff() {
   synchronized(LOCK) {
       this.work();
   }
}

Thoạt nhìn, đây có vẻ là một ví dụ đồng bộ hóa khá nhỏ. Tuy nhiên; bởi vì các chuỗi được tập trung trong Java, chuỗi ký tự "LOCK"hóa ra là cùng một thể hiện của java.lang.String(mặc dù chúng được khai báo hoàn toàn khác biệt với nhau.) Kết quả rõ ràng là xấu.

Một vấn đề kinh điển là thay đổi đối tượng bạn đang đồng bộ hóa trong khi đồng bộ hóa trên nó:

synchronized(foo) {
  foo = ...
}

Các luồng đồng thời khác sau đó được đồng bộ hóa trên một đối tượng khác và khối này không cung cấp loại trừ lẫn nhau mà bạn mong đợi.

Một vấn đề phổ biến là sử dụng các lớp như Lịch và SimpleDateFormat từ nhiều luồng (thường bằng cách lưu trữ chúng trong một biến tĩnh) mà không đồng bộ hóa. Các lớp này không an toàn cho luồng nên việc truy cập đa luồng cuối cùng sẽ gây ra các vấn đề lạ với trạng thái không nhất quán.

Kiểm tra khóa kép. Bởi và lớn.

Mô hình mà tôi bắt đầu tìm hiểu các vấn đề khi tôi làm việc tại BEA, là mọi người sẽ kiểm tra một người độc thân theo cách sau:

public Class MySingleton {
  private static MySingleton s_instance;
  public static MySingleton getInstance() {
    if(s_instance == null) {
      synchronized(MySingleton.class) { s_instance = new MySingleton(); }
    }
    return s_instance;
  }
}

Điều này không bao giờ hoạt động, bởi vì một luồng khác có thể đã được đưa vào khối được đồng bộ hóa và s_instance không còn null. Vì vậy, sự thay đổi tự nhiên là để thực hiện nó:

  public static MySingleton getInstance() {
    if(s_instance == null) {
      synchronized(MySingleton.class) {
        if(s_instance == null) s_instance = new MySingleton();
      }
    }
    return s_instance;
  }

Điều đó cũng không hoạt động, bởi vì Mô hình bộ nhớ Java không hỗ trợ nó. Bạn cần khai báo s_instance là không ổn định để làm cho nó hoạt động và thậm chí sau đó nó chỉ hoạt động trên Java 5.

Những người không quen thuộc với sự phức tạp của Mô hình bộ nhớ Java mọi lúc mọi nơi .

Không đồng bộ hóa đúng cách trên các đối tượng được trả về Collections.synchronizedXXX(), đặc biệt là trong quá trình lặp hoặc nhiều thao tác:

Map<String, String> map = Collections.synchronizedMap(new HashMap<String, String>());

...

if(!map.containsKey("foo"))
    map.put("foo", "bar");

Điều đó sai . Mặc dù có các hoạt động đơn lẻ synchronized, trạng thái bản đồ giữa việc gọi containsvà putcó thể được thay đổi bởi một luồng khác. Nó nên là:

synchronized(map) {
    if(!map.containsKey("foo"))
        map.put("foo", "bar");
}

Hoặc với ConcurrentMapviệc thực hiện:

map.putIfAbsent("foo", "bar");

Mặc dù có thể không chính xác những gì bạn đang yêu cầu, nhưng vấn đề liên quan đến đồng thời thường gặp nhất mà tôi gặp phải (có lẽ là do nó xuất hiện trong mã đơn luồng thông thường) là một

java.util.ConcurrentModificationException

gây ra bởi những thứ như:

List<String> list = new ArrayList<String>(Arrays.asList("a", "b", "c"));
for (String string : list) { list.remove(string); }

Có thể dễ dàng nghĩ rằng các bộ sưu tập được đồng bộ hóa mang lại cho bạn sự bảo vệ nhiều hơn so với thực tế và quên giữ khóa giữa các cuộc gọi. Tôi đã thấy lỗi này một vài lần:

 List<String> l = Collections.synchronizedList(new ArrayList<String>());
 String[] s = l.toArray(new String[l.size()]);

Ví dụ, trong dòng thứ hai ở trên, toArray()và size()các phương pháp đều đề an toàn trong quyền riêng của họ, nhưng size()được đánh giá tách biệt khỏi toArray(), và các khóa trên danh sách không được tổ chức giữa hai cuộc gọi này.

Nếu bạn chạy mã này với một luồng khác đồng thời loại bỏ các mục khỏi danh sách, sớm hay muộn bạn sẽ kết thúc với một String[]trả về mới lớn hơn yêu cầu để giữ tất cả các thành phần trong danh sách và có giá trị null ở đuôi. Thật dễ dàng để nghĩ rằng bởi vì hai phương thức gọi đến Danh sách xảy ra trong một dòng mã duy nhất, đây là một hoạt động nguyên tử, nhưng thực tế không phải vậy.

Lỗi phổ biến nhất mà chúng tôi thấy nơi tôi làm việc là các lập trình viên thực hiện các hoạt động dài, như các cuộc gọi máy chủ, trên EDT, khóa GUI trong vài giây và khiến ứng dụng không phản hồi.

Quên chờ đợi () (hoặc condition.await ()) trong một vòng lặp, kiểm tra xem điều kiện chờ có thực sự đúng không. Nếu không có điều này, bạn sẽ gặp phải các lỗi từ đánh thức giả (). Sử dụng Canonical nên là:

 synchronized (obj) {
     while (<condition does not hold>) {
         obj.wait();
     }
     // do stuff based on condition being true
 }

Một lỗi phổ biến khác là xử lý ngoại lệ kém. Khi một luồng nền ném một ngoại lệ, nếu bạn không xử lý nó đúng cách, bạn có thể không thấy dấu vết ngăn xếp nào cả. Hoặc có lẽ tác vụ nền của bạn ngừng chạy và không bao giờ bắt đầu lại vì bạn không thể xử lý ngoại lệ.

Cho đến khi tôi mất một lớp học với Brian Goetz Tôi đã không nhận ra rằng không đồng bộ gettercủa một lĩnh vực tư nhân bị biến đổi thông qua một đồng bộ setterlà không bao giờ được đảm bảo để trả về giá trị được cập nhật. Chỉ khi một biến được bảo vệ bởi khối được đồng bộ hóa trên cả hai lần đọc VÀ ghi, bạn mới có được sự đảm bảo về giá trị mới nhất của biến.

public class SomeClass{
    private Integer thing = 1;

    public synchronized void setThing(Integer thing)
        this.thing = thing;
    }

    /**
     * This may return 1 forever and ever no matter what is set
     * because the read is not synched
     */
    public Integer getThing(){
        return thing;  
    }
}

Nghĩ rằng bạn đang viết mã đơn luồng, nhưng sử dụng số liệu thống kê có thể thay đổi (bao gồm cả singletons). Rõ ràng chúng sẽ được chia sẻ giữa các chủ đề. Điều này xảy ra đáng ngạc nhiên thường xuyên.

Các cuộc gọi phương thức tùy ý không nên được thực hiện từ bên trong các khối được đồng bộ hóa.

Dave Ray đã chạm vào điều này trong câu trả lời đầu tiên của anh ấy, và trên thực tế tôi cũng gặp phải một sự bế tắc cũng phải làm với việc gọi các phương thức trên người nghe từ bên trong một phương thức được đồng bộ hóa. Tôi nghĩ rằng bài học tổng quát hơn là các cuộc gọi phương thức không nên được thực hiện "trong tự nhiên" từ trong một khối được đồng bộ hóa - bạn không biết liệu cuộc gọi sẽ kéo dài, dẫn đến bế tắc hoặc bất cứ điều gì.

Trong trường hợp này và thông thường nói chung, giải pháp là giảm phạm vi của khối được đồng bộ hóa để chỉ bảo vệ một phần riêng tư quan trọng của mã.

Ngoài ra, vì chúng tôi hiện đang truy cập Bộ sưu tập người nghe bên ngoài một khối được đồng bộ hóa, chúng tôi đã thay đổi nó thành Bộ sưu tập sao chép trên ghi. Hoặc chúng ta có thể chỉ cần tạo một bản sao phòng thủ của Bộ sưu tập. Vấn đề là, thường có những lựa chọn thay thế để truy cập an toàn vào Bộ sưu tập các đối tượng không xác định.

Lỗi liên quan đến đồng thời gần đây nhất mà tôi gặp phải là một đối tượng mà trong hàm tạo của nó đã tạo ra một ExecutorService, nhưng khi đối tượng không còn được tham chiếu nữa, nó chưa bao giờ tắt ExecutorService. Do đó, trong một khoảng thời gian vài tuần, hàng ngàn luồng bị rò rỉ, cuối cùng khiến hệ thống gặp sự cố. (Về mặt kỹ thuật, nó không gặp sự cố, nhưng nó đã ngừng hoạt động bình thường, trong khi vẫn tiếp tục chạy.)

Về mặt kỹ thuật, tôi cho rằng đây không phải là vấn đề tương tranh, nhưng đó là vấn đề liên quan đến việc sử dụng các thư viện java.util.concurrency.

Đồng bộ hóa không cân bằng, đặc biệt là đối với Bản đồ dường như là một vấn đề khá phổ biến. Nhiều người tin rằng việc đồng bộ hóa trên các bản đồ (không phải là Bản đồ đồng thời, nhưng nói HashMap) và không đồng bộ hóa trên get là đủ. Tuy nhiên, điều này có thể dẫn đến một vòng lặp vô hạn trong quá trình băm lại.

Tuy nhiên, cùng một vấn đề (đồng bộ hóa một phần) có thể xảy ra ở bất cứ nơi nào bạn có trạng thái chia sẻ với đọc và ghi.

Tôi đã gặp một vấn đề tương tranh với Servlets, khi có các trường có thể thay đổi sẽ được giải quyết theo từng yêu cầu. Nhưng chỉ có một ví dụ của servlet cho tất cả các yêu cầu, vì vậy điều này hoạt động hoàn hảo trong một môi trường người dùng duy nhất nhưng khi có nhiều hơn một người dùng yêu cầu các dịch vụ không thể đoán được kết quả.

public class MyServlet implements Servlet{
    private Object something;

    public void service(ServletRequest request, ServletResponse response)
        throws ServletException, IOException{
        this.something = request.getAttribute("something");
        doSomething();
    }

    private void doSomething(){
        this.something ...
    }
}

Không chính xác là một lỗi, nhưng tội lỗi tồi tệ nhất là cung cấp một thư viện mà bạn định người khác sử dụng, nhưng không nêu rõ các lớp / phương thức nào là an toàn cho luồng và những cái nào chỉ phải được gọi từ một luồng, v.v.

Nhiều người nên sử dụng các chú thích đồng thời (ví dụ @ThreadSafe, @GuardedBy, v.v.) được mô tả trong cuốn sách của Goetz.

Vấn đề lớn nhất của tôi luôn là sự bế tắc, đặc biệt là do người nghe bị sa thải với một khóa được giữ. Trong những trường hợp này, thật dễ dàng để có được khóa ngược giữa hai luồng. Trong trường hợp của tôi, giữa một mô phỏng đang chạy trong một luồng và trực quan hóa mô phỏng đang chạy trong luồng UI.

EDIT: Đã chuyển phần thứ hai để tách câu trả lời.

Bắt đầu một luồng trong hàm tạo của một lớp là có vấn đề. Nếu lớp được mở rộng, luồng có thể được bắt đầu trước khi hàm tạo của lớp con được thực thi.

Các lớp có thể thay đổi trong cấu trúc dữ liệu được chia sẻ

Thread1:
    Person p = new Person("John");
    sharedMap.put("Key", p);
    assert(p.getName().equals("John");  // sometimes passes, sometimes fails

Thread2:
    Person p = sharedMap.get("Key");
    p.setName("Alfonso");

Khi điều này xảy ra, mã phức tạp hơn nhiều mà ví dụ đơn giản hóa này. Sao chép, tìm và sửa lỗi là khó. Có lẽ có thể tránh được nếu chúng ta có thể đánh dấu các lớp nhất định là các cấu trúc dữ liệu bất biến và nhất định là chỉ giữ các đối tượng bất biến.

Đồng bộ hóa trên một chuỗi bằng chữ hoặc hằng được xác định bởi một chuỗi ký tự là (có khả năng) là một vấn đề vì chuỗi ký tự được thực hiện và sẽ được chia sẻ bởi bất kỳ ai khác trong JVM bằng cách sử dụng cùng một chuỗi ký tự. Tôi biết vấn đề này đã xuất hiện trong các máy chủ ứng dụng và các tình huống "container" khác.

Thí dụ:

private static final String SOMETHING = "foo";

synchronized(SOMETHING) {
   //
}

Trong trường hợp này, bất kỳ ai sử dụng chuỗi "foo" để khóa đều chia sẻ cùng một khóa.

Tôi tin rằng trong tương lai, vấn đề chính với Java sẽ là (thiếu) đảm bảo khả năng hiển thị cho các nhà xây dựng. Ví dụ: nếu bạn tạo lớp sau

class MyClass {
    public int a = 1;
}

và sau đó chỉ cần đọc thuộc tính của MyClass a từ một luồng khác, MyClass.a có thể là 0 hoặc 1, tùy thuộc vào tâm trạng và cách triển khai của JavaVM. Ngày nay, cơ hội cho 'a' là 1 là rất cao. Nhưng trên các máy NUMA trong tương lai, điều này có thể khác. Nhiều người không nhận thức được điều này và tin rằng họ không cần quan tâm đến đa luồng trong giai đoạn khởi tạo.

Sai lầm ngớ ngẩn nhất mà tôi thường mắc phải là quên đồng bộ hóa trước khi gọi thông báo () hoặc chờ () trên một đối tượng.

Sử dụng một "đối tượng mới ()" cục bộ làm mutex.

synchronized (new Object())
{
    System.out.println("sdfs");
}

Điều này là vô ích.

Một vấn đề 'đồng thời' phổ biến khác là sử dụng mã được đồng bộ hóa khi hoàn toàn không cần thiết. Ví dụ tôi vẫn thấy các lập trình viên sử dụng StringBufferhoặc thậm chí java.util.Vector(như các biến cục bộ của phương thức).

Nhiều đối tượng được bảo vệ khóa nhưng thường được truy cập liên tiếp. Chúng tôi đã gặp một vài trường hợp trong đó các khóa được lấy bằng các mã khác nhau theo các thứ tự khác nhau, dẫn đến bế tắc.

Không nhận ra rằng thistrong một lớp bên trong không phải là thiscủa lớp bên ngoài. Thông thường trong một lớp bên trong vô danh mà thực hiện Runnable. Vấn đề gốc là bởi vì đồng bộ hóa là một phần của tất cả các Objects nên không có kiểm tra kiểu tĩnh. Tôi đã thấy điều này ít nhất hai lần trên usenet và nó cũng xuất hiện trong Brian Goetz'z Java đồng thời trong thực tiễn.

Việc đóng cửa BGGA không phải chịu đựng điều này vì không có thissự đóng cửa ( thistham chiếu lớp bên ngoài). Nếu bạn sử dụng các thisđối tượng không phải là khóa thì nó sẽ giải quyết vấn đề này và các vấn đề khác.

Sử dụng một đối tượng toàn cầu như một biến tĩnh để khóa.

Điều này dẫn đến hiệu suất rất xấu vì ganh đua.

Honesly? Trước khi xuất hiện java.util.concurrent, vấn đề phổ biến nhất mà tôi thường gặp phải là cái mà tôi gọi là "luồng-đập": Các ứng dụng sử dụng các luồng để xử lý đồng thời, nhưng sinh ra quá nhiều trong số chúng và cuối cùng bị đập.