随笔 | Hugo Academic CV Theme

From unique to cleanups and weak new low-level tools for efficiency

Fri, 28 Mar 2025 00:00:00 +0000

📌 背景与动机

在过去，Go 语言提供了 runtime.SetFinalizer 方法来处理对象被垃圾回收时的清理操作（Finalizer）。
但 Finalizer 存在一些固有问题：

如果对象之间有循环引用，Finalizer 可能永远不会被调用，导致内存泄漏。
Finalizer 会延迟对象的回收，至少需要两个垃圾回收周期才能彻底清除对象。
Finalizer 有可能让对象“复活”（Resurrection），导致原本应被释放的对象意外存活下来，造成内存浪费。

因此，Go 在 1.24 版本推出了两个新功能：

runtime.AddCleanup：更安全的对象清理方法。
weak.Pointer：弱引用指针类型，可以引用对象但不会阻止对象被回收。

这两个功能结合使用，能有效解决传统 Finalizer 的问题，并构建更高效、更安全的数据结构，比如缓存或去重机制。

📌 一、`runtime.AddCleanup`（安全清理函数）

runtime.AddCleanup 允许给一个对象附加一个“清理函数”，当该对象变得不可达（即垃圾回收后）时，清理函数将被执行。

示例：使用内存映射文件（memory-mapped file）

package main

import (
 "os"
 "runtime"
 "syscall"
)

// MemoryMappedFile 表示一个内存映射文件对象
// 通过该对象可直接访问文件内容，无需反复读取磁盘
// 当对象不再使用时，会自动释放内存映射资源
type MemoryMappedFile struct {
    data []byte // 文件内容的内存映射区域
}

// NewMemoryMappedFile 创建一个内存映射文件对象
// filename: 需要被映射的文件路径
func NewMemoryMappedFile(filename string) (*MemoryMappedFile, error) {
    // 打开指定文件
    f, err := os.Open(filename)
    if err != nil {
        return nil, err
    }
    // 确保函数结束时自动关闭文件句柄
    defer f.Close()

    // 获取文件信息（主要是为了获取文件大小）
    fi, err := f.Stat()
    if err != nil {
        return nil, err
    }

    // 获取底层系统的文件描述符（file descriptor）
    conn, err := f.SyscallConn()
    if err != nil {
        return nil, err
    }

    var data []byte
    // 使用conn.Control安全地拿到文件描述符并执行内存映射操作
    connErr := conn.Control(func(fd uintptr) {
    // syscall.Mmap 将文件内容映射到内存
    data, err = syscall.Mmap(
        int(fd),            // 文件描述符
        0,                  // 映射的起始位置，从文件头开始
        int(fi.Size()),     // 映射的长度为文件的大小
        syscall.PROT_READ,  // 映射区域权限：只读
        syscall.MAP_SHARED, // 共享模式，可被多个进程访问
    )
    })

    // 检查映射过程中是否发生错误
    if connErr != nil || err != nil {
        return nil, err
    }

    // 创建内存映射文件对象
    mf := &MemoryMappedFile{data: data}

    // 定义清理函数，用于释放内存映射资源
    cleanup := func(data []byte) {
        syscall.Munmap(data) // 当对象被垃圾回收时，自动解除内存映射
    }

    // 添加清理函数，当 mf 对象不再被引用时，自动调用 cleanup
    runtime.AddCleanup(mf, cleanup, data)

    return mf, nil
}

为什么比传统 Finalizer 更安全？

传统 Finalizer 的问题：清理函数的参数必须是原对象本身，会导致对象复活，延迟释放。
AddCleanup 改进：清理函数不再直接接收原对象，而是另外的独立参数，从而避免了对象复活问题，可以立即释放内存。

📌 二、`weak.Pointer`（弱引用指针）

弱引用指针允许引用一个对象，但这种引用不会阻止对象被垃圾回收。当对象被回收后，弱引用自动变成 nil。

示例：内存映射文件缓存（防止重复加载同一文件）

var cache sync.Map // 缓存文件映射: map[string]weak.Pointer[MemoryMappedFile]

