Forem: Leon

Go: Ticker

Leon — Fri, 15 Aug 2025 03:54:46 +0000

time.Ticker 是 Go 语言标准库 time 包中一个强大的工具，用于实现周期性的任务。它以固定的时间间隔向一个通道发送事件，非常适合用于轮询、定时刷新缓存、心跳检测等多种场景。然而，不当的使用也可能导致 goroutine 泄漏和程序性能问题。本文将全面总结 time.Ticker 的使用技巧，从基础用法到高级模式，帮助您高效、安全地在项目中使用它。

1. 基础用法：创建和接收事件

创建一个 Ticker 非常简单，只需调用 time.NewTicker() 并传入一个 time.Duration 类型的参数作为时间间隔。

Go

package main

import (
    "fmt"
    "time"
)

func main() {
    // 创建一个每秒触发一次的 ticker
    ticker := time.NewTicker(1 * time.Second)
    defer ticker.Stop() // 确保在不需要时停止 ticker

    done := make(chan bool)

    go func() {
        for {
            select {
            case <-done:
                return
            case t := <-ticker.C:
                fmt.Println("Tick at", t)
            }
        }
    }()

    // 运行一段时间后停止
    time.Sleep(5 * time.Second)
    done <- true
    fmt.Println("Ticker stopped")
}

核心要点:

time.NewTicker(duration) 返回一个 time.Ticker 对象。
ticker.C 是一个通道 (<-chan time.Time)，会按设定的时间间隔接收到当前时间。
必须调用 ticker.Stop() 来释放相关资源。通常使用 defer 语句来确保在函数退出时执行。

2. 安全停止 Ticker：避免 Goroutine 泄漏

忘记调用 ticker.Stop() 是一个常见的错误，这会导致底层的 goroutine 无法被垃圾回收，从而造成 goroutine 泄漏。特别是在一个长期运行的程序中，这会逐渐消耗系统资源。

优雅关闭模式 (Graceful Shutdown)

在实际应用中，我们常常需要在程序退出时，或者某个模块不再需要时，优雅地停止正在运行的 ticker。这通常通过一个额外的 done 或 quit 通道来实现。

Go

package main

import (
    "fmt"
    "time"
)

func worker(stop chan bool) {
    ticker := time.NewTicker(1 * time.Second)
    defer ticker.Stop()

    for {
        select {
        case <-ticker.C:
            fmt.Println("Doing periodic work...")
        case <-stop:
            fmt.Println("Worker stopping...")
            return
        }
    }
}

func main() {
    stop := make(chan bool)
    go worker(stop)

    time.Sleep(3 * time.Second)
    stop <- true // 发送停止信号
    time.Sleep(1 * time.Second) // 等待 worker 退出
    fmt.Println("Main finished")
}

这种 select 结构允许 goroutine 同时监听 ticker 事件和停止信号，实现了对 goroutine 生命周期的精确控制。

3. Ticker 与 `time.Sleep` 的对决

初学者可能会使用 for 循环配合 time.Sleep() 来实现周期性任务。然而，time.Ticker 在精确性和效率上通常更胜一筹。

特性	`time.Ticker`	`for` + `time.Sleep(d)`
精确性	高。Ticker 会自动调整下一次触发的时间，以弥补任务执行所花费的时间，尽可能保证平均间隔为 `d`。	低。实际的执行间隔是 `任务执行时间 + d`，会导致周期逐渐漂移。
资源使用	较为高效，底层由 Go runtime 的定时器统一管理。	简单直接，但不够精确。
控制	可以通过 `Stop()` 和 `Reset()` 进行灵活控制。	只能在循环中通过 `break` 或 `return` 退出。

结论： 对于需要精确周期的任务，强烈推荐使用 time.Ticker。time.Sleep 更适用于简单的、对周期精度要求不高的延时场景。

4. 应对慢消费者 (Slow Receiver)

如果接收 ticker.C 的任务执行时间超过了 ticker 的间隔时间，会发生什么？

time.Ticker 的内部通道只有一个缓冲区。如果上一个 tick 还没有被消费，而新的 tick 又到了，Ticker 会丢弃这个新的 tick，等待消费者处理完当前 tick 后再发送下一个。这可以防止 tick 在通道中无限堆积，但也意味着任务的执行频率会降低。

示例：

Go

ticker := time.NewTicker(1 * time.Second)
defer ticker.Stop()

