Go encoding/json.Decoder 资源没有释放为什么

Go encoding/json.Decoder 没有 Close 方法，也不会替你关闭传入的文件或 HTTP 响应体。解析完成只表示取得了一个 JSON 值：底层 Reader 的生命周期、Decoder 缓冲区的可达性和解码结果的保留，分别由相应的持有者负责。文件句柄持续增加时先找打开后未关闭的路径；内存增加时则要区分累计分配、仍存活的对象和进程 RSS。

官方文档：https://pkg.go.dev/encoding/json#Decoder

先把资源增长拆成可观察指标

设想一个批量导入任务：循环打开配置文件、建立 Decoder、读取一个对象。小文件时看不出问题，大批次后句柄越来越多，同时内存曲线升高。这里至少有两个独立假设：文件关闭被拖到外层函数返回；解析结果或解析器被长期保存。不能因为两条曲线同时变化，就认定 Decoder 自己启动了后台工作。

先固定输入文件数量、单个 JSON 大小、并发度、处理成功数与错误比例。句柄看同一阶段尚未关闭的文件数；内存看相同负载结束后的存活堆和持续引用，累计分配用于估算成本；RSS 用于描述操作系统看到的进程占用。本文给出诊断方法和原创代码，没有实际压测数据，不把预期效果写成测得的百分比。

明确 Decoder 与 Reader 的所有权

NewDecoder 接收 io.Reader，只约定读取能力。即使实际传入的是带 Close 的文件，Decoder 的公共 API 也不承担关闭责任。应用函数打开文件，就在该函数内安排关闭；只借用外部 Reader 的通用解析函数，应让调用方继续管理它，避免把共享连接或后续仍需读取的输入提前关掉。

对于 HTTP 客户端，成功取得响应后，调用方需要关闭 Response.Body。一次 Decode 成功不保证响应体已到 EOF，JSON 后面可能还有空白或额外数据。连接是否能复用还涉及协议及 Transport 行为，不能把 Body.Close 等同于立即关闭 TCP，也不能为了复用无上限地排空未知长度输入。当前官方文档还说明默认 Transport 在关闭时可能进行有保守上限的异步读取，业务仍应明确完成与关闭责任。

HTTP 响应体文档：https://pkg.go.dev/net/http#Response

把每个文件的生命周期封装进函数

批量循环里直接 defer f.Close，关闭动作会等到当前函数返回，可能让本已处理完的文件继续占用句柄。将单个文件的读取放进独立函数，让 defer 随每次调用结束执行。下面的 ReadConfig 自己打开和关闭文件；DecodeConfig 则只是借用 Reader，两种函数的责任不混用。示例使用 errors.Join，需要 Go 1.20 或更新版本。

package configio

import (
    "encoding/json"
    "errors"
    "fmt"
    "io"
    "os"
)

type Config struct {
    Name string `json:"name"`
}

// ReadConfig拥有自己打开的文件，每次调用结束都关闭它。
func ReadConfig(path string) (out Config, err error) {
    f, err := os.Open(path)
    if err != nil {
        return out, fmt.Errorf("打开配置: %w", err)
    }
    defer func() {
        // 合并关闭错误，避免覆盖解析失败的原因。
        err = errors.Join(err, f.Close())
    }()

    dec := json.NewDecoder(f)
    if err = dec.Decode(&out); err != nil {
        return out, fmt.Errorf("解析配置: %w", err)
    }

    // 配置文件只允许一个JSON值；第二次读取应当到达输入末尾。
    var extra any
    tailErr := dec.Decode(&extra)
    if tailErr == nil {
        return out, errors.New("配置包含多个JSON值")
    }
    if !errors.Is(tailErr, io.EOF) {
        return out, fmt.Errorf("配置尾部: %w", tailErr)
    }
    return out, nil
}

// DecodeConfig只借用Reader，不关闭调用方拥有的底层资源。
func DecodeConfig(r io.Reader) (Config, error) {
    var out Config
    err := json.NewDecoder(r).Decode(&out)
    return out, err
}

循环中逐个调用 ReadConfig，并即时处理返回的配置即可。解析失败、尾部出现多个值或文件关闭失败都会返回错误。第二次 Decode 用于这个“只含一个配置值”的文件格式；这不是所有 JSON 流都必须采用的规则。连续多条记录的输入应按流协议逐条消费，不能把第二条合法记录当成垃圾。示例未设置文件大小上限，生产导入还应按业务限制输入，尤其是可能来自外部的大文件。

控制大 JSON 与长生命周期引用

流式 API 并不代表内存永远固定。传统 encoding/json 实现中的 Decoder 包含输入引用与字节缓冲，Decode 会为当前完整 JSON 值准备数据。一个巨大的对象、超长字符串或整个大数组，仍可能要求很大的缓冲和结果空间；把结果追加到长期切片里，也会让存活堆随业务数据增加。逐条解码只能缩短单条数据的持有范围，不能消除单条巨大记录的成本。

避免把每个 Decoder 放进全局集合、缓存或长期闭包。结束处理后解除不再需要的引用，让对象具备被垃圾回收的条件；这不是承诺立刻归还内存给操作系统。将变量设为 nil 也不会替底层文件执行 Close。Decoder.Buffered 返回的 Reader 对应未消费缓冲，仍需使用它时就不能假装这部分数据已经不再被引用，其有效期还受下一次解码调用限制。

实现阅读入口：https://go.dev/src/encoding/json/stream.go。这里的缓冲说明对应传统实现，内部字段不是可依赖的公共契约，不能通过反射清空私有字段来“释放资源”。

用相同负载比较改动与限制

比较时每次只改一个因素：先把关闭位置移到单文件函数，再移除长期保存的 Decoder，最后观察结果集合是否符合业务保留预期。成功与失败输入都要覆盖；如果只测成功路径，早退时的遗漏仍可能存在。保持 Go 版本、实验开关、并发度和输入集合一致，记录负载开始、处理中与完成后相同时间窗口的数据。不要拿累计分配不下降证明泄漏，也不要把一次 GC 后 RSS 没有立即下降当成关闭失败。

Decoder 可以手动 Close 吗？

没有这个方法。关闭应作用于你拥有的文件、响应体或其他可关闭输入，不能给解析器补一个名字相同但责任不明确的伪接口。

每条记录新建 Decoder 会更省内存吗？

对同一个连续流反复新建可能丢失前一个 Decoder 已预读的数据。通常一条流使用一个 Decoder；需要混合读取时，必须正确接回 Buffered 与原 Reader 剩余内容。

调用 GC 可以修复文件泄漏吗？

不能把它作为关闭协议。先修正明确的 Close 路径，再分析对象引用及内存成本；业务不应依赖垃圾回收发生的时间来释放文件句柄。