ทำไมต้องรอ () อยู่ในบล็อกที่ซิงโครไนซ์เสมอ

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

อะไรคือความเสียหายที่อาจเกิดขึ้นหากเป็นไปได้ที่จะเรียกใช้wait()นอกบล็อกที่ซิงโครไนซ์โดยรักษาความหมายไว้ - ระงับเธรดผู้โทร?

A wait()เหมาะสมเมื่อมี a notify()เท่านั้นดังนั้นจึงเป็นเรื่องเกี่ยวกับการสื่อสารระหว่างเธรดเสมอและต้องมีการซิงโครไนซ์เพื่อให้ทำงานอย่างถูกต้อง เราอาจโต้แย้งได้ว่าสิ่งนี้ควรเป็นนัย แต่ไม่สามารถช่วยได้ด้วยเหตุผลดังต่อไปนี้:

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

if(!condition){
    wait();
}

แต่เงื่อนไขจะถูกกำหนดโดยเธรดแยกต่างหากดังนั้นเพื่อให้งานนี้ถูกต้องคุณต้องซิงโครไนซ์

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

• คุณสามารถรับสัญญาณเตือนปลอม (ซึ่งหมายความว่าเธรดสามารถตื่นจากการรอโดยไม่ได้รับการแจ้งเตือน) หรือ

• เงื่อนไขสามารถถูกตั้งค่าได้ แต่เธรดที่สามสร้างเงื่อนไขที่ผิดพลาดอีกครั้งโดยที่เธรดที่รอคอยกลับมาทำงานอีกครั้ง (และเรียกคืนจอภาพอีกครั้ง)

ในการจัดการกับกรณีเหล่านี้สิ่งที่คุณต้องการจริงๆคือการเปลี่ยนแปลงของสิ่งนี้เสมอ :

synchronized(lock){
    while(!condition){
        lock.wait();
    }
}

ยังดีกว่าอย่ายุ่งกับการซิงโครไนซ์ดั้งเดิมและทำงานกับ abstractions ที่เสนอในjava.util.concurrentแพ็คเกจ

อะไรคือความเสียหายที่อาจเกิดขึ้นหากเป็นไปได้ที่จะเรียกใช้wait()นอกบล็อกที่ซิงโครไนซ์โดยรักษาความหมายไว้ - ระงับเธรดผู้โทร?

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

สมมติว่าเราใช้คิวการบล็อก (ฉันรู้ว่ามีอยู่แล้วใน API :)

ความพยายามครั้งแรก (โดยไม่มีการซิงโครไนซ์) อาจดูบางสิ่งตามบรรทัดด้านล่าง

class BlockingQueue {
    Queue<String> buffer = new LinkedList<String>();

    public void give(String data) {
        buffer.add(data);
        notify();                   // Since someone may be waiting in take!
    }

    public String take() throws InterruptedException {
        while (buffer.isEmpty())    // don't use "if" due to spurious wakeups.
            wait();
        return buffer.remove();
    }
}

นี่คือสิ่งที่อาจเกิดขึ้น:

1. ด้ายผู้บริโภคเรียกร้องและเห็นว่าtake()buffer.isEmpty()

2. ก่อนที่เธรดผู้บริโภคจะดำเนินการต่อไปwait()เธรดผู้ผลิตจะเข้ามาและเรียกใช้งานแบบเต็มgive()นั่นคือbuffer.add(data); notify();

3. ด้ายของผู้บริโภคในขณะนี้จะเรียกwait()(และพลาดnotify()ที่ถูกเรียกว่าเพียงแค่)

4. หากโชคร้ายเธรดผู้ผลิตจะไม่ผลิตมากขึ้นgive()เนื่องจากข้อเท็จจริงที่ว่าเธรดผู้บริโภคไม่เคยตื่นขึ้นมาและเรามีระบบล็อคแบบตาย

เมื่อคุณเข้าใจปัญหาแล้ววิธีแก้ไขก็ชัดเจน: ใช้synchronizedเพื่อให้แน่ใจว่าnotifyจะไม่ถูกเรียกระหว่างisEmptyและwaitและ

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

