Gc on Tarragon

3.1 GC 與 memory limit

Wed, 22 Apr 2026 00:00:00 +0000

GC 與 memory limit 的核心關係是：Go runtime 會根據 heap 成長決定何時執行 GC，而 memory limit 讓 runtime 有一個軟性記憶體目標。Memory limit 不是硬性上限，也不是 leak 修復工具；它是讓 runtime 更早回應記憶體壓力的控制訊號。

本章目標

學完本章後，你將能夠：

理解 heap growth、GOGC 與 GC 頻率的關係
判斷 debug.SetMemoryLimit 能解決什麼、不能解決什麼
從環境變數設定服務 memory limit
用 runtime metrics 觀察調整效果
分辨 GC 壓力、長期保留與真正 leak

【觀察】長時間服務的記憶體問題通常是趨勢問題

記憶體診斷的核心觀察是趨勢。Heap 是否持續上升、GC 後是否下降、goroutine 是否增加、某個操作後是否留下無法回收的資料，這些都比「現在用了多少 MB」更重要。

常見現象：

啟動後 heap 穩定在某個區間：通常正常。
每次高峰後 heap 都能下降：可能是短暫配置。
GC 後 heap 仍持續上升：可能有長期保留或 leak。
GC 次數快速增加且 CPU 升高：可能是 allocation 壓力。
goroutine 與 heap 同時增加：可能是 goroutine leak 或 send buffer 堆積。

Memory limit 可以幫 runtime 更積極控制 heap，但不能替代趨勢判讀。

【判讀】GC 控制的是 heap 成長

Go GC 的核心目標是回收不再被引用的 heap 物件。Runtime 會根據 GOGC 控制下一次 GC 觸發點。

1GOGC=100 go run ./cmd/server

GOGC=100 大致表示 heap 在上次 GC 後成長約 100% 時觸發下一次 GC。數字越小，GC 越頻繁，記憶體通常較低但 CPU 成本較高；數字越大，GC 較少，記憶體通常較高但 CPU 成本較低。

這是取捨，不是調大或調小就一定更好。CPU 緊繃的服務可能不能承受過低 GOGC；記憶體緊繃的服務可能不能承受過高 GOGC。

【判讀】memory limit 是 runtime 軟目標

debug.SetMemoryLimit 的核心用途是告訴 Go runtime 希望整體記憶體使用量靠近某個目標。當 runtime 接近目標時，會更積極回收 heap。

1func configureRuntime() {
2    const limit = 512 << 20 // 512 MiB
3    debug.SetMemoryLimit(limit)
4}

這不是作業系統層級的硬限制。程式仍可能短暫超過這個值，特別是有大量非 Go heap 記憶體、cgo、mmap、大型 byte slice 尖峰或外部 library 配置時。

Memory limit 適合容器、桌面常駐服務、背景 worker、WebSocket server 這類需要避免吃掉過多資源的服務。若部署平台已有 memory limit，Go runtime 的 limit 通常應略低於平台限制，留給非 Go heap 與系統開銷。

【執行】設定值應來自部署環境

Memory limit 的核心配置原則是由部署環境決定，而不是寫死在 library 裡。應用入口可以讀取環境變數，解析後設定 runtime。

 1func ConfigureMemoryLimitFromEnv() error {
 2    raw := os.Getenv("APP_MEMORY_LIMIT_MB")
 3    if raw == "" {
 4        return nil
 5    }
 6
 7    mb, err := strconv.Atoi(raw)
 8    if err != nil {
 9        return fmt.Errorf("parse APP_MEMORY_LIMIT_MB: %w", err)
10    }
11
12    if mb <= 0 {
13        return fmt.Errorf("APP_MEMORY_LIMIT_MB must be positive")
14    }
15
16    debug.SetMemoryLimit(int64(mb) << 20)
17    return nil
18}

錯誤應在啟動時明確失敗。服務若用錯誤設定悄悄運行，後續記憶體行為會很難解釋。

【策略】runtime metrics 用來看調整是否有效

Runtime metrics 的核心用途是驗證調整效果。只改 GOGC 或 memory limit，不看 heap 與 GC 趨勢，容易變成憑感覺調參。

