WangzJi opened a new issue, #3025: URL: https://github.com/apache/dubbo-go/issues/3025
### ✅ Verification Checklist - [x] 🔍 I have searched the [existing issues](https://github.com/apache/dubbo-go/issues) and confirmed this is not a duplicate ### 🚀 Go Version 1.23.0 ### 📦 Dubbo-go Version v3.3.0 ### 🖥️ Server Configuration _No response_ ### 💻 Client Configuration _No response_ ### 🌐 Protocol Configuration _No response_ ### 📋 Registry Configuration _No response_ ### 💾 Operating System 🍎 macOS ### 📝 Bug Description ## 🐛 Critical Memory Leak Issues ### 🚨 **HIGH PRIORITY: Goroutine Leaks** #### 1. Log Rotation Goroutine Leak (`filter/accesslog/filter.go`) **Problem**: The `startLogRotator()` method creates a goroutine with infinite loop but no exit mechanism. ```go func (a *accessLogFilter) startLogRotator() { go func() { ticker := time.NewTicker(a.rotateInterval) defer ticker.Stop() for { select { case <-ticker.C: a.rotateLog() // No exit condition } } }() } ``` **Impact**: Each `accessLogFilter` instance leaks one goroutine permanently, accumulating with service restarts or dynamic filter creation. **Proposed Solution**: ```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 // Exit on context cancellation } } }(ctx) } ``` #### 2. Triple Protocol Connection Handler Leak (`protocol/triple/triple_protocol/server.go`) **Problem**: Connection handler goroutines lack exit mechanisms and timeout controls. ```go func (s *Server) handleConn(conn net.Conn) { for { // Processing logic without exit condition // Blocks indefinitely on abnormal disconnections } } ``` **Impact**: Abnormal client disconnections leave handler goroutines running indefinitely. **Proposed Solution**: - Add connection timeouts using `SetReadDeadline`/`SetWriteDeadline` - Implement server-level context for graceful shutdown - Monitor connection status and exit on disconnection ### ⚠️ **MEDIUM PRIORITY: Resource Leaks** #### 3. File Handle Leak in Log Rotation (`filter/accesslog/filter.go`) **Problem**: Old file handles are not closed before opening new ones during log rotation. ```go func (a *accessLogFilter) rotateLog() { // os.Rename without closing old handle err = os.Rename(a.accessLog, newPath) // Direct overwrite without cleanup a.logFile = newFile // Old handle leaked } ``` **Impact**: Accumulates file handles leading to "too many open files" errors. **Proposed Solution**: ```go func (a *accessLogFilter) rotateLog() { if a.logFile != nil { a.logFile.Close() // Close before rotation } // ... rotation logic } ``` #### 4. Nacos Client Connection Leak (`registry/nacos/service_discovery.go`) **Problem**: `Destroy()` method doesn't close Nacos client connections. ```go func (n *nacosServiceDiscovery) Destroy() error { // Empty implementation - no cleanup return nil } ``` **Proposed Solution**: Call Nacos SDK shutdown methods to release connections and goroutines. ### 🔄 **LOW PRIORITY: Cache and Reference Issues** #### 5. Global Extension Cache Growth (`common/extension/extension.go`) **Problem**: Global maps store extensions without expiration or removal mechanisms. - Risk: Long-running services with dynamic plugin updates accumulate unused extensions #### 6. Circular References (`protocol/invoker.go`) **Problem**: Invoker and URL structures hold mutual references, increasing GC overhead. ### 🔄 Steps to Reproduce 1. Create dubbo-go service with access log filter enabled 2. Run service for extended period (24+ hours) 3. Observe increasing goroutine count and memory usage 4. Check file handle count: `lsof -p <pid> | wc -l` ### ✅ Expected Behavior - Goroutine count should remain stable during service operation - Memory usage should not grow continuously without load increase - File handles should be properly managed and released - Service should handle graceful shutdown cleanly ### ❌ Actual Behavior - Memory usage grows continuously - File handle leaks occur during log rotation - Connection resources remain unreleased on service shutdown ### 💡 Possible Solution _No response_ -- 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: notifications-unsubscr...@dubbo.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@dubbo.apache.org For additional commands, e-mail: notifications-h...@dubbo.apache.org
