`LockSupport.park（）`可以代替Object.wait（）嗎？

目前我正在學習Java中的併發編程。我注意到LockSupport.park()在Java 1.6的推出更容易比Object.wait()使用的Object.wait()一個典型的用法是一樣`LockSupport.park（）`可以代替Object.wait（）嗎？

// Thread1 
synchronized (lock) { 
    while (condition != true) { 
     lock.wait() 
    } 

    // do stuff 
} 

// Thread2 
synchronized (lock) { 
    condition = true; 
    lock.notify(); 
}

我想我可以用它改寫LockSupport.park()像

// Thread1 
while (condition != true) { 
    LockSupport.park(); 
} 

// do stuff 

// Thread2 
condition = true; 
LockSupport.unpark(Thread1);

通過使用LockSupport.park()，繁瑣的synchroinzed塊消失。

我的問題是，我應該總喜歡LockSupport.park()比Object.wait()？性能方面Object.wait()比LockSupport.park()好嗎？

來源

2016-09-09 dyng

我不確定，但是想到的一點是，從文檔中不清楚LockSupport的方法是否提供同步提供的任何內存可見性保證（發生在邊和所有內容之前）。 – yshavit

另請參見問題[LockSupport/AbstractQueuedSynchronizer的實際示例]（http://stackoverflow.com/questions/3311811/any-practical-example-of-locksupport-abstractqueuedsynchronizer-use）。 – Kayaman

wait/notify後面的想法是通知不是線程特定的，通知程序不必知道需要通知的特定線程，它只是告訴鎖（或條件，對於ReentrantLock）它是通知，並且它們之間的鎖定和操作系統調度程序決定誰獲得通知。

我期望大多數時間通知者不想知道什麼線程需要停車，所以等待/通知將是這些情況下更好的選擇。隨着公園/ unpark你的代碼必須知道更多，並會有更多的失敗機會。你可能會認爲一個同步塊是單調乏味的，但真正乏味的是排除那些應該有的東西不能被打開的情況。

請注意，在您的第二個示例中，您的條件需要是volatile或Atomic或其他更新在線程間可見的東西。

來源

2016-09-09 16:37:44

在研究了相關類的javadoc之後，我意識到替換wait（）是Condition，而synchroinzed是Lock。 ''Condition'需要從'Lock'派生，也反映了wait（）和synchronized的關係。 'LockSupport.park（）'是它們的基礎。 – dyng

`LockSupport.park（）`可以代替Object.wait（）嗎？

回答

相關問題