func NewCachedMemoryMappedFile(filename string) (*MemoryMappedFile, error) {
    var newFile *MemoryMappedFile
    for {
        value, ok := cache.Load(filename)
        if !ok {
            if newFile == nil {
                var err error
                newFile, err = NewMemoryMappedFile(filename)
                if err != nil {
                    return nil, err
                }
            }

            wp := weak.Make(newFile)
            value, loaded := cache.LoadOrStore(filename, wp)
            if !loaded {
                runtime.AddCleanup(newFile, func(filename string) {
                    cache.CompareAndDelete(filename, wp)
                }, filename)
                return newFile, nil
            }
        }

        if mf := value.(weak.Pointer[MemoryMappedFile]).Value(); mf != nil {
            return mf, nil
        }

        cache.CompareAndDelete(filename, value)
    }
}

优势：

避免反复映射同一个文件，提升效率。
不需要手动确定何时移除缓存条目。当对象不再被使用，弱引用自动变为 nil，此时可以自动从缓存删除。

📌 三、组合使用与泛型扩展

利用泛型，weak.Pointer 和 runtime.AddCleanup 可用于构建通用缓存结构：

type Cache[K comparable, V any] struct {
    create func(K) (*V, error)
    m      sync.Map
}

func (c *Cache[K, V]) Get(key K) (*V, error) {
    var newValue *V
    for {
        value, ok := c.m.Load(key)
        if !ok {
            if newValue == nil {
                var err error
                newValue, err = c.create(key)
                if err != nil {
                    return nil, err
                }
            }

            wp := weak.Make(newValue)
            value, loaded := c.m.LoadOrStore(key, wp)
            if !loaded {
                runtime.AddCleanup(newValue, func(key K) {
                    c.m.CompareAndDelete(key, wp)
                }, key)
                return newValue, nil
            }
        }

        if v := value.(weak.Pointer[V]).Value(); v != nil {
            return v, nil
        }

        c.m.CompareAndDelete(key, value)
    }
}

📌 四、注意事项与未来方向

尽管更安全，runtime.AddCleanup 和 weak.Pointer 仍属于高级功能：

不要让对象和其清理函数互相引用，否则清理函数可能永远不会执行。
弱引用指针用作 Map 的键时，其对应的值不应引用该对象本身，否则对象可能永远无法回收。
清理操作本质上是非确定性的，难以严格测试和控制，使用时需谨慎考虑。

未来改进方向：

引入 Ephemeron（弱键映射）进一步改善弱引用使用体验。
提供垃圾收集器直接管理资源（如内存映射）的可能。

📌 五、为何现在才推出？

弱引用指针在 Go 中早已被讨论，但长期未被优先考虑：

它复杂微妙，容易误用，可能引入语言复杂度。
但如今泛型支持、对 Finalizer 的长期经验总结，以及其他语言（如 Java、C#）的经验，让这些功能的设计和推出变得成熟和可行。

📌 六、总结（功能对比）

功能	优势	缺陷	推荐用法
runtime.SetFinalizer	易用、简单	易造成内存泄漏或对象复活	不推荐，易误用
✅ runtime.AddCleanup	不造成对象复活，立即回收	高级用法，注意引用关系	资源清理，内存映射
✅ weak.Pointer	不影响垃圾回收，可实现自动缓存清理	非确定性，需谨慎使用	缓存、对象池、去重

综上所述，
Go 1.24 的新功能 runtime.AddCleanup 和 weak.Pointer 提供了更安全、高效的资源管理机制，避免了传统 Finalizer 的重大缺陷。但仍需谨慎合理使用，以避免引入新的复杂性。

From unique to cleanups and weak new low-level tools for efficiency

Fri, 28 Mar 2025 00:00:00 +0000

🧠 一、背景：为什么并发测试很难？

Go 的并发编程很强大（goroutine + channel），但并发测试却非常难写、难维护。

1. 负面条件不好测试

比如你想测试某个函数 “还没有被调用” —— 你没法断言某事“没有发生”。

常见写法是等待一段时间：

select {
case <-calledCh:
    return true
case <-time.After(10 * time.Millisecond):
    return false // 没被调用
}

这种测试方式：

速度慢：每个测试都等 10ms，几百个测试下来就很久了。
不稳定（flaky）：在 CI 上容易失败，比如系统卡顿，10ms 不够就误判失败。
不优雅：测试中必须人为引入等待时间，还可能产生 race。

🌟 二、解决方案：synctest 包

