AlexStocks commented on issue #3008:
URL: https://github.com/apache/dubbo-go/issues/3008#issuecomment-3273489737
内存泄漏：
结合提供的 `dubbo-go1` 代码片段，从 **goroutine 管理、资源释放、缓存回收、循环引用** 等维度分析潜在内存泄漏风险，具体如下：
### 一、高风险：goroutine 泄漏（持续占用内存且无法回收）
#### 1. 日志切割 goroutine 无退出机制（`filter/accesslog/filter.go`）
**代码问题**：
```go
func (a *accessLogFilter) startLogRotator() {
go func() {
ticker := time.NewTicker(a.rotateInterval)
defer ticker.Stop()
for {
select {
case <-ticker.C:
a.rotateLog() // 定时切割日志
}
}
}()
}
```
- 该 goroutine 启动后进入 **无限 for 循环**，且未监听退出信号（如 `context.Done()` 或退出通道）。
- 当 `accessLogFilter` 实例被销毁（如服务关闭）时，此 goroutine 仍会持续运行，占用内存和 CPU，导致泄漏。
**潜在影响**：每创建一个 `accessLogFilter` 实例就会泄漏一个 goroutine，若服务频繁重启或动态创建过滤器，会导致大量僵尸
goroutine 堆积。
**修复建议**：添加退出信号监听，通过 `context` 控制 goroutine 生命周期：
```go
func (a *accessLogFilter) startLogRotator(ctx context.Context) {
go func(ctx context.Context) {
ticker := time.NewTicker(a.rotateInterval)
defer ticker.Stop()
for {
select {
case <-ticker.C:
a.rotateLog()
case <-ctx.Done(): // 监听退出信号
return // 退出 goroutine
}
}
}(ctx)
}
```
#### 2. Triple 协议服务器连接处理 goroutine
未清理（`protocol/triple/triple_protocol/server.go`）
**代码问题**：
```go
func (s *Server) Serve() error {
lis, err := net.Listen("tcp", s.addr)
if err != nil {
return err
}
for {
conn, err := lis.Accept()
if err != nil {
return err
}
go s.handleConn(conn) // 为每个连接启动 goroutine
}
}
func (s *Server) handleConn(conn net.Conn) {
// 处理连接逻辑，未关联退出机制
for {
// 读取请求、处理...
}
}
```
- 服务端为每个新连接启动独立 goroutine 处理（`handleConn`），但：
- 未监听连接关闭事件（如 `conn.SetDeadline` 或读取时的 `io.EOF`）；
- 无全局退出信号（如服务关闭时通知所有 `handleConn` goroutine 退出）。
- 当客户端异常断开连接（如网络中断），`handleConn` 可能因阻塞在 `Read` 操作而持续存活，导致 goroutine 泄漏。
**修复建议**：
1. 为连接设置超时时间，避免永久阻塞：
```go
func (s *Server) handleConn(conn net.Conn) {
defer conn.Close()
// 设置读写超时（如30秒）
conn.SetReadDeadline(time.Now().Add(30 * time.Second))
conn.SetWriteDeadline(time.Now().Add(30 * time.Second))
// 处理逻辑...
}
```
2. 通过服务级 `context` 通知所有连接 goroutine 退出：
```go
// Server 结构体添加退出上下文
type Server struct {
ctx context.Context
cancel context.CancelFunc
// ...
}
func (s *Server) handleConn(conn net.Conn) {
defer conn.Close()
for {
select {
case <-s.ctx.Done(): // 服务关闭信号
return
default:
// 正常处理逻辑
}
}
}
```
### 二、中风险：资源未释放（文件句柄、连接、缓冲区）
#### 1. 日志文件句柄未关闭（`filter/accesslog/filter.go`）
**代码问题**：
```go
func (a *accessLogFilter) rotateLog() {
// ...
fileInfo, err := os.Stat(a.accessLog)
// ...
err = os.Rename(a.accessLog, newPath) // 重命名日志文件
// ...
// 未关闭原日志文件句柄，直接重新打开
newFile, err := os.OpenFile(a.accessLog,
os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
if err != nil {
// 错误处理
}
a.logFile = newFile // 覆盖原句柄，导致旧句柄泄漏
}
```
- 日志切割时，仅通过 `os.Rename` 重命名文件，未 **关闭原 `a.logFile` 句柄**，直接用新句柄覆盖。
- 旧文件句柄会持续占用，直到被 GC 回收（但 Go 对文件句柄的 GC 不及时），导致 **文件句柄泄漏**，最终可能触发系统 `too many
open files` 错误。
**修复建议**：切割前关闭旧文件句柄：
```go
func (a *accessLogFilter) rotateLog() {
// ...
// 关闭旧文件句柄
if a.logFile != nil {
a.logFile.Close() // 需处理关闭错误
}
// 重命名文件
err = os.Rename(a.accessLog, newPath)
// ...
// 打开新文件
newFile, err := os.OpenFile(a.accessLog,
os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
// ...
a.logFile = newFile
}
```
#### 2. Nacos 客户端连接未优雅关闭（`registry/nacos/service_discovery.go`）
**代码问题**：
```go
func (n *nacosServiceDiscovery) Destroy() error {
// 未实现 Nacos 客户端连接关闭逻辑
return nil
}
```
- `nacosServiceDiscovery` 的 `Destroy` 方法为空，未调用 Nacos SDK 的 `Shutdown` 或
`Close` 方法释放连接。
- 当注册中心实例销毁时，Nacos 客户端的 TCP 连接、心跳 goroutine 等资源不会释放，导致连接泄漏。
**修复建议**：补充连接关闭逻辑：
```go
func (n *nacosServiceDiscovery) Destroy() error {
if n.client != nil {
// 调用 Nacos 客户端的关闭方法（具体方法名需参考 SDK）
if err := n.client.Close(); err != nil {
return perrors.WithStack(err)
}
}
return nil
}
```
### 三、低风险：缓存未清理与循环引用
#### 1. 全局扩展缓存无过期清理（`common/extension/extension.go`）
**代码问题**：
```go
var (
protocols = make(map[string]ProtocolConstructor) // 全局协议缓存
// 其他全局缓存：loadbalancers、filters 等
)
// RegisterProtocol 注册协议，无删除/过期机制
func RegisterProtocol(name string, constructor ProtocolConstructor) {
protocols[name] = constructor
}
```
- 所有扩展组件（协议、负载均衡器、过滤器等）通过全局 map 缓存，且 **仅注册不删除**。
- 若服务支持动态加载扩展（如热更新插件），旧版本组件会持续占用内存，导致缓存膨胀。
**潜在影响**：长期运行的服务中，未使用的扩展组件缓存会逐渐消耗内存，尤其在频繁更新插件的场景下。
**修复建议**：
1. 为全局缓存添加过期清理机制（如 LRU 缓存）；
2. 提供注销接口，允许删除不再使用的扩展：
```go
// 新增注销方法
func UnregisterProtocol(name string) {
delete(protocols, name)
}
```
#### 2. URL 与 Invoker 循环引用（`protocol/invoker.go`）
**代码问题**：
```go
type Invoker struct {
url *URL // 持有 URL 引用
// ...
}
type URL struct {
invoker Invoker // 持有 Invoker 引用
// ...
}
```
- `Invoker` 与 `URL` 互相持有对方引用，形成 **循环引用**。
- Go 的 GC 虽能识别循环引用并回收，但会增加 GC 标记阶段的开销，长期大量存在可能影响 GC 效率，间接导致内存占用上升。
**修复建议**：打破循环引用，如 URL 中存储 Invoker 的 ID 而非直接引用，需要时通过全局 map 查找：
```go
type URL struct {
invokerID string // 存储 ID 而非直接引用
// ...
}
// 全局 map 维护 ID 与 Invoker 的映射
var invokerMap = make(map[string]*Invoker)
```
### 四、总结：内存泄漏风险优先级与修复建议
| 风险类型 | 优先级 | 核心问题 | 修复关键动作
|
|------------------|--------|-----------------------------------|-----------------------------------------------|
| goroutine 泄漏 | 高 | 日志切割/连接处理无退出机制 | 用 context 或退出通道控制
goroutine 生命周期 |
| 文件句柄泄漏 | 中 | 日志切割未关闭旧文件 | 重命名前显式关闭旧文件句柄
|
| 连接未关闭 | 中 | Nacos 客户端未实现 Destroy | 调用 SDK 关闭方法释放连接
|
| 全局缓存膨胀 | 低 | 扩展组件仅注册不删除 | 增加注销接口或 LRU 过期机制
|
| 循环引用 | 低 | Invoker 与 URL 互相引用 | 用 ID 替代直接引用，打破循环
|
优先修复 **goroutine 泄漏** 和 **文件句柄泄漏**，避免服务运行中资源持续耗尽；全局缓存和循环引用问题可在迭代中优化，减少长期内存占用。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
