ปัญหาการเห็นพ้องบ่อยที่สุดที่คุณพบใน Java คืออะไร [ปิด]

นี่เป็นแบบสำรวจความคิดเห็นเกี่ยวกับปัญหาการเกิดพร้อมกันทั่วไปใน Java ตัวอย่างอาจเป็น deadlock แบบคลาสสิกหรือสภาพการแข่งขันหรือบางที EDT เธรดเธรดใน Swing ฉันสนใจทั้งปัญหาที่เป็นไปได้กว้าง แต่รวมถึงประเด็นที่พบบ่อยที่สุดด้วย ดังนั้นโปรดทิ้งคำตอบเฉพาะไว้สำหรับข้อบกพร่องของการทำงานพร้อมกันของ Java ต่อความคิดเห็นและโหวตถ้าคุณเห็นคำตอบที่คุณพบ

ปัญหาที่เกิดขึ้นพร้อมกันที่พบบ่อยที่สุดที่ฉันเคยเห็นคือไม่ได้ตระหนักว่าเขตข้อมูลที่เขียนโดยหนึ่งเธรดไม่รับประกันว่าจะเห็นได้โดยเธรดอื่น แอปพลิเคชันทั่วไปของสิ่งนี้:

class MyThread extends Thread {
  private boolean stop = false;

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

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

ตราบใดที่หยุดไม่ระเหยหรือsetStopและrunจะไม่ตรงกันนี้ไม่รับประกันว่าจะทำงาน ความผิดพลาดนี้เป็นเรื่องที่โหดร้ายโดยเฉพาะอย่างยิ่งใน 99.999% มันจะไม่สำคัญในทางปฏิบัติเนื่องจากเธรดผู้อ่านจะเห็นการเปลี่ยนแปลงในที่สุด - แต่เราไม่รู้ว่าเขาจะเห็นได้เร็วแค่ไหน

ปัญหาการทำงานพร้อมกันที่เจ็บปวดที่สุดอันดับ 1ของฉันเคยเกิดขึ้นเมื่อห้องสมุดโอเพ่นซอร์สสองแห่งที่ต่างกันทำสิ่งนี้:

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

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

ในภาพรวมก่อนหน้านี้ดูเหมือนว่าจะเป็นตัวอย่างของการซิงโครไนซ์เล็กน้อย อย่างไรก็ตาม; เนื่องจากสตริงมีการฝึกงานใน Java สตริงตัวอักษร"LOCK"จะกลายเป็นอินสแตนซ์เดียวกันของjava.lang.String(แม้ว่าพวกเขาจะประกาศอย่างสมบูรณ์โดยสิ้นเชิงจากกัน) ผลลัพธ์ที่ได้ก็ไม่ดีอย่างเห็นได้ชัด

ปัญหาคลาสสิกอย่างหนึ่งคือการเปลี่ยนวัตถุที่คุณซิงโครไนซ์ขณะซิงโครไนซ์มัน

synchronized(foo) {
  foo = ...
}

เธรดที่เกิดขึ้นพร้อมกันอื่น ๆ จะซิงโครไนซ์บนวัตถุอื่นและบล็อกนี้ไม่ได้ให้การยกเว้นซึ่งกันและกันที่คุณคาดไว้

ปัญหาที่พบบ่อยคือการใช้คลาสเช่น Calendar และ SimpleDateFormat จากหลายเธรด (โดยการแคชในตัวแปรแบบสแตติก) โดยไม่มีการซิงโครไนซ์ คลาสเหล่านี้ไม่ได้เป็นเธรดที่ปลอดภัยดังนั้นการเข้าถึงแบบมัลติเธรดจะทำให้เกิดปัญหาแปลก ๆ กับสถานะที่ไม่สอดคล้องกันในที่สุด

ไม่ซิงโครไนซ์กับวัตถุที่ส่งคืนโดยCollections.synchronizedXXX()เฉพาะอย่างยิ่งในระหว่างการทำซ้ำหรือการดำเนินการหลายอย่าง:

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

...

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

นั่นคือที่ไม่ถูกต้อง แม้จะมีการดำเนินการเดี่ยวsynchronizedสถานะของแผนที่ระหว่างการเรียกใช้containsและputสามารถเปลี่ยนแปลงได้โดยเธรดอื่น มันควรจะเป็น:

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

หรือด้วยการConcurrentMapใช้งาน:

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

ล็อคตรวจสอบอีกครั้ง โดยและขนาดใหญ่

กระบวนทัศน์ที่ฉันเริ่มเรียนรู้ปัญหาเมื่อฉันทำงานที่ BEA คือผู้คนจะตรวจสอบซิงเกิลในวิธีต่อไปนี้:

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

สิ่งนี้ไม่ได้ผลเนื่องจากเธรดอื่นอาจเข้าสู่บล็อกที่ซิงโครไนซ์และ s_instance จะไม่เป็นโมฆะอีกต่อไป ดังนั้นการเปลี่ยนแปลงตามธรรมชาติคือการทำให้:

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

ไม่สามารถใช้งานได้เนื่องจาก Java Memory Model ไม่รองรับ คุณต้องประกาศ s_instance ว่ามีความผันผวนเพื่อให้มันทำงานได้และแม้กระทั่งมันจะทำงานบน Java 5 เท่านั้น

คนที่ไม่คุ้นเคยกับความซับซ้อนของ Java หน่วยความจำรุ่นระเบียบนี้ขึ้นตลอดเวลา

แม้ว่าอาจจะไม่ใช่สิ่งที่คุณขออย่างแน่นอนปัญหาที่เกี่ยวข้องกับการเกิดพร้อมกันบ่อยที่สุดที่ฉันเคยพบ

java.util.ConcurrentModificationException

เกิดจากสิ่งที่ชอบ:

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

เป็นเรื่องง่ายที่จะคิดว่าคอลเลกชันที่ซิงโครไนซ์จะให้การป้องกันแก่คุณมากกว่าที่เป็นจริงและลืมล็อคระหว่างการโทร ฉันเห็นข้อผิดพลาดนี้สองสามครั้ง:

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

ตัวอย่างเช่นในบรรทัดที่สองด้านบนtoArray()และsize()วิธีการต่างก็ปลอดภัยทั้งเธรดด้วยตนเอง แต่size()ถูกประเมินแยกต่างหากจากtoArray()และล็อคในรายการไม่ได้ถูกพักไว้ระหว่างการโทรทั้งสองนี้

หากคุณเรียกใช้รหัสนี้โดยมีเธรดอื่นนำรายการออกจากรายการพร้อมกันไม่ช้าก็เร็วคุณจะจบลงด้วยการString[]ส่งคืนใหม่ซึ่งมีขนาดใหญ่กว่าที่จำเป็นในการเก็บองค์ประกอบทั้งหมดในรายการและมีค่า Null ในส่วนท้าย มันง่ายที่จะคิดว่าเพราะทั้งสองวิธีการเรียกใช้รายการเกิดขึ้นในรหัสบรรทัดเดียวนี่เป็นการดำเนินการปรมาณู แต่อย่างใด

ข้อผิดพลาดที่พบบ่อยที่สุดที่เราเห็นว่าฉันทำงานคือโปรแกรมเมอร์ทำงานเป็นเวลานานเช่นการโทรเซิร์ฟเวอร์บน EDT ล็อค GUI ไว้สักครู่และทำให้แอปไม่ตอบสนอง

ลืมที่จะรอ () (หรือ Condition.await ()) ในลูปตรวจสอบว่าเงื่อนไขการรอเป็นจริงจริง หากปราศจากสิ่งนี้คุณจะพบข้อบกพร่องจากการรอคอย () การปลอมแปลง การใช้ Canonical ควรเป็น:

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

ข้อผิดพลาดทั่วไปอื่น ๆ คือการจัดการข้อยกเว้นที่ไม่ดี เมื่อเธรดพื้นหลังมีข้อผิดพลาดหากคุณไม่จัดการอย่างถูกต้องคุณอาจไม่เห็นการติดตามสแต็กเลย หรือบางทีงานพื้นหลังของคุณหยุดทำงานและไม่เคยเริ่มต้นอีกครั้งเพราะคุณไม่สามารถจัดการข้อยกเว้นได้

จนกว่าฉันจะเข้าชั้นเรียนกับ Brian Goetz ฉันไม่ได้ตระหนักว่าการไม่ซิงโครไนซ์getterของฟิลด์ส่วนตัวที่setterถูกซิงโครไนซ์ผ่านการซิงโครไนซ์จะไม่รับประกันว่าจะส่งคืนค่าที่อัปเดต เฉพาะเมื่อตัวแปรได้รับการปกป้องโดยบล็อกที่ซิงโครไนซ์ทั้งในการอ่านและเขียนคุณจะได้รับการรับประกันถึงค่าล่าสุดของตัวแปร

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

กำลังคิดว่าคุณกำลังเขียนโค้ดแบบเธรดเดียว แต่ใช้สถิตที่ไม่แน่นอน (รวมถึงซิงเกิลตัน) เห็นได้ชัดว่าพวกเขาจะแบ่งปันระหว่างหัวข้อ สิ่งนี้เกิดขึ้นบ่อยครั้งอย่างแปลกใจ

ไม่ควรทำการโทรด้วยวิธีตามอำเภอใจจากภายในบล็อกที่ซิงโครไนซ์

เดฟเรย์แตะที่นี่ในคำตอบแรกของเขาและในความเป็นจริงฉันก็พบว่ามีการหยุดชะงักเช่นเดียวกับที่เกี่ยวข้องกับวิธีการเรียกใช้ฟังจากวิธีการซิงโครไนซ์ ฉันคิดว่าบทเรียนทั่วไปมากขึ้นคือไม่ควรทำการโทรด้วยวิธีการ "สู่ความเป็นป่า" จากภายในบล็อกที่ซิงโครไนซ์ - คุณไม่มีความคิดว่าการโทรจะใช้เวลานานส่งผลให้หยุดชะงักหรืออะไรก็ตาม

ในกรณีนี้และโดยทั่วไปการแก้ปัญหาคือการลดขอบเขตของบล็อกที่ซิงโครไนซ์เพื่อป้องกันส่วนส่วนตัวที่สำคัญของรหัส

นอกจากนี้เนื่องจากขณะนี้เรากำลังเข้าถึงกลุ่มผู้ฟังนอกบล็อกที่มีการซิงโครไนซ์เราจึงเปลี่ยนเป็นกลุ่มชุดคัดลอกเมื่อเขียน หรือเราอาจจะทำเพียงแค่คัดลอกชุดป้องกัน ประเด็นก็คือมักจะมีทางเลือกอื่นในการเข้าถึงชุดวัตถุที่ไม่รู้จักอย่างปลอดภัย

ข้อผิดพลาดที่เกี่ยวข้องกับการเกิดขึ้นพร้อมกันล่าสุดที่ฉันพบคือวัตถุที่ตัวสร้างสร้าง ExecutorService แต่เมื่อวัตถุไม่ได้ถูกอ้างอิงอีกต่อไปมันไม่เคยปิด ExecutorService ดังนั้นในช่วงสัปดาห์ที่ผ่านมาหลายพันคนมามีการรั่วไหลเธรดทำให้ระบบล่ม (โดยทางเทคนิคแล้วมันไม่ได้ผิดพลาด แต่มันก็หยุดทำงานอย่างถูกต้องในขณะที่ยังคงทำงานต่อไป)

ในทางเทคนิคแล้วฉันคิดว่านี่ไม่ใช่ปัญหาการทำงานพร้อมกัน แต่เป็นปัญหาที่เกี่ยวข้องกับการใช้ไลบรารี java.util.concurrency

การซิงโครไนซ์ที่ไม่สมดุลโดยเฉพาะกับแผนที่ดูเหมือนจะเป็นปัญหาที่พบได้บ่อย หลายคนเชื่อว่าการซิงโครไนซ์ทำให้เป็นแผนที่ (ไม่ใช่ ConcurrentMap แต่พูด HashMap) และการซิงโครไนซ์ไม่ได้รับเพียงพอ อย่างไรก็ตามสิ่งนี้สามารถนำไปสู่การวนซ้ำไม่สิ้นสุดในระหว่างการแฮชอีกครั้ง

ปัญหาเดียวกัน (การซิงโครไนซ์บางส่วน) สามารถเกิดขึ้นได้ทุกที่ที่คุณแชร์สถานะด้วยการอ่านและเขียน

ฉันพบปัญหาการทำงานพร้อมกันกับ Servlets เมื่อมีฟิลด์ที่ไม่แน่นอนซึ่งจะถูกกำหนดโดยการร้องขอแต่ละครั้ง แต่มีเพียงหนึ่ง servlet-instance สำหรับคำร้องขอทั้งหมดดังนั้นสิ่งนี้จึงทำงานได้อย่างสมบูรณ์ในสภาวะแวดล้อมผู้ใช้เดียว แต่เมื่อผู้ใช้มากกว่าหนึ่งคนร้องขอ servlet ผลลัพธ์ที่ไม่สามารถคาดการณ์ได้เกิดขึ้น

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

ไม่ใช่ข้อผิดพลาดอย่างแน่นอน แต่บาปที่เลวร้ายที่สุดคือการจัดหาห้องสมุดที่คุณต้องการให้คนอื่นใช้ แต่ไม่ได้ระบุว่าคลาส / วิธีใดที่ปลอดภัยต่อเธรด

ผู้คนจำนวนมากควรใช้คำอธิบายประกอบที่เกิดขึ้นพร้อมกัน (เช่น @ThreadSafe, @GuardedBy ฯลฯ ) ที่อธิบายไว้ในหนังสือของ Goetz

ปัญหาที่ใหญ่ที่สุดของฉันคือการหยุดชะงักโดยเฉพาะอย่างยิ่งที่เกิดจากผู้ฟังที่ถูกไล่ออกพร้อมล็อคที่จัดขึ้น ในกรณีเหล่านี้มันง่ายมากที่จะได้รับการล็อคกลับกันระหว่างสองเธรด ในกรณีของฉันระหว่างการจำลองที่ทำงานในหนึ่งเธรดและการสร้างภาพจำลองการทำงานในเธรด UI

แก้ไข: ย้ายส่วนที่สองเพื่อแยกคำตอบ

การเริ่มเธรดภายในตัวสร้างของคลาสนั้นเป็นปัญหา ถ้าคลาสถูกขยายเธรดสามารถเริ่มได้ก่อนที่ตัวสร้างคลาสย่อยจะถูกเรียกใช้งาน

คลาสที่ไม่แน่นอนในโครงสร้างข้อมูลที่ใช้ร่วมกัน

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

เมื่อสิ่งนี้เกิดขึ้นรหัสจะซับซ้อนกว่านี้อย่างมากตัวอย่างที่ง่าย การทำซ้ำค้นหาและแก้ไขข้อบกพร่องนั้นยาก อาจหลีกเลี่ยงได้ถ้าเราสามารถทำเครื่องหมายคลาสบางคลาสว่าเป็นโครงสร้างที่ไม่เปลี่ยนรูปและโครงสร้างข้อมูลบางอย่างเป็นเพียงการเก็บวัตถุที่ไม่เปลี่ยนรูป

การซิงโครไนซ์บนสตริงตัวอักษรหรือค่าคงที่ที่กำหนดโดยสตริงตัวอักษรคือ (อาจ) ปัญหาเนื่องจากสตริงตัวอักษรถูก interned และจะถูกแบ่งใช้โดยบุคคลอื่นใน JVM โดยใช้สตริงตัวอักษรเดียวกัน ฉันรู้ว่าปัญหานี้เกิดขึ้นในแอพพลิเคชันเซิร์ฟเวอร์และสถานการณ์ "คอนเทนเนอร์" อื่น ๆ

ตัวอย่าง:

private static final String SOMETHING = "foo";

synchronized(SOMETHING) {
   //
}

ในกรณีนี้ทุกคนที่ใช้สตริง "foo" เพื่อล็อคจะแชร์การล็อคเดียวกัน

ฉันเชื่อว่าในอนาคตปัญหาหลักของ Java คือการรับประกันการมองเห็น (ขาด) สำหรับผู้สร้าง ตัวอย่างเช่นถ้าคุณสร้างคลาสต่อไปนี้

class MyClass {
    public int a = 1;
}

จากนั้นเพียงแค่อ่านคุณสมบัติของ MyClass aจากเธรดอื่น MyClass.a อาจเป็น 0 หรือ 1 ขึ้นอยู่กับการนำไปใช้และอารมณ์ของ JavaVM วันนี้โอกาสสำหรับ 'a' ที่เป็น 1 สูงมาก แต่ในอนาคต NUMA เครื่องอาจแตกต่างกัน หลายคนไม่ได้ตระหนักถึงสิ่งนี้และเชื่อว่าพวกเขาไม่จำเป็นต้องสนใจมัลติเธรดในช่วงเริ่มต้น

ข้อผิดพลาดที่โง่ที่สุดที่ฉันทำบ่อยๆคือลืมซิงโครไนซ์ก่อนที่จะโทรแจ้ง () หรือรอ () บนวัตถุ

การใช้ "วัตถุใหม่ ()" ในท้องถิ่นเป็น mutex

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

นี่มันไร้ประโยชน์

ปัญหา 'การเกิดขึ้นพร้อมกัน' อีกประการหนึ่งคือการใช้รหัสที่ซิงโครไนซ์เมื่อไม่จำเป็นเลย ตัวอย่างเช่นฉันยังเห็นโปรแกรมเมอร์ใช้StringBufferหรือแม้กระทั่งjava.util.Vector(เป็นวิธีตัวแปรท้องถิ่น)

วัตถุหลายอย่างที่ได้รับการป้องกันการล็อค แต่มีการเข้าถึงโดยทั่วไปอย่างต่อเนื่อง เราพบกรณีที่มีการล็อคโดยรหัสที่แตกต่างกันในการสั่งซื้อที่แตกต่างกันทำให้เกิดการหยุดชะงัก

ไม่ทราบว่าthisในชั้นในไม่ได้thisของชั้นนอก Runnableมักจะอยู่ในระดับชั้นที่ไม่ระบุชื่อที่ใช้ ปัญหาหลักคือเนื่องจากการซิงโครไนซ์เป็นส่วนหนึ่งของทั้งหมดObjectไม่มีการตรวจสอบชนิดคงที่ได้อย่างมีประสิทธิภาพ ฉันเคยเห็นสิ่งนี้อย่างน้อยสองครั้งบน usenet และมันก็ปรากฏใน Brian Goetz'z Java Concurrency ในทางปฏิบัติ

การปิดของ BGGA ไม่ได้เกิดจากสิ่งนี้เนื่องจากไม่มีthisการปิด ( thisอ้างอิงจากคลาสภายนอก) หากคุณใช้thisวัตถุที่ไม่ล็อคเป็นการแก้ไขปัญหานี้และอื่น ๆ

การใช้วัตถุร่วมเช่นตัวแปรคงที่สำหรับการล็อค

สิ่งนี้นำไปสู่ประสิทธิภาพที่แย่มากเนื่องจากการช่วงชิง

Honesly? ก่อนการปรากฎตัวของjava.util.concurrentปัญหาที่พบบ่อยที่สุดที่ฉันพบเป็นประจำคือสิ่งที่ฉันเรียกว่า "การฟาดฟันแบบเธรด": แอปพลิเคชันที่ใช้เธรดสำหรับการทำงานพร้อมกัน แต่วางไข่จำนวนมากเกินไป