for range ticker.C {
    fmt.Println("Tick!")
    time.Sleep(2 * time.Second) // 任务耗时超过了 ticker 间隔
}
// 输出会是每 2 秒一个 "Tick!"，而不是每秒一个

应对策略：

优化任务性能：从根本上减少每次任务的执行时间。
解耦：如果任务确实耗时，可以考虑将任务放入一个工作池 (worker pool) 中异步执行，让 ticker 的接收者只负责分发任务，避免阻塞。

5. 动态调整 Ticker 间隔

在某些场景下，我们可能需要根据程序的运行状态动态调整定时任务的频率。这时可以使用 ticker.Reset() 方法。

ticker.Reset(newDuration) 会停止当前的 ticker，并将其周期重置为新的时长。下一个 tick 会在 newDuration 之后到达。

Go

package main

import (
    "fmt"
    "time"
)

func main() {
    ticker := time.NewTicker(3 * time.Second)
    defer ticker.Stop()

    go func() {
        for t := range ticker.C {
            fmt.Println("Tick at", t)
        }
    }()

    fmt.Println("Ticker started with 3s interval.")
    time.Sleep(7 * time.Second)

    // 将间隔重置为 1 秒
    ticker.Reset(1 * time.Second)
    fmt.Println("Ticker interval reset to 1s.")

    time.Sleep(5 * time.Second)
}

6. Go 1.23 的重要变化：自动垃圾回收

在 Go 1.23 之前，如果忘记调用 ticker.Stop()，Ticker 对象将永远不会被垃圾回收，导致资源泄漏。

从 Go 1.23 开始，Go 的垃圾回收器变得更加智能，能够回收未被引用的、且未被停止的 Ticker。这意味着即使忘记调用 Stop()，也不再会导致永久的资源泄漏。

尽管如此，最佳实践仍然是：

显式调用 Stop()：这使得代码意图更加清晰，表明你已经完成了对这个 Ticker 的使用。
在不再需要 Ticker 时立即停止它，可以更早地释放资源，而不是等待 GC。

7. 常见使用场景

心跳检测：客户端或服务器定时发送心跳包以维持连接。
数据轮询：定时从数据库、API 或其他数据源拉取更新。
缓存刷新：定期清理或更新内存中的缓存数据。
监控和度量：周期性地收集系统性能指标。
超时控制：结合 select 语句，为某个操作设置一个周期性的检查点。

总结

time.Ticker 是 Go 并发编程中不可或缺的工具。掌握其正确的使用方法，特别是优雅地停止它，是编写健壮、可维护的 Go 程序的关键。

核心技巧回顾：

创建与停止：使用 time.NewTicker() 创建，并用 defer ticker.Stop() 确保释放。
优雅关闭：结合 select 和一个额外的 done 通道来安全地终止 goroutine。
精确周期：优先选择 Ticker 而不是 time.Sleep 来保证周期的准确性。
注意慢消费：理解慢消费会导致 tick 被丢弃，并据此设计你的任务逻辑。
动态调整：使用 ticker.Reset() 灵活改变任务频率。
了解版本差异：知晓 Go 1.23 在 GC 方面的改进，但仍坚持显式调用 Stop() 的好习惯。

通过遵循这些技巧，你可以充满信心地在你的 Go 项目中发挥 time.Ticker 的最大效用。

Rust: Ownership, Borrowing (References), Lifetimes, Move/Copy/Clone semantics

Leon — Tue, 13 May 2025 09:43:51 +0000

🧠 Why Care About These Concepts?

Reliability
These concepts allow the Rust compiler to prevent common resource errors such as:
- Memory leaks
- Dangling pointers
- Double frees
- Accessing uninitialized memory
Convenience

The Rust compiler can automatically free resources using these concepts — no need for manual free or a garbage collector.
Performance
Resource management without a garbage collector enables:
- Faster performance
- Suitability for real-time systems

🛠️ How to Use These Features?

These features are enforced by the compiler through compile-time checks.
You don't usually do something manually — instead, you follow Rust's rules.
Understanding these concepts is essential to fix compiler error messages during development.

🧾 Basic Memory Management Terminology

A variable is a name for a memory location holding a value of some type.
Memory can be allocated in three regions:
- Stack: Automatically allocated when a function is called, and freed when the function returns.
- Heap: Requires explicit allocation and deallocation (handled by Rust’s ownership model).
- Static memory: Lives for the entire duration of the program.