簡單方式可以用 runtime.ReadMemStats：

1func ReadHeapAlloc() uint64 {
2    var stats runtime.MemStats
3    runtime.ReadMemStats(&stats)
4    return stats.HeapAlloc
5}

較完整的服務可以使用 runtime/metrics：

1func ReadRuntimeSamples() []metrics.Sample {
2    samples := []metrics.Sample{
3        {Name: "/memory/classes/heap/objects:bytes"},
4        {Name: "/gc/cycles/total:gc-cycles"},
5        {Name: "/sched/goroutines:goroutines"},
6    }
7    metrics.Read(samples)
8    return samples
9}

觀察時要看趨勢：調整後 heap 峰值是否下降、GC 次數是否合理、CPU 是否上升、goroutine 是否仍持續增加。

【判讀】memory limit 不能修正仍被引用的資料

Memory limit 的核心邊界是它只能影響 GC 行為，不能讓仍被引用的物件消失。若程式把資料一直留在 map、slice、cache、goroutine 或 send buffer 裡，GC 不能回收。

1var cache = map[string][]byte{}
2
3func SavePayload(id string, payload []byte) {
4    cache[id] = payload
5}

如果 cache 沒有大小限制、TTL 或刪除策略，memory limit 只會讓 GC 更常跑，但資料仍被 cache 引用。真正修正是設計 cache 淘汰、分頁、快照大小限制或資料釋放路徑。

因此遇到 heap 持續上升時，下一步是用 pprof 確認誰保留了記憶體。

【策略】判斷是 GC 壓力還是長期保留

記憶體問題的核心分流是：物件被大量配置但很快回收，還是物件被長期保留。

現象	可能問題	下一步
`alloc_space` 高，`inuse_space` 不高	短命配置多，GC 壓力大	找熱路徑 allocation
`inuse_space` 持續上升	長期保留或 leak	看 heap profile retainers
goroutine 數量同步上升	goroutine leak 或 queue 堆積	看 goroutine profile
GC 次數暴增但 heap 仍高	memory limit 壓力或資料保留	檢查 cache/map/buffer

這個分流會決定後續工具。GC 參數能緩解壓力，但保留資料要回到資料結構與 lifecycle 修。

【測試】runtime 設定函式可以獨立測解析

Runtime 本身不需要在單元測試中反覆調參。應把環境解析邏輯獨立出來，測試輸入與錯誤即可。

 1func ParseMemoryLimitMB(raw string) (int64, error) {
 2    if raw == "" {
 3        return 0, nil
 4    }
 5    mb, err := strconv.Atoi(raw)
 6    if err != nil {
 7        return 0, fmt.Errorf("parse memory limit: %w", err)
 8    }
 9    if mb <= 0 {
10        return 0, fmt.Errorf("memory limit must be positive")
11    }
12    return int64(mb) << 20, nil
13}

測試：

1func TestParseMemoryLimitMB(t *testing.T) {
2    got, err := ParseMemoryLimitMB("512")
3    if err != nil {
4        t.Fatalf("parse memory limit: %v", err)
5    }
6    if got != 512<<20 {
7        t.Fatalf("limit = %d, want %d", got, int64(512<<20))
8    }
9}

這讓設定邏輯可測，而不需要在每個測試中真的改 runtime 狀態。

本章不處理

本章先處理單一 Go process 如何判讀 heap、GC 與 memory limit；平台 OOM 與部署合約，會在下列章節再往外延伸：

和 Go 教材的關係

這一章承接的是 runtime 壓力、allocation 與 pprof 診斷；如果你要先回看語言教材，可以讀：

小結

GC 控制 heap 回收節奏，memory limit 給 runtime 一個記憶體軟目標。合理設定能降低長時間服務的資源風險，但不能修正 cache、map、slice、goroutine 或 buffer 長期持有資料。診斷時先看趨勢，再用 pprof 區分 GC 壓力與長期保留。

3.2 記憶體管理與垃圾回收

Tue, 20 Jan 2026 00:00:00 +0000

Python 的記憶體管理結合了參考計數和分代垃圾回收。理解這些機制有助於寫出更高效的程式碼。

