Golang观察者模式：事件通知实现解析

本篇文章向大家介绍《Golang实现观察者模式：事件通知详解》，主要包括，具有一定的参考价值，需要的朋友可以参考一下。

Go中观察者模式通过Observer/Subject接口实现松耦合事件分发，需用读写锁+快照保障并发安全，推荐泛型约束事件类型并避免阻塞通知、内存泄漏与循环引用。

在 Go 中实现观察者模式，核心是定义“被观察者”（Subject）和“观察者”（Observer）的契约，并通过注册、通知、解绑机制完成松耦合的事件分发。Go 没有内置 interface 继承或泛型约束（旧版），但借助接口（interface）和切片（[]Observer），完全可以简洁、安全地实现该模式——关键是避免内存泄漏和并发竞争。

定义 Observer 和 Subject 接口

先约定行为：观察者需能接收事件；被观察者需支持增删监听器与广播通知。

Observer 接口只需一个方法：

• Update(event interface{})：接收任意类型事件（生产中建议用具体事件结构体，而非空接口）

Subject 接口包含三个基本能力：

• Register(o Observer)：添加观察者
• Deregister(o Observer)：移除观察者（防止重复通知或 goroutine 泄漏）
• Notify(event interface{})：遍历所有已注册观察者并调用其 Update

实现线程安全的事件总线（推荐做法）

实际项目中，Subject 常被多个 goroutine 并发操作（如异步任务触发事件、HTTP handler 注册监听）。必须加锁保护观察者列表。

示例简明实现：

type EventBroker struct {
    mu       sync.RWMutex
    observers []Observer
}
func (eb *EventBroker) Register(o Observer) {
eb.mu.Lock()
defer eb.mu.Unlock()
eb.observers = append(eb.observers, o)
}
func (eb *EventBroker) Deregister(o Observer) {
eb.mu.Lock()
defer eb.mu.Unlock()
for i, obs := range eb.observers {
if obs == o {
eb.observers = append(eb.observers[:i], eb.observers[i+1:]...)
break
}
}
}
func (eb *EventBroker) Notify(event interface{}) {
eb.mu.RLock()
// 复制一份快照，避免遍历时被修改（尤其 deregister 可能发生）
obsCopy := make([]Observer, len(eb.observers))
copy(obsCopy, eb.observers)
eb.mu.RUnlock()
for _, o := range obsCopy {
    o.Update(event)
}
}

注意：使用读写锁 + 快照复制，可避免 Notify 过程中因 Deregister 导致的 panic 或漏通知。

定义具体事件与观察者（类型安全增强）

用空接口虽灵活，但易出错。更推荐为不同业务定义事件类型：

type UserCreatedEvent struct {
    UserID   int64
    Username string
    Email    string
}
type UserObserver struct{}
func (uo *UserObserver) Update(event interface{}) {
if e, ok := event.(UserCreatedEvent); ok {
log.Printf("User created: %s (%d)", e.Username, e.UserID)
}
}

也可用泛型（Go 1.18+）进一步约束：

type TypedObserver[T any] interface {
    Update(event T)
}
type TypedBroker[T any] struct {
mu       sync.RWMutex
observers []TypedObserver[T]
}
func (tb TypedBroker[T]) Notify(event T) { / ... */ }

这样编译期就能检查事件类型匹配，减少运行时断言错误。

避免常见陷阱

• 不要在 Update 中阻塞或执行耗时操作：否则会拖慢整个 Notify 流程。应启动 goroutine 或投递到 worker 队列
• 观察者注册后未解绑 → 内存泄漏：尤其在 HTTP handler 或长生命周期对象中注册了短生命周期 observer（如临时闭包）。务必配对 Deregister 或用 context 控制生命周期
• 循环引用风险：Subject 持有 Observer 引用，Observer 又持有 Subject 引用（比如闭包捕获）→ GC 无法回收。建议 Observer 不反向持有 Subject
• 不保证通知顺序：Go 切片遍历顺序确定，但若用 map 存储 observers（为 O(1) 删除），则顺序不可靠。如需严格顺序，坚持用 slice + 线性查找

基本上就这些。观察者模式在 Go 里不复杂但容易忽略并发和生命周期细节——接口清晰、锁粒度合理、事件类型明确，就能稳稳支撑模块解耦与事件驱动架构。

到这里，我们也就讲完了《Golang观察者模式：事件通知实现解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！