🐞 Common Memory Errors

Dangling Pointer:
A pointer to memory that has been freed or was never initialized.
Memory Leak:
Memory allocated on the heap is never freed — e.g., forgetting to release memory.
Uninitialized Memory:
Using memory before it has been properly allocated or assigned a value.
Double Free:
Attempting to free the same memory more than once — either on the same variable or on a copy.

⚠️ What Can Go Wrong on the Stack?

Since memory is automatically allocated and freed, there are no memory leaks, uninitialized memory, or double free problems.
The function might return a pointer to a value on the stack, leading to a dangling pointer.
Rust prevents this by simply checking that no such references are returned — see stack-dangling-pointer.rs.

❌ Example: Returning a reference to a local variable

fn create_ref() -> &i32 {
    let number = 10;
    &number // ❌ This will cause a compile error
}

Compiler Error:

error[E0515]: cannot return reference to local variable `number`

Don’t return references to local function variables — copy or move the value out of the function.

✅ Correct version: Move the value out

fn create_value() -> i32 {
    let number = 10;
    number // ✅ Move the value instead of returning a reference
}

💾 What Can Go Wrong on the Heap?

A reference might be used after the memory was reallocated or freed, leading to a dangling pointer.
The borrow checker prevents the reallocation by not allowing a mutable and other reference at the same time.
An immutable reference is needed to push on a vector and possibly reallocate it — see heap-reallocation-dangling-pointer.rs.

❌ Example: Reallocation with active immutable borrow

fn main() {
    let mut vec = vec![1, 2, 3];
    let first = &vec[0];      // Immutable borrow
    vec.push(4);              // ❌ May cause reallocation
    println!("{}", first);    // Use after potential reallocation
}

Compiler Error:

error[E0502]: cannot borrow `vec` as mutable because it is also borrowed as immutable

Don’t do it, and if you really need a mutable reference paired with other references, use the std::cell module.

✅ Correct version: Borrow after mutation

fn main() {
    let mut vec = vec![1, 2, 3];
    vec.push(4);              // ✅ Mutate first
    let first = &vec[0];      // Borrow afterwards
    println!("{}", first);
}

Rust prevents the use after free case by making sure no reference is used after its lifetime has ended, i.e. the value was dropped — see heap-dropped-dangling-pointer.rs.

❌ Example: Reference lives longer than the value

fn main() {
    let r;
    {
        let vec = vec![1, 2, 3];
        r = &vec[0]; // ❌ `vec` goes out of scope here
    }
    println!("{}", r); // Use after drop
}

Compiler Error:

error[E0597]: `vec` does not live long enough

Don’t do it, or if you really run into this problem, you might need shared ownership with the std::rc module.

The borrow checker also does not allow a value to be moved to another variable that could reallocate or free the memory while there are references — see heap-move-dangling-pointer.rs.

❌ Example: Move after borrow

fn main() {
    let vec = vec![1, 2, 3];
    let r = &vec;
    let moved = vec; // ❌ Moving vec while r still exists
    println!("{:?}", r);
}

Compiler Error:

error[E0505]: cannot move out of `vec` because it is borrowed

Don’t move a value to another variable and then use a reference to it you created before.

✅ Correct version: Use after move or avoid borrowing before move

fn main() {
    let vec = vec![1, 2, 3];
    let moved = vec; // ✅ Move without borrowing first
    println!("{:?}", moved);
}

🔑 What Is Ownership?

Rust automatically frees memory, so there are no memory leaks or double free calls.
Rust does this without a garbage collector.

🧹 How Does Rust Manage Memory?

The concept is simple: Rust calls a destructor (drop) whenever the lifetime of a value ends, i.e., when the value goes out of scope ({} block ends).

fn main() {
    {
        let _s = String::from("hello");
        // `_s` is dropped here automatically
    }
    // memory is freed
}

❌ The Problem with Shallow Copies

Some values, like a Vec, contain heap-allocated data.
A shallow copy (only copying pointer and metadata) would cause a double free error if both copies tried to free the same memory.

✅ Rust prevents this with Move Semantics

When you assign one variable to another, Rust moves the value instead of copying it (unless it implements Copy).

🔁 Move Example (`move-semantics.rs`)

fn main() {
    let vec = vec![1, 2, 3];
    let moved = vec; // vec is moved
    // println!("{:?}", vec); // ❌ error: use of moved value
}

