-
-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: memory leak #4431
base: dev
Are you sure you want to change the base?
fix: memory leak #4431
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make only necessary modifications and avoid changing additional areas according to your own habits.
Channels will be garbage collected after they are no longer referenced, so there is no need to explicitly read all elements.
Try to provide reproducible steps and scenarios.
@@ -54,7 +54,7 @@ type transporterImpl struct { | |||
|
|||
func (impl *transporterImpl) Send(m msg.Message) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I intend to add a context parameter similar to the Do function to allow cancellation of sending.
One case is when the user exits manually, which can be canceled through this mechanism, and another case is for potential scenarios where a timeout might be set later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding context parameters would be a better solution.
In other cases, adding a timeout is indeed a viable solution, and I have considered using this pattern before
@@ -54,7 +54,7 @@ type transporterImpl struct { | |||
|
|||
func (impl *transporterImpl) Send(m msg.Message) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additionally, a TrySend function can be added, which returns a specific error when sendCh is full, instead of blocking. This function is more suitable for certain specific scenarios.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes,Adding TrySend is indeed a way to make it clearer. I didn't read the code thoroughly and may not fully understand the this function.
@@ -66,6 +66,7 @@ func (d *Dispatcher) readLoop() { | |||
m, err := ReadMsg(d.rw) | |||
if err != nil { | |||
close(d.doneCh) | |||
close(d.sendCh) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sendCh does not need to be actively closed; it should be automatically reclaimed after all senders have exited.
As I commented in transport/message.go, I prefer to use a reasonable mechanism to ensure exit on the sender's side.
@@ -97,7 +97,7 @@ func NewControl(ctx context.Context, sessionCtx *SessionContext) (*Control, erro | |||
ctl.msgDispatcher = msg.NewDispatcher(sessionCtx.Conn) | |||
} | |||
ctl.registerMsgHandlers() | |||
ctl.msgTransporter = transport.NewMessageTransporter(ctl.msgDispatcher.SendChannel()) | |||
ctl.msgTransporter = transport.NewMessageTransporter(ctl.msgDispatcher.Send) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hope to keep it as it is.
WHY
在某些特殊情况下,会导致内存泄露
在发送比接收慢的情况下,容易出现sendCh满,会导致后续所有的 goroutine 泄露了