先備知識

3.1 PyObject 與物件模型

本章目標

學完本章後，你將能夠：

理解參考計數的限制
理解分代垃圾回收的原理
使用 __slots__ 優化記憶體
使用 tracemalloc 分析記憶體使用

【原理層】記憶體模型

Stack vs Heap

Python 的記憶體分為兩個主要區域：

 1┌─────────────────────────────────────┐
 2│              Stack                   │
 3│  ┌─────────────────────────────────┐│
 4│  │ 變數名稱 → 指向 Heap 的指標      ││
 5│  │ a ──────→ [指標]                ││
 6│  │ b ──────→ [指標]                ││
 7│  └─────────────────────────────────┘│
 8└─────────────────────────────────────┘
 9                 │
10                 ▼
11┌─────────────────────────────────────┐
12│              Heap                    │
13│  ┌─────────────────────────────────┐│
14│  │ PyObject: [1, 2, 3]             ││
15│  │ PyObject: "hello"               ││
16│  │ PyObject: 42                    ││
17│  └─────────────────────────────────┘│
18└─────────────────────────────────────┘

Stack：儲存變數名稱和指標（參考）
Heap：儲存實際的 Python 物件

Python 的記憶體分配器

CPython 使用分層的記憶體分配器：

 1┌─────────────────────────────────────┐
 2│     Python 物件分配器               │
 3│     (PyObject_Malloc)               │
 4├─────────────────────────────────────┤
 5│     Python 記憶體分配器             │
 6│     (PyMem_Malloc)                  │
 7├─────────────────────────────────────┤
 8│     C 標準函式庫                    │
 9│     (malloc)                        │
10├─────────────────────────────────────┤
11│     作業系統                        │
12└─────────────────────────────────────┘

對於小於 512 bytes 的物件，Python 使用自己的分配器來減少系統呼叫。

【設計層】循環參考問題

參考計數的限制

參考計數無法處理循環參考：

 1import gc
 2
 3class Node:
 4    def __init__(self, name):
 5        self.name = name
 6        self.ref = None
 7
 8# 建立循環參考
 9a = Node("A")
10b = Node("B")
11a.ref = b
12b.ref = a
13
14# 刪除外部參考
15del a
16del b
17
18# 此時 A 和 B 仍互相參考，參考計數都是 1
19# 但它們已經無法被存取了（垃圾）

1刪除前：
2外部 ─→ A ←──→ B ←─ 外部
3        refcnt=2  refcnt=2
4
5刪除後：
6        A ←──→ B
7        refcnt=1  refcnt=1
8        （無法被存取，但參考計數不為 0）

分代垃圾回收

為了解決循環參考，Python 使用分代垃圾回收：

 1import gc
 2
 3# 查看 GC 統計
 4print(gc.get_count())  # (700, 10, 0) - 各代的物件數
 5
 6# 三個世代（Python 3.12 以前）
 7# Generation 0: 新物件
 8# Generation 1: 存活過一次 GC 的物件
 9# Generation 2: 存活過多次 GC 的物件
10
11# Python 3.12+ 改為四個世代
12# Young generation (1 代)
13# Old generations (2 代)
14# Permanent generation (永久)

GC 觸發時機

 1import gc
 2
 3# 查看閾值
 4print(gc.get_threshold())  # (700, 10, 10)
 5
 6# 意義：
 7# - 當 Generation 0 有 700 個物件時，觸發 Gen 0 GC
 8# - 當 Gen 0 GC 執行 10 次後，觸發 Gen 1 GC
 9# - 當 Gen 1 GC 執行 10 次後，觸發 Gen 2 GC
10
11# 手動觸發 GC
12gc.collect()
13
14# 設定閾值
15gc.set_threshold(1000, 15, 15)

【實作層】記憶體優化

使用 slots

__slots__ 可以顯著減少物件的記憶體使用：

 1import sys
 2
 3class WithoutSlots:
 4    def __init__(self, x, y):
 5        self.x = x
 6        self.y = y
 7
 8class WithSlots:
 9    __slots__ = ['x', 'y']