Go 1.24 引入了 testing/synctest 实验包，让并发测试变得快速、稳定、无 race 条件。

⭐ 提供两个核心函数

函数	作用
`synctest.Run(func())`	在一个“并发隔离气泡（bubble）”中运行函数
`synctest.Wait()`	等待气泡中的所有 goroutine 都进入阻塞状态

🧪 三、重写测试的示例对比

❌ 原始写法

if funcCalled() {
    t.Fatalf("函数太早被调用")
}
cancel()
if !funcCalled() {
    t.Fatalf("函数没在取消后被调用")
}

需要通道同步或加锁避免数据竞态
需要 time.After() 等人为延时
慢且不稳定

✅ 使用 synctest

synctest.Run(func() {
    funcCalled := false
    context.AfterFunc(ctx, func() { funcCalled = true })

    synctest.Wait()
    if funcCalled {
        t.Fatalf("函数在取消前被调用了")
    }

    cancel()

    synctest.Wait()
    if !funcCalled {
        t.Fatalf("函数在取消后没有被调用")
    }
})

无需 sleep 或通道
使用 Wait() 自动等 goroutine 阻塞
可读性更强、无竞态、速度更快

⏰ 四、测试涉及时间的代码（使用虚拟时间）

在 synctest 的 bubble 中，Go 使用虚拟时间（fake clock）：

所有 time.Sleep、WithTimeout 都变成非真实阻塞
时间只会在 goroutine 全部阻塞时推进

示例：测试 `context.WithTimeout`

time.Sleep(5s - 1ns)
synctest.Wait()
expect ctx.Err() == nil

time.Sleep(1ns)
synctest.Wait()
expect ctx.Err() == DeadlineExceeded

就像写真时间测试一样直观
实际运行速度极快
不需要修改代码来支持 fake clock！

🌀 五、深入理解：Bubble 的工作机制

“Bubble” 是什么？

Run() 启动一个 goroutine，在一个完全隔离的环境里运行：

这个环境叫 “bubble”
里面的 goroutine 之间是独立的
外界无法干扰它们

`Wait()` 的原理

等待 bubble 中所有 goroutine 都阻塞
阻塞条件必须是“耐久阻塞” (durably blocked)

什么是 durably blocked？

只有以下情况，goroutine 才被认为“耐久阻塞”：

在 nil 通道上收发
在 bubble 内的 channel 上阻塞
所有 select 分支都阻塞
sync.WaitGroup.Wait、sync.Cond.Wait
time.Sleep

❌ 以下情况不会视为耐久阻塞

sync.Mutex（可能会被 bubble 外的 goroutine 解锁）
外部网络或 I/O
与 bubble 外通信的 channel

📦 六、处理 I/O、网络、channel

❗Channel 使用规则

只有 在 bubble 内创建的 channel 才能用于同步
从外部访问 bubble 内 channel 会 panic（防止意外竞争）

❗网络和 I/O 不被视为耐久阻塞

网络数据可能来自 bubble 外部（甚至是其他进程）
无法保证安全性，因此不能直接用 Wait 同步

✅ 推荐方式

使用 net.Pipe() 来创建内存中 fake 网络连接。

🌐 七、网络测试示例：Expect: 100-continue

HTTP 中 Expect: 100-continue 的行为：

客户端先发 header，等服务器返回 100 Continue 再发 body
测试要确保没有提前发 body

测试流程

用 net.Pipe 创建 server/client 的内存连接
设置 http.Transport 用这个连接
启动 goroutine 发请求
拿到请求头之后，不发 100 Continue，检查 body 没有发
发 100 Continue 响应
等待，验证 body 被发出

使用 synctest

go io.Copy(&gotBody, req.Body)
synctest.Wait()
assert gotBody == "" // 没提前发 body

srvConn.Write([]byte("HTTP/1.1 100 Continue\r\n\r\n"))
synctest.Wait()
assert gotBody == body // 收到 Continue 后才发

🚧 八、使用须知与实验状态

testing/synctest 是 实验性 包
默认不可见，需开启实验特性：

GOEXPERIMENT=synctest go test

API 未来可能变动或被移除
欢迎通过 go.dev/issue/67434 提供反馈

✅ 总结表格

