衡水市网站建设_网站建设公司_Spring_seo优化

最近再写一个Go TCP 网络聊天室，服务端有登录、注册功能。
一开始写得很顺，功能也都能跑，但很快我发现了一个致命问题：
当一个客户端在登录/注册时，其他客户端居然完全没法操作了。

这不是 bug，而是我并没有真正理解 goroutine 的使用场景。

一."理所当然却错误"的服务端写法

先来看一个非常符合新手直觉的TCP服务端结构

listener, _ := net.Listen("tcp", ":8888") for { conn, _ := listener.Accept() handleConn(conn) }

然后在handleConn里面

func handleConn(conn net.Conn) { for { msg := readMsg(conn) if msg.Type == "login" { doLogin(conn) } if msg.Type == "register" { doRegister(conn) } } }

当时并没有考虑到 :当一个用户进行登录注册,在阻塞的时候,其他的客户端并不能自然向下进行

二.问题的本质

关键点就在于: **Accept()**后面的逻辑如果不并发,那么整个服务器就是串行的
我原本的程序逻辑实际上是这样的

接收连接A →处理A的登录(阻塞) →A没有处理完 →B永远等不到处理机会

而登录/注册的阻塞有很多种:

• conn.Read()可能因为网络问题阻塞
• 密码验证
• 用户输入慢,失败重试–只要有一个人在输入密码,后面所有人陪着等
• 数据库访问

聊天室中,不止是聊天需要并发,登录注册同样需要

三.修改方案

给每个连接都启动一个goroutine

for { conn, err := listener.Accept() if err != nil { continue } go handleConn(conn) }

这样修改完之后,整体的逻辑就变成了这样:

主 goroutine:只负责 Accept 新连接 | |-- goroutine #1 → 客户端 A（登录） |-- goroutine #2 → 客户端 B（聊天） |-- goroutine #3 → 客户端 C（注册） |-- goroutine #4 → 客户端 D（登录）

四.goroutine在聊天室中的"真实分工"

1. 连接 goroutine

go handleConn(conn) // 一个客户端一个goroutine // 生命周期 = 连接生命周期

2. 读写解耦 goroutine

go readLoop(conn) go writeLoop(conn) // 读写不阻塞,写不影响读

3. 登录注册 goroutine

go func() { user := login(conn) loginResultChan <- user }() // 登录校验不阻塞消息接收

4. 心跳检测/超时踢人 goroutine

go func() { ticker := time.NewTicker(30 * time.Second) for range ticker.C { checkAliveUsers() } }() // 定时任务不能阻塞主流程

完全可以把这些需要用的放在一个控制整体流程的函数,然后给这个函数起一个协程

五.goroutine 带来的第二层问题

当你开始大量使用 goroutine，很快会遇到这些新问题：

1. goroutine 泄露

go func() { msg := <-ch // 客户端已经断开 }()

客户端已经断开,goroutine会永远挂着,造成goroutine泄露
解决方案:使用context包管理协程生命周期;连接关闭时 close channel

2. 在线用户 map并发读

onlineUsers[userID] = conn // 并发不安全

解决方案: 加锁:sync.Mutex 或者channel + 单 goroutine 管理状态
3. 广播消息阻塞

for _, conn := range conns { conn.Write(msg) // 一个慢客户端拖垮全体 }

每个用户一个发送 goroutine;发送channel

六.协程相关内容回顾

1. 基本概念
   定义:Go 语言中的轻量级并发执行单元，由 Go runtime 调度
   特点：
   • 创建成本极低（初始栈 ~2KB，可动态增长）
   • 由 Go 调度器而非操作系统线程管理
   • 可以同时运行成千上万个 goroutine
     基本用法:

go func() { fmt.Println("Hello, goroutine!") }()

2. goroutine 生命周期
   1.创建（调用 go func() {}）
2. 可运行（等待被调度）
3. 运行（实际在 CPU 上执行）
4. 阻塞（IO、channel、锁等）
5. 结束（完成或被取消）

阻塞的 goroutine 不占用 OS 线程，Go runtime 会调度其他 goroutine 继续执行。

3. goroutine 与线程的关系

多个 goroutine 可以共享少量线程，由 Go runtime 调度
并发 ≠ 并行：

• 并发：逻辑上同时执行
• 并行：物理上同时执行（受 CPU 核心限制）

4. GMP 调度模型(Go核心原理)

• G (Goroutine)：执行单元
• M (Machine / OS 线程)：执行 G 的实际线程
• P (Processor)：调度器，控制可运行 goroutine 队列

调度流程:

1. 新建 goroutine → 放入 P 的本地队列
2. M 从 P 的队列取 G 执行
3. G 阻塞 → 挂起，M 可执行其他 G
4. 空闲 P 会“工作窃取”其他 P 的队列

并行度由 runtime.GOMAXPROCS(n) 控制（默认等于 CPU 核心数）

5. goroutine 常见问题

• 泄露:goroutine 永远阻塞，未退出
  解决：context + close(channel) + 检查阻塞点
• main goroutine提前退出,所有的子 goroutine 会被强制结束
  解决: 阻塞 main（WaitGroup / select / channel）
• 闭包变量捕获陷阱

for i := 0; i < 3; i++ { go func() { fmt.Println(i) }() // ❌ go func(i int) { fmt.Println(i) }(i) // ✅ }

• channel 阻塞:发送方满,接收方空时阻塞
  解决:缓冲 channel / 超时 / 丢弃策略
• 无限创建 goroutine:容易OOM
  解决:控制数量 / worker pool

OOM 是 Out Of Memory 的缩写,表示系统内存被占满;Go runtime会抛出panic,程序崩掉
典型表现:fatal error: runtime: out of memory

6. goroutine使用建议

• 原则：凡是可能阻塞的逻辑，都用 goroutine 隔离。
• 不要滥用：短小、非阻塞、一次性操作不必 goroutine。
• 确保退出路径：每个 goroutine 都应能被取消或结束。
• 通信首选 channel，共享状态用锁或单 goroutine 管理。

以上是本人在学习过程中遇到的困难和疑惑，希望这些分享可以帮到你，也希望得到你的指导和建议。