10
11    def __init__(self, x, y):
12        self.x = x
13        self.y = y
14
15obj1 = WithoutSlots(1, 2)
16obj2 = WithSlots(1, 2)
17
18print(sys.getsizeof(obj1))  # 48
19print(sys.getsizeof(obj2))  # 48（但沒有 __dict__）
20
21# 實際差異在 __dict__
22print(sys.getsizeof(obj1.__dict__))  # 104
23# obj2 沒有 __dict__

為什麼 `slots` 省記憶體？

 1沒有 __slots__：
 2┌─────────────────────────┐
 3│ PyObject header (16 B)  │
 4│ __dict__ 指標 (8 B)      │
 5│ __weakref__ 指標 (8 B)   │
 6│ __dict__ → { 'x': 1,    │
 7│              'y': 2 }   │
 8│            （額外 100+ B）│
 9└─────────────────────────┘
10
11有 __slots__：
12┌─────────────────────────┐
13│ PyObject header (16 B)  │
14│ x (8 B)                 │
15│ y (8 B)                 │
16└─────────────────────────┘

slots 的限制

 1class Base:
 2    __slots__ = ['x']
 3
 4class Derived(Base):
 5    __slots__ = ['y']  # 不能與父類別重複
 6
 7    def __init__(self):
 8        self.x = 1
 9        self.y = 2
10        # self.z = 3  # 錯誤！沒有 __dict__
11
12# 如果需要動態屬性，加入 '__dict__'
13class Flexible:
14    __slots__ = ['x', '__dict__']

使用弱參考

弱參考不增加參考計數，適合用於快取：

 1import weakref
 2
 3class ExpensiveObject:
 4    def __init__(self, value):
 5        self.value = value
 6
 7# 建立物件和弱參考
 8obj = ExpensiveObject(42)
 9weak_ref = weakref.ref(obj)
10
11print(weak_ref())  # 
12print(weak_ref().value)  # 42
13
14# 刪除強參考
15del obj
16
17print(weak_ref())  # None（物件已被回收）

使用 WeakValueDictionary 實作快取

 1import weakref
 2
 3class Cache:
 4    def __init__(self):
 5        self._cache = weakref.WeakValueDictionary()
 6
 7    def get(self, key, factory):
 8        value = self._cache.get(key)
 9        if value is None:
10            value = factory()
11            self._cache[key] = value
12        return value
13
14cache = Cache()
15
16def create_expensive():
17    return ExpensiveObject(100)
18
19obj = cache.get('key1', create_expensive)
20# 當 obj 不再被使用時，快取會自動清理

【實作層】記憶體分析工具

使用 tracemalloc

 1import tracemalloc
 2
 3# 開始追蹤
 4tracemalloc.start()
 5
 6# 執行程式碼
 7data = [i ** 2 for i in range(10000)]
 8more_data = {str(i): i for i in range(10000)}
 9
10# 取得記憶體快照
11snapshot = tracemalloc.take_snapshot()
12
13# 顯示前 10 個記憶體使用最多的位置
14top_stats = snapshot.statistics('lineno')
15for stat in top_stats[:10]:
16    print(stat)
17
18# 比較兩個快照
19tracemalloc.start()
20snapshot1 = tracemalloc.take_snapshot()
21
22# 執行更多程式碼
23big_list = list(range(100000))
24
25snapshot2 = tracemalloc.take_snapshot()
26diff = snapshot2.compare_to(snapshot1, 'lineno')
27
28for stat in diff[:5]:
29    print(stat)

使用 gc 模組除錯

 1import gc
 2
 3# 啟用除錯
 4gc.set_debug(gc.DEBUG_LEAK)
 5
 6# 找出無法回收的物件
 7gc.collect()
 8print(gc.garbage)  # 無法回收的物件列表
 9
10# 取得所有被追蹤的物件
11all_objects = gc.get_objects()
12print(f"被追蹤的物件數量: {len(all_objects)}")
13
14# 找出特定類別的實例
15class MyClass:
16    pass
17
18instances = [obj for obj in gc.get_objects() if isinstance(obj, MyClass)]
19print(f"MyClass 實例數量: {len(instances)}")