ย่อหน้าจากลิงก์ที่โพสต์โดย @Willieสรุปว่าค่อนข้างดี:

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

buffer.isEmpty()คำกริยาที่ผู้ผลิตและผู้บริโภคจำเป็นต้องตกลงอยู่ในตัวอย่างข้างต้น และข้อตกลงดังกล่าวได้รับการแก้ไขโดยการทำให้มั่นใจว่าการรอและการแจ้งเตือนนั้นดำเนินการเป็นsynchronizedบล็อก

โพสต์นี้ถูกเขียนใหม่เป็นบทความที่นี่: Java: เหตุใดจึงต้องรอในบล็อกที่ซิงค์

@Rollerball ถูกต้อง wait()เรียกว่าเพื่อให้ด้ายสามารถรอให้สภาพบางอย่างที่จะเกิดขึ้นเมื่อนี้wait()โทรที่เกิดขึ้นด้ายถูกบังคับให้ขึ้นล็อค
ในการยอมแพ้คุณต้องเป็นเจ้าของมันก่อน เธรดต้องเป็นเจ้าของล็อคก่อน ดังนั้นความต้องการที่จะเรียกมันว่าภายในsynchronizedเมธอด / บล็อก

ใช่ฉันเห็นด้วยกับคำตอบทั้งหมดข้างต้นเกี่ยวกับความเสียหาย / ความไม่สอดคล้องที่อาจเกิดขึ้นหากคุณไม่ได้ตรวจสอบสภาพภายในsynchronizedวิธี / บล็อก อย่างไรก็ตามเนื่องจาก @ shrini1000 ชี้ให้เห็นว่าการโทรwait()ภายในบล็อกที่ซิงโครไนซ์จะช่วยป้องกันความไม่สอดคล้องนี้

นี่คือการอ่านที่ดี ..

ปัญหาที่อาจเกิดขึ้นหากคุณไม่ซิงโครไนซ์มาก่อนwait()ดังต่อไปนี้:

1. หากเธรดที่ 1 เข้าสู่makeChangeOnX()และตรวจสอบเงื่อนไข while และเป็นtrue( x.metCondition()ส่งคืนfalseหมายความว่าx.conditionมีค่าfalse) ดังนั้นมันจะเข้าสู่ภายใน แล้วก็ก่อนที่จะwait()วิธีหัวข้ออื่นไปsetConditionToTrue()และกำหนดx.conditionไปและtruenotifyAll()
2. จากนั้นหลังจากนั้นเธรดที่ 1 จะเข้าสู่wait()วิธีการของเขา(ไม่ได้รับผลกระทบจากเหตุการณ์notifyAll()ที่เกิดขึ้นเมื่อไม่นานมานี้) ในกรณีนี้เธรดที่ 1 จะรอให้เธรดอื่นดำเนินการอยู่setConditionToTrue()แต่นั่นอาจไม่เกิดขึ้นอีก

แต่ถ้าคุณใส่synchronizedก่อนหน้าวิธีการที่เปลี่ยนสถานะวัตถุสิ่งนี้จะไม่เกิดขึ้น

class A {

    private Object X;

    makeChangeOnX(){
        while (! x.getCondition()){
            wait();
            }
        // Do the change
    }

    setConditionToTrue(){
        x.condition = true; 
        notifyAll();

    }
    setConditionToFalse(){
        x.condition = false;
        notifyAll();
    }
    bool getCondition(){
        return x.condition;
    }
}

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

boolean wasNotified = false;
while(!wasNotified) {
    wait();
}

จากนั้นการแจ้งชุดเธรดคือตัวแปรที่แจ้งถึงจริงและแจ้งให้ทราบ

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

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

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

synchronized(monitor) {
    boolean wasNotified = false;
    while(!wasNotified) {
        wait();
    }
}

ขอบคุณหวังว่ามันชัดเจน

