1
例如，考慮在用戶將新內容輸入到文檔中時，在大文檔上工作的拼寫檢查程序。爲了避免延遲用戶的工作，拼寫檢查在單獨的線程上完成，但拼寫檢查器仍然需要訪問文檔。我們可以將對文檔的所有訪問權限放入同步塊中，但這會強制編輯線程放慢速度以適應拼寫檢查線程。在沒有同步訪問的情況下在線程之間共享大數據
原則上，用戶交互線程不應因任何原因被阻塞。如果由於從多個線程訪問文檔而導致任何延遲，我們希望它們總是在拼寫檢查線程中發生，但是什麼樣的線程通信可以保證？
這同樣的問題不僅適用於拼寫檢查。只要一個線程是某些數據的主要擁有者，而另一個線程對數據執行非關鍵的後臺計算，我們就會面臨相同的情況。我認爲解決方案是某種消息傳遞系統，其中輔助線程將請求發送給以主線程自己的速度處理的主線程。
你試過用鎖嗎？如果沒有，那麼你怎麼知道有一個性能問題？我無法想象爲什麼拼寫檢查線程需要持續一段時間才能獲得最新更新（亞毫秒）的本地副本，或者需要更多時間來通知GUI線程的拼寫錯誤（再次，亞毫秒）。 –
Re，「某種消息傳遞」，除非LMAX Disruptor適用於您的應用程序（吞吐量非常高，非阻塞，_bounded_隊列），否則很可能您的消息傳遞將使用某種類型的無論如何都鎖定。 –
@jameslarge我們希望爲性能而設計，而不是一旦解決問題就等待一個問題。原則上UI線程不應該阻塞。我們可能會違反拼寫檢查的原則，但也可能不會。即使我們可能不需要它，也很好地知道如何正確地做到這一點，因此如果以後要做，它不會造成巨大的改變。 – Geo