Memory management 为什么要在web应用程序中进行垃圾收集？

考虑在一个平台上构建一个web应用程序，在这个平台上，每个请求都由用户级别的ThreadULT green thread/erlang process/goroutine/…处理。。。任何轻量的线。假设每个请求都是无状态的，并且在应用程序启动时获得数据库连接之类的资源，并在这些线程之间共享。这些线程中的垃圾收集需要什么

一般来说，这样的线程运行时间很短，只有几毫秒，如果设计得当，不会占用超过几KB或MB的内存。如果对线程中分配的资源进行垃圾收集是在线程的出口处完成的，并且与其他线程无关，那么即使是第98个或第99个百分位的请求也不会有GC暂停。所有请求都将在可预测的时间内得到答复

---

这种模式有什么问题？为什么没有被广泛使用

你的假设可能不是真的

如果设计良好，则不会使用超过几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

---

它分配的内存比文本大。

可能是因为在实际应用程序中没有满足这些假设？erlang具有每个erlang进程的GC绿色线程，因此，如果每个请求都在一个进程上处理，而该进程没有被重用，则可以调整每个进程的GC设置，这样，除非该进程使用非常大的内存，否则不太可能执行GC内存量。首先要查看的设置是最小堆大小和之后的完全扫描。说任何erlang GC都不是一个世界站，因此只会影响该进程上请求的延迟。我知道这可以在erlang中完成，但我想知道为什么这样做不受欢迎，以及这样做是否有任何负面影响。大多数面向用户的web应用通常会接收请求、从db检索或写入db，返回响应，请求完成。这个假设对于这样的应用程序是有效的，我上面建议的模型只会对延迟敏感的应用程序有利。我无法想象一个对每个请求执行大量处理的应用程序会对延迟敏感，因此不会从这个模型中受益。@Sacheendrataluri确实如此。然而，拥有一个天真的标记和扫描gc不会有任何伤害。如果最大堆大小大于工作负载大小，则gc不会启动。否则，如果没有提供gc，程序必须停止。