給定一個同步程序（Minecraft），當世界正在生成時需要處理x光照更新。提高性能的一項技術是將Minecraft修補程序改爲排隊照明更新，然後異步處理它們，從隊列中刪除任何重複的預定照明更新。緩慢線程處理的緩解技術
這是爲了提供一些重複刪除，以及在接下來的幾個滴答週期中分散世代的負載。
這個隊列當前是無界的，並且在重複的位置檢查之前，當隊列長到可笑的大小時，將是性能差或內存泄漏的來源。
如果隊列增長得快，它正在處理的情況下，你能做些什麼來解決內存泄漏？是否有技術強制線程獲得更多時間，或阻塞直到隊列長度達到一定長度？我們無法提供背壓，因爲這會導致丟失的照明更新，而這些更新不一定會被重新安排。在有希望的處理之前也可能具有最大排隊時間可能是理想的。
我會提供代碼，/以更抽象的方式提問，但我不確定具體情況。
除了將睡眠語句放入它之外，您不能減慢線程的速度。你可以玩線程優先級，但這只是改變線程的排序順序。這可能會減慢線程的速度，但只有在優先級較高的線程佔用全部運行時間的情況下。
你需要的是某種形式的作品數量調節的，而不是一個工作速度調節器。也就是說，試圖只做底層機器可以完成的工作。你可能想看看ZeroMQ：這將是一個很大的體系結構變化（一開始就是異步的），但堅持一會兒。
用ZeroMQ編程是Actor模型;線程向下傳遞套接字，這就像消息隊列一樣。美麗之處在於，這些套接字的方式不僅僅是點對點鏈接;也有模式。例如，您可能有8個線程正在進行照明。您可以通過一個PUSH/PULL套接字將照明請求發送給這些人;可用的那個將會選擇該消息並處理它。您還可以配置該套接字，以便如果達到高水位標記（燈光線程沒有跟上），則新的燈光請求消息將取代隊列中的舊燈光請求消息（燈光線程只會處理儘可能多的實際情況，偏差對最新的）。
而插座可以去網絡連接上了。您可以在幾臺計算機上分發它，而幾乎沒有任何代碼更改。
有這個建議我的問題：你會連載和deserialising對象非常多。你會撕毀現有的架構。但是您將利用通信框架來分發，擴展並以有用的方式實現負載平衡和隊列管理。嘗試一下會很有趣！
編輯迴應評論
有一件事我能想到的是一個時間的日提交字段添加到照明要求，並具有照明線（S）計算初始之間的時間每個請求的提交以及完成處理的時間。這個執行時間測量可用於更新所有燈光線程的平均完成時間值（將其放置在由互斥鎖守護的共享內存中，或類似的東西）。
事情提交照明的要求，然後可以參考這個平均水平，如果它的增加，應該在速度趨緩。同樣，如果平均處理時間在減少，它可能會提高速度。如果計算機本身開始忙於在後臺執行其他操作，則會適應執行時間的短缺。
實際上，這是建築照明處理分析到應用程序，餵養回提交者，並且是多麼每秒許多照明請求可以不下降太落後了提交執行過程中學習。
這將有保證隊列本身並沒有太充分和無限增長的副作用。它並沒有將隊列限制在任何特定的長度上，但是它限制了隊列前後之間的時間。所以在一臺速度更快的機器上，隊列的平均時間會更長，而更慢的機器上的時間會更短。在CPU的
當然
熱管理，一個「快」和「慢」電腦的定義是有點這幾天複雜。如果確定需要大量運行時間，現代英特爾/ AMD CPU（以及大量的ARM）將提高其時鐘頻率。所以當CPU需要Turbo模式時，可以持續的照明請求速率將會增加，提高時鐘頻率，運行速度更快。因此，通過適應在達到時間目標時可以維持的速率（即保持平均完成時間合理），您的代碼將會利用CPU的更高速度，因爲它適應了您要求的工作負載做。
你需要小心一點，雖然;不斷變化的時鐘速度並不是瞬間的 - 我看到300毫秒的延遲，在整個機器的任何地方都沒有發生任何事情 - 當它們發生時，看起來所有事物都突然花費了300毫秒。這就是爲什麼需要「平均」完成時間的原因 - 它會消除測量中的波動。
獲得的平均權將此事太長度，否則你會陷入這樣一種情況：你的代碼的CPU和CPU的時鐘頻率上的需求將oscilate：
而且你將要步入正軌的工作量，即使平均完成時間已經達到穩定。如果這樣做可以推動CPU提高其時鐘頻率，並且可以完成更多的照明請求，而不會影響完成時間。
基本上要被增加的工作量，且僅減少它，如果等待時間實際上增加，但在時間尺度比CPU本身的熱管理/時鐘管理週期較慢這樣做。
如何解決內存泄漏的情況下，如果隊列增長更快，那麼它正在處理？
在這種情況下，增加內存佔用空間可能是您最小的問題。
是否有強制線程獲得更多時間或阻塞，直到隊列長度低於一定長度的技術？
Java線程可以優先化，但如果導致可觀察到的效果，則它非常依賴於底層操作系統。
除了上述內容之外，很難提供幫助 - 您會看到，因爲這非常依賴於架構/實現的細節。我會考慮如下問題：
你看 - 看起來你不能影響你的系統流入的事件數爲。所以你只需要設計一個解決方案，爲該流程工作。這是一個特定的問題，需要你坐下來，簡介你的主題，例如：瞭解他們在哪裏以及如何度過他們的時間。例如，結論可能是，執行這些計算的機器沒有足夠的馬力。但是你必須做的事情。
如果異步負荷增長太多，我們有可能拖慢遊戲處理/滴答速度，沒有達到內存限制。我們無法直接控制需要生成的照明更新數量，但我們可能會放慢「主要」線程，以便再次將隊列處理爲可管理的數量，即做一些*同步*照明更新。我希望看到指向某種資源的鏈接，該資源描述了一些可能支持此功能的模式/隊列/體系結構設計。 –
感謝您的回答，我很欣賞對學習目的的迴應，但不幸的是，引入新框架並不是真正的解決方案，因爲我們正在修補和逆向設計基本的Minecraft遊戲。 你有關於工作量調節裝置VS的工作速度調節器，將需要最少干預的標準Java8線程處理，或將有適當的集合/線程/執行人也許有些圖書館的進一步信息？ –
@RyanTheLeach不用擔心。我在自我分析的基礎上增加了一個想法，直到答案結尾，這應該很好地適應標準的Java線程/互斥/共享內存。祝你好運！ – bazza
**可愛的閱讀，@ bazza **（一如既往）。除了CPU硬連線散熱管理之外，最近人們還應該注意主板實現的「外部」電源衝擊影響，觀察這些影響是爲了解決極端HPC基礎架構中的問題（對需要電源的關鍵部分進行右調整具有不利影響在最大限度上，而不是「綠色」 - 生態恐怖主義導致的惡化......有趣的是，LLNL HPC專家找到一種方法來應對這種新型外型系統性能殺手「幽靈」 「）。 – user3666197