Java'da en sık karşılaştığınız eşzamanlılık sorunu nedir? [kapalı]

Bu, Java'daki yaygın eşzamanlılık sorunları hakkında bir ankettir. Bir örnek, klasik kilitlenme veya yarış durumu veya belki de Swing'deki EDT diş açma hataları olabilir. Hem olası sorunların genişliği hem de hangi sorunların en yaygın olduğu ile ilgileniyorum. Bu nedenle, lütfen yorum başına bir Java eşzamanlılık hatası için belirli bir cevap bırakın ve karşılaştığınız birini görürseniz oy verin.

Gördüğüm en yaygın eşzamanlılık sorunu, bir iş parçacığı tarafından yazılan bir alanın farklı bir iş parçacığı tarafından görülmesinin garanti edilmediğinin farkında değildir . Bunun ortak bir uygulaması:

class MyThread extends Thread {
  private boolean stop = false;

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

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

Sürece durağı olarak değil uçucu ya setStopve runolmayan senkronize bu işe garanti edilmez. Bu hata, özellikle% 99,999'da olduğu gibi şeytani bir şeydir, çünkü okuyucu iş parçacığı sonunda değişikliği görecektir - ancak ne kadar sürede gördüğünü bilmiyoruz.

Benim en acı verici eşzamanlılık sorunum iki farklı açık kaynak kütüphanesi böyle bir şey yaptığında ortaya çıktı :

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

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

İlk bakışta, bu oldukça önemsiz bir senkronizasyon örneğine benziyor. Ancak; Dizeler Java'da staj olduğundan , değişmez dize "LOCK"aynı örnek olarak ortaya çıkar java.lang.String(birbirlerinden tamamen farklı olsalar bile) Sonuç açıkça kötüdür.

Klasik sorunlardan biri, senkronize ederken senkronize ettiğiniz nesneyi değiştirmektir:

synchronized(foo) {
  foo = ...
}

Diğer eşzamanlı iş parçacıkları daha sonra farklı bir nesne üzerinde eşitlenir ve bu blok beklediğiniz karşılıklı dışlamayı sağlamaz.

Sık karşılaşılan bir sorun, Takvim ve SimpleDateFormat gibi sınıfları eşitlemeden birden çok iş parçacığından (genellikle statik bir değişkende önbelleğe alarak) kullanmaktır. Bu sınıflar iş parçacığı için güvenli değildir, bu nedenle çok iş parçacıklı erişim sonuçta tutarsız durumla garip sorunlara neden olur.

Özellikle yineleme veya çoklu işlemler sırasında döndürülen nesneler üzerinde düzgün senkronizeCollections.synchronizedXXX() edilmemesi:

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

...

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

Bu yanlış . Tek işlem olmasına rağmen synchronized, çağırma arasındaki haritanın durumu containsve putbaşka bir evre tarafından değiştirilebilir. Olmalı:

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

Veya bir ConcurrentMapuygulama ile:

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

Çift Kontrollü Kilitleme. Genel olarak.

BEA'da çalışırken yaşadığım sorunları öğrenmeye başladığım paradigma, insanların bir singletonu şu şekilde kontrol edeceğidir:

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;
  }
}

Bu asla işe yaramaz, çünkü senkronize edilmiş bloğa başka bir iş parçacığı girmiş olabilir ve s_instance artık null değildir. Böylece doğal değişim bunu yapmaktır:

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

Java Bellek Modeli bunu desteklemediğinden bu da işe yaramaz. Çalışması için s_instance değişkenini deklare etmeniz gerekir ve o zaman bile sadece Java 5 üzerinde çalışır.

Java Bellek Modeli'nin karmaşıklıklarına aşina olmayan insanlar bunu her zaman berbat eder .

Muhtemelen tam olarak ne istediğinizi olmasa da, karşılaştığım en sık eşzamanlılık sorunu (muhtemelen normal tek iş parçacıklı kodda geldiği için)

java.util.ConcurrentModificationException

gibi şeylerin neden olduğu:

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

Senkronize edilmiş koleksiyonların gerçekte olduğundan daha fazla koruma sağladığını düşünmek kolay olabilir ve aramalar arasındaki kilidi tutmayı unutmayın. Bu hatayı birkaç kez gördüm:

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

Örneğin, yukarıdaki ikinci satırda, toArray()ve size()yöntemlerinin her ikisi de kendi başlarına iş parçacığı açısından güvenlidir, ancak , ve size()öğesinden ayrı olarak değerlendirilir toArray()ve Listedeki kilit bu iki çağrı arasında tutulmaz.