🧠 Compiler Error:

error[E0382]: borrow of moved value: `vec`

Don’t use a value after it was moved.
If you really need a deep copy, use .clone():

fn main() {
    let vec = vec![1, 2, 3];
    let cloned = vec.clone(); // deep copy
    println!("{:?}", vec);    // ✅ ok to use
}

⚠️ .clone() is often unnecessary and can lead to performance issues if overused.

📦 Copy vs Move

Primitive types (e.g., i32, bool, char) are copied by default.
- No heap data → no double free risk.

fn main() {
    let a = 42;
    let b = a; // a is copied, not moved
    println!("a = {}, b = {}", a, b); // ✅ both are usable
}

Types with heap data (e.g., Vec, String) are moved by default.
You can make your own types Copy-able by implementing the Copy trait:

Example: `Copy` trait (`copy-semantics.rs`)

#[derive(Copy, Clone)]
struct Point {
    x: i32,
    y: i32,
}

fn main() {
    let p1 = Point { x: 1, y: 2 };
    let p2 = p1; // p1 is copied, not moved
    println!("p1: {}, {}", p1.x, p1.y); // ✅ still valid
}

If a type is not Copy, Rust will give an error like:

move occurs because `config` has type `Config`, which does not implement the `Copy` trait

✅ Don’t implement Copy if you can live with using references.

✅ You can also just implement Clone and call .clone() explicitly — see clone-semantics.rs.

📌 Summary and Miscellaneous Info

Ownership, borrowing, and lifetimes enable the Rust compiler to:
- Detect and prevent memory errors
- Handle memory automatically and safely
Safe Rust guarantees memory safety — no undefined behavior from memory misuse.
You can use unsafe Rust inside an unsafe {} block if needed.
Rust understands how to free memory even in:
- Loops
- if/match clauses
- Iterators
- Partial moves from structs
✅ If your program compiles, you get these memory safety guarantees without a runtime garbage collector.

Introducing LoConn: local area network chatting app written in GO

Leon — Fri, 09 May 2025 15:25:42 +0000

Golan

Go implementation of local area network communications based on protocols like UDP, HTTPS, WebSocket, etc.

Try the desktop GUI app for lan-chatting/document transferring:https://github.com/leoxiang66/golan/releases

General roadmap

[x] basic GUI app that supports peer2peer lan-chatting
[x] support multiple conversations at the same time
[ ] support copying chat messages
[ ] support random user names
[ ] GUI notifications for system information such as "socket disconnected"
[ ] support disconnecting sockets by users
[ ] support file transferring
[ ] support blacklist
[ ] encryption/decryption

Some screenshots

Peer2Peer chat
Invite for socket connection
Received invitation

Go vs C++ 变量生存周期对比

Leon — Tue, 06 May 2025 08:00:12 +0000

1. 变量分配位置：栈（Stack） vs 堆（Heap）

特性	Go	C++
栈上分配	默认；逃逸分析判断不外泄的局部变量	默认；函数作用域内局部变量
堆上分配	`&T{}` 语法，根据逃逸分析结果决定	必须显式 `new` / `malloc`
栈/堆切换逻辑	编译期逃逸分析自动决定	由程序员通过不同语法手动选择

Go 的逃逸分析
- 编译时分析：如果一个变量的引用“逃逸”出函数作用域（例如被返回或存入外部结构），则在堆上分配；否则留在栈上。
- 无需手动标注或调用函数，&T{} 语句自动触发逃逸检测。
C++ 的显式分配
- 栈分配：T obj; 在函数结束时自动销毁。
- 堆分配：new T 或 malloc，需要手动 delete 或 free，否则产生内存泄漏。

2. 内存回收：垃圾回收 vs 手动管理

特性	Go	C++
内存回收方式	并发标记-清除（Garbage Collection）	手动 `delete` / `free`
开发者负担	低：无需关注何时释放	高：必须谨慎配对分配与释放
内存泄漏风险	极低，只要无引用即可回收	较高：忘记释放或多次释放都可能出错
性能开销	GC 偶发停顿；现代 Go GC 已大幅优化	几乎零开销，但需额外编码与审查成本

