当前位置：首页 > 文章列表 > Golang > Go问答 > Go crc64.MakeTable 生成的 Table 可以安全复用吗

Go crc64.MakeTable 生成的 Table 可以安全复用吗

来源：17golang原创 2026-11-11 01:26:43 0浏览收藏

可以复用，但要把“算法表”和“计算状态”分开看：crc64.MakeTable 返回的 *crc64.Table 可以作为只读共享对象，被多个并发任务引用；每个任务则应通过 crc64.New(table) 创建自己的 hash.Hash64。官方文档明确要求不要修改 Table 内容，而 Hash64 本身包含会随 Write 变化的状态，所以不能把同一个 Hash64 在 goroutine 之间混用。

要点速览

Table 是由多项式构造出的 256 项算法表，初始化一次后只读复用。
New(table) 每次返回独立的 hash.Hash64；并发任务不要共享同一个实例。
小块内存数据可用 Checksum，流式数据用 New + Write，已有累计值时再考虑 Update。

Table 可以共享，Hash64 状态不能混用

我第一次把 CRC64 放进并发校验服务时，最容易混淆的是两个指针的职责。Table 只描述“怎样计算”，官方把它定义为表示多项式的 256-word table，并特别说明其内容不能修改；hash.Hash64 则是一次具体计算的累积状态，写入一批字节后，后续 Sum64 会依赖已经写入的内容。

Go crc64 Table 只读共享与多个独立 Hash64 状态隔离的结构说明图 — 图1：只读复用结构图，展示同一 crc64.Table 被两个独立 Hash64 引用；这是静态说明图，不是运行截图。

因此推荐把表放在初始化位置，把哈希对象放到请求或任务函数内部：

package main

import (
    "hash"
    "hash/crc64"
    "io"
    "os"
)

// crcTable 只在初始化时生成，后续只读复用，不要改写其内容。
var crcTable = crc64.MakeTable(crc64.ECMA)

// fileCRC64 为每次调用创建独立 Hash64，避免并发任务共享累积状态。
func fileCRC64(path string) (uint64, error) {
    file, err := os.Open(path)
    if err != nil {
        return 0, err
    }
    defer file.Close()

    var h hash.Hash64 = crc64.New(crcTable)
    // 文件字节持续写入当前任务自己的哈希对象，不把文件整体载入内存。
    if _, err := io.Copy(h, file); err != nil {
        return 0, err
    }
    // Sum64 只读取当前对象的累计结果，不会修改它的状态。
    return h.Sum64(), nil
}

这里可以安全复用的是 crcTable，不是 h。如果两个 goroutine 同时向同一个 h 调用 Write，它们会竞争同一份累积状态；即使程序没有立刻崩溃，也不能把结果当成两个独立输入的 CRC64。需要并发时，让每个任务调用一次 crc64.New(crcTable) 就够了。

并发复用的边界：共享只读数据，隔离可变状态

“Table 可以并发复用”是一个有前提的工程判断，不是说 crc64 的所有对象都可以无锁共享。更准确的关系是：算法表只读，多个 Hash64 读取它；Hash64 的累计值各自独立，分别接收自己的输入。

对象	能否跨任务复用	使用边界
`*crc64.Table`	可以，只读	初始化后不要修改 256 项内容
`hash.Hash64`	不要直接共享	每个文件、请求或 goroutine 独立创建
`uint64` 累计值	按值传递	用 `Update` 返回新的累计结果

如果业务确实把 Table 暴露给多个组件，组件之间也只能把它当成只读配置。不要为了“动态切换算法”直接改写已有 Table；需要另一套算法时，生成另一张表，并让任务显式选择对应指针。

Checksum、New 和 Update 怎么选

这三个 API 都接收 *crc64.Table，但适用的输入形态不同。官方文档中，Checksum 直接返回一段数据的 CRC64；New 创建可持续写入的 hash.Hash64；Update 则是在已有 CRC 值上加入一段字节。

Go crc64 Checksum、New、Update 与不同输入形态的 API 关系说明图 — 图2：API 关系图，展示 Checksum、New 和 Update 的输入边界；这是静态说明图，不是运行截图。

package main

import "hash/crc64"

// checksumSmall 适合数据已经在内存中的一次性计算。
func checksumSmall(data []byte, table *crc64.Table) uint64 {
    return crc64.Checksum(data, table)
}

// updateChunks 适合调用方已经维护累计 crc，并按块追加输入。
func updateChunks(crc uint64, chunks [][]byte, table *crc64.Table) uint64 {
    for _, chunk := range chunks {
        // Update 返回新的累计值；不要把不同任务的 crc 变量混在一起。
        crc = crc64.Update(crc, table, chunk)
    }
    return crc
}

文件、网络流或未知大小的数据，我更倾向 New + Write；小的内存切片用 Checksum 更直观；已有分块协议状态时，Update 可以减少额外的 Hash64 包装。无论选哪一种，Table 的复用规则不变：只读共享，不能修改。