檢測記憶體洩漏

 1import gc
 2import tracemalloc
 3
 4def find_memory_leak():
 5    tracemalloc.start()
 6
 7    # 記錄初始狀態
 8    gc.collect()
 9    snapshot1 = tracemalloc.take_snapshot()
10
11    # 執行可能洩漏的程式碼
12    for _ in range(1000):
13        suspicious_function()
14
15    # 記錄最終狀態
16    gc.collect()
17    snapshot2 = tracemalloc.take_snapshot()
18
19    # 比較
20    diff = snapshot2.compare_to(snapshot1, 'lineno')
21
22    print("記憶體增長最多的位置：")
23    for stat in diff[:10]:
24        print(stat)

【實戰】常見記憶體問題

問題 1：大量小物件

 1# 不好：建立大量小物件
 2class Point:
 3    def __init__(self, x, y):
 4        self.x = x
 5        self.y = y
 6
 7points = [Point(i, i) for i in range(1000000)]
 8
 9# 好：使用 __slots__
10class Point:
11    __slots__ = ['x', 'y']
12    def __init__(self, x, y):
13        self.x = x
14        self.y = y
15
16# 更好：使用 NumPy（如果是數值資料）
17import numpy as np
18points = np.zeros((1000000, 2))

問題 2：循環參考

 1# 不好：物件間的循環參考
 2class Parent:
 3    def __init__(self):
 4        self.children = []
 5
 6class Child:
 7    def __init__(self, parent):
 8        self.parent = parent
 9        parent.children.append(self)
10
11# 好：使用弱參考
12import weakref
13
14class Child:
15    def __init__(self, parent):
16        self.parent = weakref.ref(parent)
17        parent.children.append(self)

問題 3：全域變數累積

 1# 不好：全域快取無限增長
 2_cache = {}
 3
 4def process(key, value):
 5    if key not in _cache:
 6        _cache[key] = expensive_compute(value)
 7    return _cache[key]
 8
 9# 好：使用 LRU cache
10from functools import lru_cache
11
12@lru_cache(maxsize=1000)
13def process(key, value):
14    return expensive_compute(value)

思考題

為什麼 Python 需要同時使用參考計數和垃圾回收？只用其中一種不行嗎？
__slots__ 為什麼不能用於繼承自內建型別的類別？
在什麼情況下應該手動呼叫 gc.collect()？

實作練習

使用 tracemalloc 分析一個現有程式的記憶體使用
將一個使用大量物件的程式改用 __slots__ 優化
使用 WeakValueDictionary 實作一個自動清理的快取

延伸閱讀

上一章：PyObject 與物件模型 下一章：Bytecode 與虛擬機

模組三：Runtime 與效能診斷

Wed, 22 Apr 2026 00:00:00 +0000

Runtime 診斷的核心目標是用資料判斷服務壓力來源。Go 服務長時間運行後，問題常出現在 heap 成長、GC 壓力、goroutine 數量、WebSocket buffer 堆積、JSON 配置與共享狀態保留；診斷流程應先看趨勢，再用 profile 定位來源。

本模組承接前面的並發、WebSocket 與測試可靠性：如果 goroutine lifecycle、send buffer、repository copy boundary 沒設計好，runtime 訊號會在 heap profile、goroutine profile、CPU profile 或 allocation profile 中反映出來。

章節列表

章節	主題	關鍵收穫
3.1	GC 與 memory limit	理解 heap、GOGC、memory limit 與 runtime metrics 的關係
3.2	pprof 基礎診斷流程	用 heap、goroutine、CPU、trace profile 定位壓力來源
3.3	goroutine leak 偵測	從 stack pattern 回到 context、close、deadline 與 ticker lifecycle
3.4	資料結構與 allocation 壓力	區分必要 copy、安全邊界與可優化熱路徑配置

本模組使用的範例主題

本模組使用虛構的即時通知服務作為範例。範例包含 WebSocket client lifecycle、background worker、repository list、JSON push payload 與 cache。

範例只用來展示 Go runtime 診斷方法，不假設讀者正在維護任何特定專案。

本模組的 Go 核心概念