Go 的 GC 特点
- 并发执行、不停机：大对象标记与清除在后台进行。
- 只要变量不再被任何活动引用，内存即被回收。
C++ 的手动管理
- new/malloc 与 delete/free 必须成对出现。
- 智能指针（std::unique_ptr、std::shared_ptr）可减轻部分负担，但仍需理解引用计数与生命周期。

3. 指针安全性与悬空指针

问题	Go	C++
返回本地变量地址	安全：自动逃逸到堆	危险：返回栈上变量地址导致悬空指针
悬空指针风险	不存在（逃逸分析保证）	普遍：需小心谨慎
空指针检测	无需手动；引用失效后不可达	访问悬空或空指针未定义行为

Go 示例（安全）

  func createNode(val int) *ListNode {
      return &ListNode{Val: val} // 自动分配在堆上
  }

无论 createNode 返回什么，节点都在堆上，由 GC 管理。

C++ 示例（危险）

  ListNode* createNode(int val) {
      ListNode node(val);      // 栈上分配
      return &node;            // 返回栈上地址 -> 悬空指针
  }

4. 示例对比：追加链表节点

Go 版

func appendNode(head *ListNode, val int) {
    curr := head
    for curr.Next != nil {
        curr = curr.Next
    }
    curr.Next = &ListNode{Val: val}  // 新节点逃逸到堆
}
// 调用后，无需担心内存释放，GC 自动管理

C++ 版

void appendNode(ListNode* head, int val) {
    ListNode* curr = head;
    while (curr->next != nullptr) {
        curr = curr->next;
    }
    curr->next = new ListNode(val);  // 手动分配
}
// 需要在适当时机 delete 整个链表，避免内存泄漏

5. 小结

分配简便 vs 灵活自由

Go：&T{} 一行搞定分配位置，兼顾性能与安全。
C++：细粒度控制，但需程序员自行选择并管理。

自动回收 vs 手动回收

Go 的并发 GC 降低开发者负担，适合快速迭代。
C++ 的手动管理零 GC 开销，但易错、调试成本高。

指针安全

Go 强制逃逸分析与 GC，几乎消除悬空指针风险。
C++ 强大灵活，却要时刻提防野指针与内存泄漏。

两者各有优劣：Go 在安全性和开发体验上更胜一筹，而 C++ 在性能控制和底层能力上更具优势。根据项目需求和团队背景，选择最合适的语言与记忆模型即可。

Forem: Leon

Go: Ticker

1. 基础用法：创建和接收事件

Go

2. 安全停止 Ticker：避免 Goroutine 泄漏

优雅关闭模式 (Graceful Shutdown)

Go

3. Ticker 与 time.Sleep 的对决

4. 应对慢消费者 (Slow Receiver)

Go

5. 动态调整 Ticker 间隔

Go

6. Go 1.23 的重要变化：自动垃圾回收

7. 常见使用场景

总结

Rust: Ownership, Borrowing (References), Lifetimes, Move/Copy/Clone semantics

🧠 Why Care About These Concepts?

🛠️ How to Use These Features?

🧾 Basic Memory Management Terminology

🐞 Common Memory Errors

⚠️ What Can Go Wrong on the Stack?

❌ Example: Returning a reference to a local variable

Compiler Error:

✅ Correct version: Move the value out

💾 What Can Go Wrong on the Heap?

❌ Example: Reallocation with active immutable borrow

Compiler Error:

✅ Correct version: Borrow after mutation

❌ Example: Reference lives longer than the value

Compiler Error:

❌ Example: Move after borrow

Compiler Error:

✅ Correct version: Use after move or avoid borrowing before move

🔑 What Is Ownership?

🧹 How Does Rust Manage Memory?

❌ The Problem with Shallow Copies

✅ Rust prevents this with Move Semantics

🔁 Move Example (move-semantics.rs)

🧠 Compiler Error:

📦 Copy vs Move

Example: Copy trait (copy-semantics.rs)

📌 Summary and Miscellaneous Info

Introducing LoConn: local area network chatting app written in GO

Golan

General roadmap

Some screenshots

Go vs C++ 变量生存周期对比

1. 变量分配位置：栈（Stack） vs 堆（Heap）

2. 内存回收：垃圾回收 vs 手动管理

3. 指针安全性与悬空指针

4. 示例对比：追加链表节点

Go 版

C++ 版

5. 小结

3. Ticker 与 `time.Sleep` 的对决

🔁 Move Example (`move-semantics.rs`)

Example: `Copy` trait (`copy-semantics.rs`)