Bu kodu, öğeleri listeden aynı anda kaldıran başka bir iş parçacığıyla çalıştırırsanız , er ya da geç String[], listedeki tüm öğeleri tutmak için gerekenden daha büyük ve kuyrukta null değerleri olan yeni bir döndürme ile sonuçlanırsınız. Listeye iki yöntem çağrısının tek bir kod satırında gerçekleştiği için bunun bir şekilde atomik bir işlem olduğunu düşünmek kolaydır, ancak değildir.

Çalıştığım yerde gördüğümüz en yaygın hata, programcıların EDT'de sunucu çağrıları gibi uzun işlemler gerçekleştirmesi, GUI'yi birkaç saniyeliğine kilitlemesi ve uygulamanın yanıt vermemesidir.

Bir döngüde wait () (veya Condition.await ()) öğesinin unutulması, bekleme koşulunun gerçekten doğru olup olmadığını kontrol etme. Bu olmadan, sahte wait () uyandırma hataları böcek içine koşmak. Kanonik kullanım:

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

Başka bir yaygın hata, kötü istisna işlemedir. Bir arka plan iş parçacığı bir istisna atarsa, düzgün işlemezseniz yığın izini hiç göremeyebilirsiniz. Veya arka plan göreviniz çalışmayı durdurur ve istisnayı işleyemediğiniz için bir daha asla başlamaz.

Brian Goetz ile bir ders getteralana kadar, senkronize edilmiş bir mutasyona uğramış özel bir alanın senkronize setteredilmesinin , güncellenmiş değeri döndüreceği asla garanti edilemezdi. Yalnızca bir değişken her iki okumada VE yazarken senkronize blok tarafından korunduğunda , değişkenin en son değerinin garantisini alırsınız.

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;  
    }
}

Tek iş parçacıklı kod yazdığınızı düşünün, ancak değişebilir statikler kullanın (tektonlar dahil). Açıkçası konu başlıkları arasında paylaşılacaklar. Bu şaşırtıcı bir şekilde sık sık olur.

Senkronize blokların içinden rastgele yöntem çağrıları yapılmamalıdır.

Dave Ray ilk cevabında buna değindi ve aslında aynı zamanda senkronize edilmiş bir yöntemden dinleyicilere çağrı yapma yöntemleri ile ilgili bir çıkmaza da rastladım. Bence daha genel bir ders yöntem çağrıları senkronize bir blok içinde "vahşi içine" yapılmaması gerektiğidir - çağrının uzun süre çalışıp çalışmayacağı, çıkma veya başka bir sonuçla sonuçlanacağına dair hiçbir fikriniz yok.

Bu durumda ve genellikle genel olarak çözüm, kodun kritik bir özel bölümünü korumak için senkronize bloğun kapsamını azaltmaktı .

Ayrıca, dinleyici Koleksiyonuna senkronize edilmiş bir bloğun dışında eriştiğimiz için, onu bir kopya üzerine yazma Koleksiyonu olarak değiştirdik. Ya da sadece Koleksiyonun savunma amaçlı bir kopyasını oluşturabilirdik. Mesele şu ki, bilinmeyen nesneler koleksiyonuna güvenli bir şekilde erişmek için genellikle alternatifler vardır.

Karşılaştığım en son Concurrency ile ilgili hata, yapıcısında bir ExecutorService oluşturan bir nesneydi, ancak nesneye artık başvurulmadığında, ExecutorService'i asla kapatmamıştı. Böylece, birkaç hafta boyunca binlerce iş parçacığı sızdı ve sonunda sistemin çökmesine neden oldu. (Teknik olarak çökmedi, ancak çalışmaya devam ederken düzgün çalışmayı bıraktı.)

Teknik olarak, bunun bir eşzamanlılık sorunu olmadığını, ancak java.util.concurrency kütüphanelerinin kullanımı ile ilgili bir sorun olduğunu düşünüyorum.

Dengesiz senkronizasyon, özellikle Haritalar'a karşı, oldukça yaygın bir sorun gibi görünüyor. Birçok kişi Harita üzerinde senkronizasyonun bir ConcurrentMap değil, bir HashMap dediği) ve get üzerinde senkronize olmamanın yeterli olduğuna inanır. Ancak bu yeniden hash işlemi sırasında sonsuz bir döngüye yol açabilir.

Ancak aynı sorun (kısmi senkronizasyon), okuma ve yazma durumlarını paylaştığınız her yerde oluşabilir.

Her istek tarafından ayarlanacak değişken alanlar olduğunda Servlets ile bir eşzamanlılık sorunuyla karşılaştım. Ancak, tüm istek için yalnızca bir sunucu uygulaması örneği vardır, bu nedenle bu, tek bir kullanıcı ortamında mükemmel bir şekilde çalıştı, ancak birden fazla kullanıcı sunucu uygulaması beklenmedik şekilde sonuç verdi.

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 ...
    }
}