用 runtime.ReadMemStats 或 runtime/metrics 觀察 heap、GC 與 goroutine 趨勢。
用 debug.SetMemoryLimit 給 runtime 軟性記憶體目標。
用 pprof 分析 heap、goroutine、CPU、block、mutex 與 trace。
用 goroutine profile 找出卡在 channel、network read、ticker、mutex 的路徑。
用 alloc_space 與 inuse_space 區分配置壓力與保留記憶體。
用資料結構設計降低不必要 allocation，但保留必要 copy boundary。

學習重點

學完本模組後，你應該能判斷：

記憶體問題是 GC 壓力、長期保留，還是短暫尖峰
什麼情境適合調整 memory limit，什麼情境應該找 leak
heap、goroutine、CPU、trace 各自回答什麼問題
goroutine leak 應回到哪個 lifecycle 邊界修
allocation 優化何時值得做，何時會破壞安全邊界

本模組不處理

本模組不討論分散式 tracing 平台、完整監控系統或雲端特定 profiler。這些工具可以接在本模組之後；本模組先建立 Go runtime 原生訊號與 pprof 的診斷思路。後續可接 Observability pipeline、metrics 與 tracing。

3.4 資料結構與 allocation 壓力

Wed, 22 Apr 2026 00:00:00 +0000

Allocation 分析的核心目標是區分必要的安全複製與可優化的重複配置。Go 服務中很多配置來自 slice 成長、map/list 複製、JSON marshal、buffer 建立與 WebSocket payload；優化前要先確認配置是否位於熱路徑，且不能破壞狀態邊界。

本章目標

學完本章後，你將能夠：

理解 allocation 如何增加 GC 壓力
分辨必要 copy boundary 與不必要重複配置
用預配置降低 slice 成長成本
判斷 JSON marshal 與 WebSocket payload 的重用邊界
用 pprof 的 alloc_space 與 inuse_space 決定優化方向

【觀察】allocation 壓力會放大 GC 成本

Allocation 的核心影響是增加 heap 成長速度，進而增加 GC 工作量。即使物件很快被回收，大量短命配置仍可能造成 CPU 與 latency 壓力。

常見熱路徑：

每次 WebSocket broadcast 都對每個 client 重新 marshal。
每次 API list 都建立大型 slice。
每次 repository 查詢都 copy 大型 map。
每次 log 都組大量臨時欄位。
每次 encode 都建立新的 bytes.Buffer。

不是所有 allocation 都要消除。診斷重點是找出高頻、可避免、且不破壞邊界的配置。

【判讀】預配置解決的是成長成本

Slice 預配置的核心用途是讓底層 array 成長符合預期。若結果長度可預估，應用 make 設定容量。

未預配置：

1func BuildNames(users []User) []string {
2    var names []string
3    for _, user := range users {
4        names = append(names, user.Name)
5    }
6    return names
7}

預配置：

1func BuildNames(users []User) []string {
2    names := make([]string, 0, len(users))
3    for _, user := range users {
4        names = append(names, user.Name)
5    }
6    return names
7}

這不是微優化。若這段程式在高頻 list API、background projection 或 broadcast path 中執行，預配置可以減少反覆擴容與 copy。

【判讀】copy boundary 是必要成本

安全複製的核心目的是保護內部可變狀態。Repository 回傳資料時 copy slice 或 map，會增加 allocation，但能避免外部突變與 data race。

 1func (r *UserRepository) ListUsers(ctx context.Context) ([]User, error) {
 2    r.mu.RLock()
 3    defer r.mu.RUnlock()
 4
 5    users := make([]User, 0, len(r.users))
 6    for _, user := range r.users {
 7        users = append(users, user)
 8    }
 9    return users, nil
10}

這個 allocation 是狀態邊界的成本。優化前要先確認它是否真的是瓶頸，不能只因為 profile 看到配置就移除 copy。

若列表很大且讀取頻繁，應考慮分頁、projection、snapshot cache 或只回傳必要欄位。不要為了省配置而直接暴露內部 map。

【策略】大型 list 優先改資料形狀

大型 list allocation 的核心問題常常是 API 一次回太多資料。若每次請求都複製整個 repository，配置與延遲都會隨資料量線性成長。

