关于Go encoding/json解码器过度读取TCP连接数据导致后续Gob解码阻塞的问题咨询

这个问题确实是encoding/json包中Decoder的预读机制引发的，我来帮你拆解一下问题根源和可行的解决办法：

问题根源：json.Decoder的预读逻辑 #

你已经找到了关键的refill()方法源码，这里再梳理下它的核心行为：

func (dec *Decoder) refill() error {
    // Make room to read more into the buffer.
    // First slide down data already consumed.
    if dec.scanp > 0 {
        dec.scanned += int64(dec.scanp)
        n := copy(dec.buf, dec.buf[dec.scanp:])
        dec.buf = dec.buf[:n]
        dec.scanp = 0
    }

    // Grow buffer if not large enough.
    const minRead = 512
    if cap(dec.buf)-len(dec.buf) < minRead {
        newBuf := make([]byte, len(dec.buf), 2*cap(dec.buf)+minRead)
        copy(newBuf, dec.buf)
        dec.buf = newBuf
    }

    // Read. Delay error for next iteration (after scan).
    n, err := dec.r.Read(dec.buf[len(dec.buf):cap(dec.buf)])
    dec.buf = dec.buf[0 : len(dec.buf)+n]

    return err
}

当解码器的缓冲区剩余空间不足512字节时，它会先扩容缓冲区，然后从底层Reader（也就是你的TCP连接）尽可能多地读取数据填充缓冲区。这意味着如果TCP连接中已经同时存在header和body的字节数据，json解码器会一次性把这些数据都读进自己的内部缓冲区里。

而json.Decoder只会用缓冲区里的数据完成当前的解码（也就是你的header结构体），解码后剩下的body字节会留在它的内部缓冲区中，不会还给原TCP连接。后续你用gob.NewDecoder(conn)直接读取TCP连接时，就会因为没有数据可读而阻塞。

你的代码问题点 #

你的解码逻辑直接让两个解码器共用同一个net.Conn，没有处理json解码器预读的剩余数据：

func decode(conn net.Conn) {
    h := &header{}
    if err := json.NewDecoder(conn).Decode(h); err != nil {
        log.Printf("rpc server: decode header error: %v", err)
    }

    b := &body{}
    if err := gob.NewDecoder(conn).Decode(req); err != nil {
        log.Printf("rpc server: decode body error: %v", err)
    }
}

只有当json解码器第一次读取时，TCP连接中只有header的数据时，才能正常工作；如果body数据已经到达，就会被json解码器预读走，导致gob解码器无数据可用。

解决方案 #

这里提供两种常用的解决思路：

方案1：利用json.Decoder的Buffered()方法传递剩余数据

json.Decoder提供了Buffered()方法，它会返回一个包含解码器内部缓冲区中未使用数据的io.Reader。我们可以把这个Reader和原TCP连接组合成一个新的Reader，传递给gob解码器，这样gob就能先读取json剩下的缓冲数据，再读取TCP连接的新数据：

func decode(conn net.Conn) {
    // 先初始化json解码器并解码header
    jsonDec := json.NewDecoder(conn)
    h := &header{}
    if err := jsonDec.Decode(h); err != nil {
        log.Printf("rpc server: decode header error: %v", err)
        return
    }

    // 组合缓冲的剩余数据和原连接，作为gob解码器的数据源
    combinedReader := io.MultiReader(jsonDec.Buffered(), conn)
    b := &body{}
    gobDec := gob.NewDecoder(combinedReader)
    if err := gobDec.Decode(b); err != nil {
        log.Printf("rpc server: decode body error: %v", err)
    }
}

方案2：精确控制header的读取边界（推荐用于协议设计阶段）

如果你的协议可以调整，最好在header前加上长度前缀，或者用明确的分隔符区分header和body，这样可以提前精确读取header的完整数据，避免json解码器预读body数据：

func decode(conn net.Conn) {
    // 假设协议中用4字节大端整数表示header的长度
    lenBuf := make([]byte, 4)
    if _, err := io.ReadFull(conn, lenBuf); err != nil {
        log.Printf("read header length error: %v", err)
        return
    }
    headerLen := binary.BigEndian.Uint32(lenBuf)

    // 读取对应长度的header字节
    headerBuf := make([]byte, headerLen)
    if _, err := io.ReadFull(conn, headerBuf); err != nil {
        log.Printf("read header data error: %v", err)
        return
    }

    // 用json.Unmarshal解码header，避免使用Decoder的预读
    h := &header{}
    if err := json.Unmarshal(headerBuf, h); err != nil {
        log.Printf("decode header error: %v", err)
        return
    }

    // 直接用原连接解码body即可
    b := &body{}
    if err := gob.NewDecoder(conn).Decode(b); err != nil {
        log.Printf("decode body error: %v", err)
    }
}

总结 #

json.Decoder的预读机制是为了提升解码性能，但在多解码器共用同一个底层Reader的场景下会引发数据抢占问题。解决的核心思路要么是把json解码器缓冲的剩余数据传递给后续解码器，要么是提前精确读取所需数据，避免预读的影响。

备注：内容来源于stack exchange，提问作者jaeger