Tam olarak bir hata değil, en kötü günah, başkalarının kullanmayı düşündüğünüz bir kitaplık sağlamaktır, ancak hangi sınıfların / yöntemlerin iş parçacığı için güvenli olduğunu ve hangilerinin yalnızca tek bir iş parçacığından çağrılması gerektiğini belirtmemektedir.

Goetz kitabında açıklanan eşzamanlılık ek açıklamalarından (örneğin @ThreadSafe, @GuardedBy vb.) Daha fazla kişi yararlanmalıdır.

En büyük sorunum hep kilitlenmelerdi, özellikle de bir kilitle ateşlenen dinleyicilerin neden olduğu. Bu durumlarda, iki iplik arasında ters kilitleme elde etmek gerçekten kolaydır. Benim durumumda, bir iş parçacığında çalışan bir simülasyon ile UI iş parçacığında çalışan simülasyonun görselleştirilmesi arasında.

EDIT: Ayrı cevap için ikinci bölüm taşındı.

Bir sınıfın yapıcısında bir iş parçacığının başlatılması sorunludur. Sınıf genişletilirse, alt sınıf yapıcısı yürütülmeden önce iş parçacığı başlatılabilir .

Paylaşılan veri yapılarında değiştirilebilir sınıflar

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");

Bu olduğunda, kod bu basitleştirilmiş örnekten çok daha karmaşıktır. Hatayı çoğaltmak, bulmak ve düzeltmek zordur. Belli sınıfları değişmez ve belirli veri yapılarını sadece değişmez nesneleri tutmak olarak işaretleyebilirsek belki önlenebilir.

Bir dize değişmez değeri veya bir dize değişmez değeri tarafından tanımlanan sabit üzerinde eşitleme (potansiyel olarak) dize değişmez değeri sabitlendiğinden ve aynı dize değişmez değeri kullanılarak JVM'deki başka bir kişi tarafından paylaşılacağı bir sorundur. Bu sorunun uygulama sunucuları ve diğer "kapsayıcı" senaryolarda geldi biliyorum.

Misal:

private static final String SOMETHING = "foo";

synchronized(SOMETHING) {
   //
}

Bu durumda, kilitlemek için "foo" dizesini kullanan herkes aynı kilidi paylaşır.

Gelecekte Java ile ilgili asıl sorunun inşaatçılar için görünürlük garantileri olacağına inanıyorum. Örneğin, aşağıdaki sınıfı oluşturursanız

class MyClass {
    public int a = 1;
}

ve sonra MyClass'ın özelliğini başka bir evreden okudum, JavaVM'nin uygulamasına ve ruh haline bağlı olarak MyClass.a 0 veya 1 olabilir. Bugün 'a' 1 olma şansı çok yüksek. Ancak gelecekteki NUMA makinelerinde bu farklı olabilir. Birçok insan bunun farkında değildir ve başlatma aşaması sırasında çoklu iplik geçirmeyi önemsemeleri gerekmediğine inanmaktadır.

Sıklıkla yaptığım en saçma hata, bir nesneye bildirme () veya wait () öğesini çağırmadan önce senkronize etmeyi unutmaktır.

Muteks olarak yerel bir "yeni Object ()" kullanma.

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

Bu işe yaramaz.

Başka bir yaygın 'eşzamanlılık' sorunu da, gerekli olmadığında senkronize kod kullanmaktır. Örneğin hala StringBufferveya hatta java.util.Vector(yöntem yerel değişkenleri olarak) kullanan programcılar görüyorum .

Kilit korumalı ancak art arda erişilen birden fazla nesne. Kilitlerin farklı kodlarda farklı kodlarla elde edildiği ve kilitlenmeyle sonuçlandığı birkaç durumla karşılaştık.

thisİç sınıftaki thisdış sınıfın olmadığını fark etmemek . Genellikle anonim bir iç sınıfta uygular Runnable. Temel sorun, senkronizasyonun tüm Objects'nin bir parçası olması nedeniyle etkin bir statik tip kontrolü olmamasıdır. Bunu usenet üzerinde en az iki kez gördüm ve Brian Goetz'z Uygulamada Java Eşzamanlılığı'nda da görünüyor.

BGGA kapakları bundan dolayı zarar görmez this, çünkü kapatma için hiçbir şey yoktur ( thisdış sınıfa başvurur ). thisNesne olmayanları kilit olarak kullanırsanız , bu sorun ve diğerlerinin etrafından dolanır.

Kilitleme için statik değişken gibi global bir nesnenin kullanılması.

Bu, çekişme nedeniyle çok kötü performansa yol açar.

Honesly? Gelişinden önce java.util.concurrent, rutin olarak karşılaştığım en yaygın sorun "iş parçacığı" olarak adlandırdığım şeydi: Eşzamanlılık için iş parçacığı kullanan, ancak bunların çoğunu ortaya çıkaran ve daralmaya neden olan uygulamalar.