可選策略：

策略	適用情境	代價
分頁	使用者只需要部分資料	API 需要 cursor 或 offset
projection	只需要摘要欄位	要維護讀取模型
snapshot cache	讀多寫少	要處理快取失效
incremental update	WebSocket 推送最新變化	client 要能合併狀態

優化資料形狀通常比取消 copy 更安全。Copy boundary 保護正確性，資料形狀決定每次 copy 的成本。

【執行】JSON marshal 是 WebSocket 常見配置來源

JSON 序列化的核心成本是把 Go 資料結構轉成 bytes。高頻 WebSocket 推送若對每個 client 反覆 marshal 同一份 message，會造成大量短命配置。

反模式：

1for _, client := range clients {
2    payload, err := json.Marshal(message)
3    if err != nil {
4        return err
5    }
6    client.SendBytes(payload)
7}

同一份 message 可以先 marshal 一次：

1payload, err := json.Marshal(message)
2if err != nil {
3    return err
4}
5
6for _, client := range clients {
7    client.SendBytes(payload)
8}

這個優化的前提是 payload 被視為只讀。Send path 不應修改傳入的 bytes；若某個 client 需要修改，就應在該 client 邊界 copy，而不是讓共享 payload 被改動。

【判讀】bytes 重用要先定義所有權

Bytes 重用的核心風險是共享 slice 被修改。[]byte 是可變資料，傳給多個 client 時要明確規定它只讀。

可以用型別或註解表達語意：

1type EncodedMessage []byte
2
3func (c *Client) SendEncoded(message EncodedMessage) bool {
4    return c.TrySend(ServerMessage{
5        Encoded: message,
6    })
7}

這不能從型別上完全禁止修改，但能讓 API 語意更清楚。真正保護仍靠 ownership 規則、測試與 code review。

若無法保證下游不修改，就必須 copy：

1func CloneBytes(input []byte) []byte {
2    output := make([]byte, len(input))
3    copy(output, input)
4    return output
5}

效能優化不能建立在模糊的可變資料共享上。

【策略】sync.Pool 只適合已證明的熱路徑

sync.Pool 的核心用途是複用高頻、短命、可重建的暫存物件。它可以降低配置，但會增加所有權複雜度。

 1var bufferPool = sync.Pool{
 2    New: func() any {
 3        return new(bytes.Buffer)
 4    },
 5}
 6
 7func Encode(value any) ([]byte, error) {
 8    buf := bufferPool.Get().(*bytes.Buffer)
 9    defer bufferPool.Put(buf)
10    buf.Reset()
11
12    if err := json.NewEncoder(buf).Encode(value); err != nil {
13        return nil, err
14    }
15
16    output := append([]byte(nil), buf.Bytes()...)
17    return output, nil
18}

這裡仍然 copy 出 output，因為 buf 會被放回 pool。若直接回傳 buf.Bytes()，呼叫端拿到的 slice 可能在 pool 重用後被覆寫。

不要一開始就使用 sync.Pool。先用 pprof 證明配置是瓶頸，再評估 pool 是否值得承擔額外複雜度。

【判讀】inuse 與 alloc 回答不同問題

Heap profile 的核心判讀是分清 inuse_space 與 alloc_space。

1go tool pprof http://localhost:8080/debug/pprof/heap
2go tool pprof -alloc_space http://localhost:8080/debug/pprof/heap

指標	問題	常見修正
`inuse_space` 高	現在誰保留記憶體	cache 淘汰、釋放引用、限制 buffer
`alloc_space` 高	誰累積配置最多	預配置、重用、減少 marshal、改資料形狀

若 alloc_space 高但 inuse_space 不高，代表配置很多但大多被回收，問題可能是 GC 壓力。若 inuse_space 持續上升，代表資料被長期保留，應檢查 cache、map、slice、goroutine reference 或 send buffer。

【策略】allocation 優化要保留正確性邊界

Allocation 優化的核心底線是不能破壞狀態安全。以下做法通常不可接受：