特性	原来	使用 synctest
时间控制	用 sleep 模拟	虚拟时间自动推进
并发同步	通道 / 锁	自动 Wait
稳定性	flaky	稳定、无 race
测试速度	慢	非常快
可读性	低	清晰优雅
适用场景	难测代码需重构	可直接测试现有并发代码

如果你需要，我可以：

帮你写一个使用 synctest 的测试样例
给你代码重构建议，如何从旧的 channel-based 测试迁移到 synctest
或者分析你已有测试，看看如何简化它

要不要试试？

Goodbye core types-Hello Go as we know and love it!

Fri, 28 Mar 2025 00:00:00 +0000

📌 一、理解背景：Go语言泛型（Generics）的引入

在 Go 1.18（2022年3月发布）以前，Go语言并没有泛型功能（generics）。所谓泛型就是写函数或数据结构时，可以不指定具体类型，而用类型参数代替，然后调用时再填入具体类型，这样函数可以用于很多不同类型的情况。

比如：

// 没有泛型之前，得为每种类型写一个函数
func SumInt(a, b int) int { return a + b }
func SumFloat(a, b float64) float64 { return a + b }

// 泛型后，可以只写一个函数：
func Sum[T int | float64](a, b T) T { return a + b }

泛型的引入使Go语言更灵活、更强大。但随之而来，语言内部实现变得复杂了。

📌 二、理解类型参数、类型约束和类型集

泛型中出现了一些重要概念：

类型参数（Type Parameter）

就是泛型函数或泛型结构体中用来代替具体类型的占位符，类似函数参数。
```
func Example[T any](value T) T {
    return value
}
```
这里T就是一个类型参数。
类型约束（Type Constraint）

表示一个类型参数能取哪些具体类型的限制。用接口表示：
```
type MyConstraint interface {
    ~string | ~[]byte
    Hash() uint64
}
```
这个约束表示任何底层类型是string或[]byte，并且实现了Hash()方法的类型都可以满足。
类型集（Type Set）

一个类型约束定义了一组满足特定条件的类型集合，称为“类型集”。上述例子中，类型集就是满足“底层类型是string或[]byte且带有Hash()方法”的所有类型的集合。

📌 三、“核心类型”（Core Type）到底是什么？

引入泛型之后，Go的实现者发现了一个问题：

以前语言规范里，很多操作（比如close、append、切片操作）都是直接说：“参数必须是通道”、“参数必须是切片或数组”。
但泛型出现后，有些操作的参数可能是类型参数，无法直接说清楚具体类型了。

为了解决这个问题，语言规范引入了一个抽象概念，称为核心类型（core type）。

核心类型的定义大致是：

非泛型情况：某个普通类型的核心类型就是它的底层类型（underlying type）。
比如：type MyInt int 的核心类型就是int。
泛型情况：若类型参数的类型集中的所有类型的底层类型都完全一样，则这个类型参数的核心类型就是那个共同的底层类型。
反之，如果类型集中有不同的底层类型，则不存在核心类型。

例如：

interface{ ~[]int }类型集只有一种底层类型（[]int），因此它的核心类型就是[]int。
interface{ ~[]byte | ~string }存在两种不同的底层类型（[]byte和string），因此这个接口不存在核心类型。

最初引入核心类型的原因很简单：就是为了语言规范方便叙述和编译器方便实现，避免处理泛型参数时总是考虑一堆类型的集合。

📌 四、核心类型存在的问题（为何要去掉？）

虽然核心类型初衷是为了简化泛型的实现，但实际使用中却带来了一些新问题：

问题1：规则过于严格，限制了语言扩展

因为核心类型要求类型集中所有类型必须有相同的底层类型，很多合理的泛型操作反而被禁止了。

例如，下面的约束就无法获得核心类型：
```
type Constraint interface {
    ~string | ~[]byte
    Hash() uint64
}
```
这样，使用泛型参数时，虽然直观上对字符串和字节数组的某些操作类似，但在核心类型的严格要求下无法实现。
问题2：增加了语言复杂性

很多简单的操作，比如：
```
close(ch) // 以前只要求 ch 是 channel 即可
```
现在规范里却变成了：

“参数的核心类型必须是通道类型”

这让普通的程序员在学习和理解非泛型代码时，也需要理解这个抽象而复杂的“核心类型”概念，给语言的学习造成负担。
问题3：导致了规则的不统一