โดยทั่วไปเกี่ยวข้องกับสถาปัตยกรรมฮาร์ดแวร์ (เช่นRAMและแคช )

หากคุณไม่ได้ใช้synchronizedร่วมกับwait()หรือnotify()เธรดอื่นสามารถเข้าสู่บล็อกเดียวกันแทนที่จะรอให้จอภาพเข้าสู่ ยิ่งไปกว่านั้นเมื่อเช่นการเข้าถึงอาเรย์ที่ไม่มีบล็อกที่ซิงโครไนซ์เธรดอื่นอาจไม่เห็นการเปลี่ยนแปลงของมัน ... อันที่จริงเธรดอื่นจะไม่เห็นการเปลี่ยนแปลงใด ๆเมื่อมันมีสำเนาของอาเรย์ในแคชระดับ x แล้ว aka แคชระดับ 1 / 2nd / 3rd) ของเธรดการจัดการ CPU core

แต่บล็อกที่ซิงโครไนซ์เป็นเพียงด้านเดียวของเหรียญ: ถ้าคุณเข้าถึงวัตถุภายในบริบทที่ซิงโครไนซ์จากบริบทที่ไม่ซิงโครไนซ์วัตถุนั้นจะไม่ถูกซิงโครไนซ์แม้จะอยู่ในบล็อกที่ซิงโครไนซ์ วัตถุในแคชของมัน ฉันเขียนเกี่ยวกับปัญหานี้ที่นี่: https://stackoverflow.com/a/21462631และเมื่อการล็อกมีวัตถุที่ไม่สิ้นสุดการอ้างอิงของวัตถุจะยังคงสามารถเปลี่ยนแปลงได้โดยเธรดอื่นหรือไม่

นอกจากนี้ฉันเชื่อว่าแคชระดับ x มีหน้าที่รับผิดชอบข้อผิดพลาดรันไทม์ที่ไม่สามารถทำซ้ำได้ส่วนใหญ่ นั่นเป็นเพราะนักพัฒนามักจะไม่เรียนรู้สิ่งต่าง ๆ ในระดับต่ำเช่นวิธีการทำงานของ CPU หรือลำดับชั้นของหน่วยความจำมีผลต่อการทำงานของแอปพลิเคชัน: http://en.wikipedia.org/wiki/Memory_hierarchy

ยังคงเป็นปริศนาว่าทำไมคลาสการเขียนโปรแกรมไม่เริ่มต้นด้วยลำดับชั้นหน่วยความจำและสถาปัตยกรรม CPU ก่อน "Hello world" จะไม่ช่วยที่นี่ ;)

โดยตรงจากการกวดวิชา Oracle oracle นี้ :

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

เมื่อคุณเรียกใช้การแจ้งเตือน () จากวัตถุ t, java จะแจ้งเมธอด t.wait () เฉพาะ แต่จาวาค้นหาและแจ้งวิธีการรอได้อย่างไร

java มองเฉพาะในบล็อกซิงโครไนซ์ของรหัสซึ่งถูกล็อคโดยวัตถุ t java ไม่สามารถค้นหารหัสทั้งหมดเพื่อแจ้งเตือนเฉพาะ t.wait ()

ตามเอกสาร:

เธรดปัจจุบันต้องเป็นเจ้าของจอภาพของวัตถุนี้ เธรดปล่อยความเป็นเจ้าของของจอภาพนี้

wait()วิธีการก็หมายความว่ามันปล่อยล็อคบนวัตถุ ดังนั้นวัตถุจะถูกล็อคเฉพาะภายในบล็อก / วิธีการทำข้อมูลให้ตรงกัน หากเธรดอยู่นอกบล็อกการซิงค์หมายความว่าไม่ได้ล็อคถ้าไม่ล็อคคุณจะปล่อยสิ่งใดบนวัตถุ

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

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

class A {
   int a = 0;
  //something......
  public void add() {
   synchronization(this) {
      //this is your monitoring object and thread has to wait to gain lock on **this**
       }
  }