為了省 copy，直接回傳 repository 內部 map。
為了省 bytes，讓多個 client 共享可修改 payload。
為了省 allocation，把 buffer 放回 pool 後仍回傳其底層 slice。
為了少建立 struct，把 request DTO 和 domain state 混用。

較安全的優化順序：

用 pprof 確認熱點。
預配置已知大小的 slice/map。
減少重複 marshal。
改 API 資料形狀，例如分頁或 projection。
最後才考慮 sync.Pool。

這個順序先處理低風險、高可讀性的改動，再處理高複雜度工具。

【測試】優化後要補邊界測試

Allocation 優化的測試核心是確保共享資料沒有被外部修改。若你重用 bytes、snapshot 或 pooled buffer，要補測試保護 ownership。

例如 repository list 仍要回傳 copy：

 1func TestListUsersReturnsCopy(t *testing.T) {
 2    repo := NewUserRepository()
 3    ctx := context.Background()
 4    _ = repo.Save(ctx, User{ID: "user_1"})
 5
 6    users, err := repo.ListUsers(ctx)
 7    if err != nil {
 8        t.Fatalf("list users: %v", err)
 9    }
10    users[0].ID = "changed"
11
12    again, err := repo.ListUsers(ctx)
13    if err != nil {
14        t.Fatalf("list users again: %v", err)
15    }
16    if again[0].ID != "user_1" {
17        t.Fatalf("repository data was modified through returned slice")
18    }
19}

這種測試能防止未來為了省 allocation 而移除必要 copy。

本章不處理

本章先處理熱路徑上的配置與資料形狀；更大範圍的序列化與 payload 策略，會在下列章節再往外延伸：

和 Go 教材的關係

這一章承接的是 copy boundary、JSON 與 runtime profile；如果你要先回看語言教材，可以讀：

小結

Allocation 優化要先判斷配置是否必要。保護狀態的 copy 是合理成本，高頻熱路徑的重複配置才是優先目標。JSON marshal、slice 成長、map/list 複製與 buffer 建立都是常見來源；用 pprof 區分 inuse_space 與 alloc_space 後，再決定預配置、分頁、projection、payload 重用或 sync.Pool。

Gc on Tarragon

3.1 GC 與 memory limit

本章目標

【觀察】長時間服務的記憶體問題通常是趨勢問題

【判讀】GC 控制的是 heap 成長

【判讀】memory limit 是 runtime 軟目標

【執行】設定值應來自部署環境

【策略】runtime metrics 用來看調整是否有效

【判讀】memory limit 不能修正仍被引用的資料

【策略】判斷是 GC 壓力還是長期保留

【測試】runtime 設定函式可以獨立測解析

本章不處理

和 Go 教材的關係

小結

3.2 記憶體管理與垃圾回收

先備知識

本章目標

【原理層】記憶體模型

Stack vs Heap

Python 的記憶體分配器

【設計層】循環參考問題

參考計數的限制

分代垃圾回收

GC 觸發時機

【實作層】記憶體優化

使用 slots

為什麼 __slots__ 省記憶體？

slots 的限制

使用弱參考

使用 WeakValueDictionary 實作快取

【實作層】記憶體分析工具

使用 tracemalloc

使用 gc 模組除錯

檢測記憶體洩漏

【實戰】常見記憶體問題

問題 1：大量小物件

問題 2：循環參考

問題 3：全域變數累積

思考題

實作練習

延伸閱讀

模組三：Runtime 與效能診斷

章節列表

本模組使用的範例主題

本模組的 Go 核心概念

學習重點

本模組不處理

3.4 資料結構與 allocation 壓力

本章目標

【觀察】allocation 壓力會放大 GC 成本

【判讀】預配置解決的是成長成本

【判讀】copy boundary 是必要成本

【策略】大型 list 優先改資料形狀

【執行】JSON marshal 是 WebSocket 常見配置來源

【判讀】bytes 重用要先定義所有權

【策略】sync.Pool 只適合已證明的熱路徑

【判讀】inuse 與 alloc 回答不同問題

【策略】allocation 優化要保留正確性邊界

【測試】優化後要補邊界測試

本章不處理

和 Go 教材的關係

小結

為什麼 `slots` 省記憶體？