因为存在核心类型的概念，某些正常的操作反而成为了语言规范的“特例”，比如len()、cap()、索引操作。

这种不统一性，反而使得语言变得更难懂、更难维护。

因此，核心类型在实践中变成了一个“鸡肋”，不仅没有真正让语言变简单，反而变复杂了。

📌 五、Go 1.25 做出了哪些改变？

基于以上问题，Go语言开发团队在即将到来的Go 1.25（2025年8月）中决定彻底废弃“核心类型”概念：

直接删掉了核心类型的定义。
规范中的每个操作，回到更直接的表述方式：

比如，原来：

“close函数的参数核心类型必须是通道”。

现在恢复为：

“close函数的参数必须是通道”。
针对泛型情况下，规范增加额外但直接明确的说明：

“若close函数的参数是类型参数，则类型集内所有类型必须为元素类型一致的通道类型。”

实际效果是

语言规范变简单了：普通程序员不再需要理解抽象的“核心类型”，语言回归直观和简单。
非泛型代码回归原样：不用再关心泛型相关的概念，操作的含义变得直接易懂。
泛型操作更灵活：未来可以更灵活地拓展，比如允许更丰富的类型操作，不再受核心类型概念的限制。

📌 六、总结与直观理解

泛型引入后 → 为了方便描述 → 出现了“核心类型”
实际使用后发现 → 核心类型不仅没简化，反而带来了复杂性
Go 1.25决定 → 删掉“核心类型”，回归简单直接的语言设计方式

简单来说，核心类型原本是为了解决泛型实现中遇到的问题，但实际带来了更大的复杂性。Go团队决定“回到初心”，取消这个概念，让语言规范更加易懂，更便于未来扩展。

到这里，相信你已经完全理解了这篇文章的来龙去脉以及为何 Go 决定废弃“核心类型”的原因。

Traversal-resistant file APIs

Fri, 28 Mar 2025 00:00:00 +0000

📌 一、路径遍历攻击是什么？

路径遍历（Path Traversal）攻击是一种安全漏洞，攻击者通过控制程序访问文件的路径，使程序打开了原本未授权访问的敏感文件。

📌 二、典型漏洞示例（易受攻击的代码）

存在漏洞的代码通常长这样：

// baseDirectory 是受信任的固定目录
// filename 是用户可控制的输入
f, err := os.Open(filepath.Join(baseDirectory, filename))

为什么这段代码有漏洞？

假设：

baseDirectory := "/var/www/data"
filename := "../../../../etc/passwd"

执行后：

filepath.Join("/var/www/data", "../../../../etc/passwd")
// 实际路径："/etc/passwd"

攻击者成功跳出了本来限定的目录（/var/www/data），访问到了敏感文件。

📌 三、为什么传统路径检查不够安全？

你可能会想自己手动验证，比如：

// 手动检查路径安全性（不推荐）
if strings.Contains(filename, "..") {
    return errors.New("路径不安全")
}
f, err := os.Open(filepath.Join(baseDirectory, filename))

但这种检查方式不安全，原因如下：

易被绕过：复杂路径组合（如..././../）或绝对路径难以完全覆盖；
跨平台问题：Windows 和 Unix/Linux 系统对路径的理解不同，Windows 还涉及特殊设备名；
TOCTOU攻击：
攻击者可以在你的检查完成后、程序真正打开文件之前，通过修改符号链接或路径结构，仍旧绕过检查。

📌 四、Go 1.24 提供的安全方案：`os.Root` / `os.OpenInRoot`

为彻底解决上述问题，Go 1.24 推出了新的 API：

安全代码示例如下：

// 安全的代码，彻底防止路径逃逸
f, err := os.OpenInRoot(baseDirectory, filename)

它为什么安全？

os.OpenInRoot 内部机制：

首先打开并锁定根目录（如/var/www/data）；
自动检查用户提供的路径，绝不允许路径逃逸（如通过../）；
使用平台原生API（如Unix/Linux 的openat）防止符号链接攻击；
Windows 平台防止特殊设备名访问，如COM1、NUL。

📌 五、平台差异和注意事项

平台	说明
Unix/Linux	用`openat`系统调用防止逃逸，但无法阻止root用户创建的挂载点（如bind mount）攻击。
Windows	通过句柄锁定目录，阻止目录被重命名或删除；禁止访问特殊设备名。
WASI	安全性取决于WASI实现的沙箱特性。
GOOS=js (Node.js环境)	无法有效抵御TOCTOU攻击，因为缺少`openat`函数。
Plan 9	没有符号链接，直接进行路径词法检查。

