爲什麼垃圾收集在網絡應用程序？

考慮在平臺上構建Web應用程序，每個請求由用戶級線程（ULT）（綠色線程/ erlang進程/ goroutine/...任何輕量級線程）處理。假設每個請求都是無狀態的，並且在應用程序啓動時獲得數據庫連接等資源，並在這些線程之間共享。這些線程中垃圾收集的需求是什麼？爲什麼垃圾收集在網絡應用程序？

通常，這樣的線程運行時間很短（幾毫秒），如果設計良好的話不會使用超過幾個（KB或MB）的內存。如果線程中分配的資源的垃圾收集在線程的出口處完成並且獨立於其他線程，則即使第98或第99百分位的請求也不會發生GC暫停。所有請求都會在可預測的時間內回答。

這樣的模型有什麼問題，爲什麼它沒有被廣泛使用？

來源

2015-01-15 Sacheendra Talluri

也許是因爲這些假設在現實世界的應用程序中沒有實現？ – Volker

erlang每個erlang進程都有GC（綠色線程），所以如果每個請求都在一個沒有重用的進程上處理，您可以調整GC設置（每個進程），這樣除非進程使用了大量的GC的記憶。首先要看的設置是min_heap_size和full_sweep_after。說任何erlang GC都不是世界的停止，所以只會影響該進程的請求延遲。 –

我知道這可以在erlang中完成，但我想知道爲什麼這樣做不流行，並且有沒有這樣做的負面影響。 –

您的假設可能並非如此。

如果精心設計不使用的內存超過

數（KB或MB）更多想象的功能在其在Web應用程序中使用的文本文件字數統計。一些天真的實現可能是，

def count_words(text): 
    words = text.split() 
    count = {} 
    for w in words: 
     if w in count: 
      count[w] += 1 
     else: 
      count[w] = 1 
    return count

它分配比文本更大的內存。

來源

2015-01-15 08:56:15 woodings

大多數面向Web應用程序的用戶通常會收到請求，從數據庫中檢索或寫入數據庫，返回響應並完成請求。這個假設對於這樣一個應用程序是有效的，而我上面建議的模型只會對延遲敏感的應用程序有利。我無法想象每個請求執行大量處理的應用程序對延遲敏感，因此不會受益於此模型。 –

@SacheendraTalluri的確如此。然而，有一個天真的標誌和掃描GC不會傷害。如果最大堆大小大於工作負載大小，gc將不會啓動。否則，如果未提供gc，程序必須停止。 – woodings

爲什麼垃圾收集在網絡應用程序？

回答

相關問題