從記憶體角度來看，永遠不可能。除非自己回收管理。記憶體交給系統管理，他必須將現有執行緒工作內容搬遷到新的地方去。假設記憶體無限大，系統執行緒隨著在空閒記憶體上覆制一模一樣的資料和大小，那麼GC暫停將會在一瞬間完成遷移。不過意義就是空間和拷貝的浪費。

理論來說不停頓就會影響程式本身的吞吐量，因為如果gc執行緒全階段和應用程式執行緒併發的話就會搶佔CPU資源。

其實個人認為是可以做到的，但有沒有必要就視情況而定了。譬如zgc本身停頓時間一般就在十到幾十毫秒左右，如果gc roots不是特別多的話，其實這時間已經算非常短了，也基本能滿足比較苛刻的需求了。

其實你可以換個角度想，如果全程併發gc其實回收效率並不會有stw高，而垃圾回收率不該就意味著簡介地增加了gc的次數，所以我個人認為適當的stw還是有一定需要的，因此即使研發出了感覺也不會有多大改變，因為調優本身都是等價交換的思想，即得到了併發就降低吞吐量。

除非硬體以後發展到非常強大（或遠超應用程式所需的資源）否則不可能改變這現象。因為軟體到瓶頸後還是得看硬體效能

從某種意義上來說，即使不gc，世界也是無時無刻都在暫停，因為效能不是無限的，執行每一個操作都需要時間，等待操作完成和暫停世界沒有本質區別，如果可以讓gc的時間足夠短，那gc的時間就可以忽略了

現在ibm已經有gc時間非常非常非常短的演算法了，主要缺點是費記憶體

暫停是因為需要凍結當前的記憶體狀態，來判斷哪些記憶體是可以gc的…一直處於動態的記憶體分配狀態下，gc是難以實現的…只能儘可能降低這個時間，但不能完全消滅…你gc演算法執行需要時間，只要要保障這段時間內記憶體不能變動。

Java和golang的最新的gc處理耗時已經極低了，又想有gc，又不想暫停世界，可能比較困難。

如果想智慧回收記憶體，可以選擇rust，思路是所有權機制。

所謂所有權機制，就是任何記憶體都是有主的，由主人自己在銷燬的時候來釋放，別人想使用不屬於自己的記憶體，需要通過借用來實現，借出去的東西必須還回來。

然後在編譯階段保證所有權機制的安全，不允許出現有借無還的情況。

這是一種新的語言，新的程式設計思想，你可以研究一下。