📌 六、性能问题与优化

使用os.Root或os.OpenInRoot处理复杂路径（大量../）效率稍低；
建议提前使用filepath.Clean清理路径来提高性能。

📌 七、什么时候必须使用 `os.Root`？

满足以下条件必须使用：

你要打开的文件位于某个指定的根目录内；
文件路径来自外部用户的输入或不可信来源。

例如：

解压zip/tar文件到特定目录；
用户上传文件，必须限制到特定文件夹。

📌 八、完整总结与建议

方式	是否安全	理由
✅ `os.OpenInRoot(baseDirectory, filename)`	安全	内置安全机制，路径无法逃逸
❌ `os.Open(filepath.Join(baseDirectory, filename))`	不安全	可通过路径遍历(`../`)攻击逃出
❌ 手动检查路径（如`strings.Contains("..")`）	不安全	易绕过，且易受TOCTOU攻击

因此，推荐始终使用os.OpenInRoot或os.Root处理外部来源路径，有效防范路径遍历攻击。

以上即为路径遍历攻击及 Go 1.24 中新安全 API 完整详细的总结和解释。

fuck the life!

Sat, 28 Dec 2024 00:00:00 +0000

随笔

最近有点迷茫，要学的东西很多，但是没有动力学习

fuck the life!

Mon, 16 Dec 2024 00:00:00 +0000

随笔

不知道写点什么，就随便写写

随笔 | Hugo Academic CV Theme

From unique to cleanups and weak new low-level tools for efficiency

📌 背景与动机

📌 一、runtime.AddCleanup（安全清理函数）

为什么比传统 Finalizer 更安全？

📌 二、weak.Pointer（弱引用指针）

📌 三、组合使用与泛型扩展

📌 四、注意事项与未来方向

📌 五、为何现在才推出？

📌 六、总结（功能对比）

From unique to cleanups and weak new low-level tools for efficiency

🧠 一、背景：为什么并发测试很难？

1. 负面条件不好测试

🌟 二、解决方案：synctest 包

⭐ 提供两个核心函数

🧪 三、重写测试的示例对比

❌ 原始写法

✅ 使用 synctest

⏰ 四、测试涉及时间的代码（使用虚拟时间）

示例：测试 context.WithTimeout

🌀 五、深入理解：Bubble 的工作机制

“Bubble” 是什么？

Wait() 的原理

什么是 durably blocked？

❌ 以下情况不会视为耐久阻塞

📦 六、处理 I/O、网络、channel

❗Channel 使用规则

❗网络和 I/O 不被视为耐久阻塞

✅ 推荐方式

🌐 七、网络测试示例：Expect: 100-continue

测试流程

使用 synctest

🚧 八、使用须知与实验状态

✅ 总结表格

Goodbye core types-Hello Go as we know and love it!

📌 一、理解背景：Go语言泛型（Generics）的引入

📌 二、理解类型参数、类型约束和类型集

类型参数（Type Parameter）

类型约束（Type Constraint）

类型集（Type Set）

📌 三、“核心类型”（Core Type）到底是什么？

📌 四、核心类型存在的问题（为何要去掉？）

📌 五、Go 1.25 做出了哪些改变？

实际效果是

📌 六、总结与直观理解

Traversal-resistant file APIs

📌 一、路径遍历攻击是什么？

📌 二、典型漏洞示例（易受攻击的代码）

📌 三、为什么传统路径检查不够安全？

📌 四、Go 1.24 提供的安全方案：os.Root / os.OpenInRoot

它为什么安全？

📌 五、平台差异和注意事项

📌 六、性能问题与优化

📌 七、什么时候必须使用 os.Root？

📌 八、完整总结与建议

fuck the life!

随笔

fuck the life!

随笔

📌 一、`runtime.AddCleanup`（安全清理函数）

📌 二、`weak.Pointer`（弱引用指针）

示例：测试 `context.WithTimeout`

`Wait()` 的原理

📌 四、Go 1.24 提供的安全方案：`os.Root` / `os.OpenInRoot`

📌 七、什么时候必须使用 `os.Root`？