Golang如何创建只读的任意数据结构

你想保护内存免受何种变化的影响？是语言的正常使用？编程错误？反射访问？具有调试权限的进程？硬件故障？宇宙射线？还是FBI？这里需要更多信息。

感谢您的回复 @skillian！

但我没明白您的意思；您说的“任意内存损坏”是指什么？如果您的内存出现硬件错误，或者存在强烈的电磁干扰，无论内存页的安全性如何，都可能导致内存损坏。

在这种情况下，我只是指，如果某些其他有缺陷的代码（例如，包装成 Golang 包的 C 库）极其罕见地和/或随机地向内存写入一个字节，那么如果该内存是只读的，这种损坏就会立即被发现。

您不能将它们重构为类似这样的形式吗：…… 这以“更笨拙”的语法为代价，为您提供了编译时的安全性。

感谢您的建议！

是的，问题在于现实中的结构要大得多，并且可能是分层的。当前的使用模式是：

• 许多函数对一个较大的结构进行读写，直到某个时间点，即构建阶段。
• 在某个时间点，较大的结构会变得固定/冻结/不可更改。
• 冻结之后，相同的函数应像以前一样正常工作以遍历这些结构，并且不应再进行任何更新。

保证最后一部分“并且不应再进行任何更新”是棘手之处。目前在代码中，这是通过对序列化后的数据结构计算加密哈希值来实现的。理论上，哈希值只需计算一次，就能唯一标识冻结的结构。但实际上，哈希值会被多次计算，以确保冻结的数据结构没有以某种方式发生改变，例如由于有缺陷的代码或内存损坏等原因。

只读内存映射很有趣，只要您从不将任何指向 Go 内存的指针放入结构体中（这可能包括字符串），它就可能有效。

谢谢，我也是这么想的。我有一个临时的概念验证，它将结构体、切片和字符串复制到自己的内存映射中。在这种情况下，存在指针，但它们是指向我自己在内存映射中创建的内存（而不是 Golang 的内存）。所以这意味着内存映射中的数据结构确实包含指针，但所有指针都指向内存映射内部的东西，并且所有这些东西都是我创建的。

这似乎可行，但是……我想对 Golang 的 map 实现同样的功能，现在问题开始了。如果任意结构体包含一个指向 map 的指针，那么我也想在内内存映射中重新创建这个 map。然而，map 的多个数据结构以及遍历它们的业务逻辑，都隐藏在 Golang 自己的 runtime 包中。所以不确定如何在自己的内存映射中重新创建/复制一个由 Golang 管理的 map。因为 Golang 管理的 map 使用了多个隐藏在 runtime 包内部的结构体，我无法在内存映射中重新创建它们。

到目前为止，我唯一的想法——可能很难实现——如下：

• 对于给定平台上给定版本的 Golang，我的包 xyz：
• 获取 runtime 源文件并将它们复制到我的包 xyz 中。
• 自动修改复制的源文件，使其包名变为 xyz 而不是 runtime。
• 假设我能让它编译，那么现在我有了一个内置到我包中的 runtime 的‘副本’。
• 这也意味着我可以从我的包中看到所有隐藏的 map 内部数据结构。
• 理论上，我可以自动修改 map.go 的副本，使其在分配其结构时，不分配到堆或栈上，而是分配到我的内存映射中 🙂

作为附带功能，该代码不仅能够转储结构体，还能转储与这些结构体相关的所有 Golang 内部内存。例如，像 spew 这样的包已经可以转储任意复杂的 Golang 数据结构，但只是以相对高级的格式。是的，它会转储指针值，但它不会转储与 Golang 内部数据结构（如结构体内部填充、切片、字符串，以及更复杂的 map 内部结构体）相关的内存和指针。

所以我的计划是：

• 步骤 1：使用复制 runtime 的技术来访问内部的 map 结构体。
• 步骤 2：完成我的‘转储器’，它可以转储与任意用户结构体相关的所有内存。
• 步骤 3：使用 runtime 副本在任意内存位置重新创建 map，并使用步骤 2 的转储器来检查与克隆数据结构相关的所有内存是否都在我选择的内存映射中。

这里有很多问题需要解决，但理论上，在我将任意 map 重新创建到我选择的数据位置（例如，在我的内存映射中）之后，理论上，如果我能用‘真正的’ runtime map 函数访问内存映射中的那个 map，它应该就能工作。如果写入失败，要么是因为内存映射是只读的，要么是因为它试图更新非 Golang 管理的内部结构。

您怎么看？有替代方法吗？

[1] GitHub - davecgh/go-spew: 为 Go 数据结构实现深度美化打印器以辅助调试

在Go中实现只读的任意数据结构确实是一个有挑战性的需求。虽然Go本身不直接支持这种内存管理方式，但可以通过一些系统级调用来实现类似的功能。以下是几种可能的实现方案：

方案一：使用mmap创建只读内存区域

package main

import (
    "fmt"
    "golang.org/x/sys/unix"
    "os"
    "unsafe"
)

type ROData struct {
    data []byte
    size int
}

func CreateReadOnlyData(size int) (*ROData, error) {
    // 创建临时文件作为内存映射的后备存储
    tmpfile, err := os.CreateTemp("", "rodata-*")
    if err != nil {
        return nil, err
    }
    defer os.Remove(tmpfile.Name())
    
    // 扩展文件到所需大小
    if err := tmpfile.Truncate(int64(size)); err != nil {
        return nil, err
    }
    
    // 内存映射文件
    data, err := unix.Mmap(int(tmpfile.Fd()), 0, size, 
        unix.PROT_READ|unix.PROT_WRITE, unix.MAP_SHARED)
    if err != nil {
        return nil, err
    }
    
    // 写入数据
    copy(data, []byte("Hello, Read-Only World!"))
    
    // 重新映射为只读
    if err := unix.Mprotect(data, unix.PROT_READ); err != nil {
        unix.Munmap(data)
        return nil, err
    }
    
    return &ROData{data: data, size: size}, nil
}

func main() {
    roData, err := CreateReadOnlyData(4096)
    if err != nil {
        panic(err)
    }
    
    // 读取数据 - 正常工作
    fmt.Println(string(roData.data[:25]))
    
    // 尝试写入 - 会触发段错误
    // roData.data[0] = 'X' // 取消注释会导致panic
}

方案二：使用cgo分配和管理自定义堆

package main

/*
#include <stdlib.h>
#include <sys/mman.h>
#include <string.h>

void* alloc_readonly_memory(size_t size, void* data, size_t data_size) {
    void* mem = mmap(NULL, size, PROT_READ|PROT_WRITE, 
                    MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
    if (mem == MAP_FAILED) return NULL;
    
    if (data != NULL && data_size > 0) {
        memcpy(mem, data, data_size);
    }
    
    if (mprotect(mem, size, PROT_READ) == -1) {
        munmap(mem, size);
        return NULL;
    }
    
    return mem;
}

void free_readonly_memory(void* mem, size_t size) {
    munmap(mem, size);
}
*/
import "C"
import (
    "fmt"
    "unsafe"
)

type ImmutableStruct struct {
    ID    uint64
    Value float64
    Data  [32]byte
}

func CreateImmutable(s *ImmutableStruct) unsafe.Pointer {
    size := C.size_t(unsafe.Sizeof(*s))
    
    ptr := C.alloc_readonly_memory(size, unsafe.Pointer(s), size)
    if ptr == nil {
        panic("Failed to allocate readonly memory")
    }
    
    return ptr
}

func main() {
    data := &ImmutableStruct{
        ID:    12345,
        Value: 3.14159,
        Data:  [32]byte{'i', 'm', 'm', 'u', 't', 'a', 'b', 'l', 'e'},
    }
    
    roPtr := CreateImmutable(data)
    
    // 通过指针读取数据
    roData := (*ImmutableStruct)(roPtr)
    fmt.Printf("ID: %d, Value: %f\n", roData.ID, roData.Value)
    
    // 注意：不能写入roData，否则会段错误
}

方案三：序列化到只读内存映射

package main

import (
    "encoding/gob"
    "golang.org/x/sys/unix"
    "bytes"
    "fmt"
)

func SerializeToReadOnly(v interface{}) ([]byte, error) {
    var buf bytes.Buffer
    encoder := gob.NewEncoder(&buf)
    if err := encoder.Encode(v); err != nil {
        return nil, err
    }
    
    data := buf.Bytes()
    size := len(data)
    
    // 分配可写内存
    mem, err := unix.Mmap(-1, 0, size, 
        unix.PROT_READ|unix.PROT_WRITE, 
        unix.MAP_PRIVATE|unix.MAP_ANONYMOUS)
    if err != nil {
        return nil, err
    }
    
    // 复制数据
    copy(mem, data)
    
    // 设置为只读
    if err := unix.Mprotect(mem, unix.PROT_READ); err != nil {
        unix.Munmap(mem)
        return nil, err
    }
    
    return mem, nil
}

type ComplexData struct {
    MapData map[string]int
    SliceData []float64
    Nested *ComplexData
}

func main() {
    data := &ComplexData{
        MapData: map[string]int{"a": 1, "b": 2},
        SliceData: []float64{1.1, 2.2, 3.3},
    }
    
    roMem, err := SerializeToReadOnly(data)
    if err != nil {
        panic(err)
    }
    
    // 反序列化只读数据
    var decoded ComplexData
    decoder := gob.NewDecoder(bytes.NewReader(roMem))
    if err := decoder.Decode(&decoded); err != nil {
        panic(err)
    }
    
    fmt.Printf("Decoded: %v\n", decoded.MapData)
}

重要注意事项

1. 指针重定位问题：当复制包含指针的Go数据结构时，所有指针都需要重新计算偏移量。这通常需要自定义的序列化/反序列化逻辑。

2. 内存对齐：确保自定义分配的内存满足Go类型的内存对齐要求。

3. 垃圾回收：Go的垃圾回收器不会管理自定义分配的内存，需要手动管理生命周期。

4. 平台依赖：这些方案依赖于系统调用（mmap/mprotect），在不同操作系统上可能需要调整。

5. 性能考虑：频繁创建只读内存区域可能影响性能，建议批量处理或使用内存池。

这些方案提供了在Go运行时之外管理只读数据结构的方法，但都需要仔细处理内存管理和错误处理。对于区块链这类需要高度确定性和安全性的应用，这种底层内存控制是合理的。