[Bug]: memory leaks of disconnected connections

[xuhuigithub]

Actions I've taken before I'm here

• I've thoroughly read the documentations on this issue but still have no clue.
• I've searched the Github Issues but didn't find any duplicate issues that have been resolved.
• I've searched the internet for this issue but didn't find anything helpful.

What happened?

连接在关闭后关于连接的异步任务asyncWrite会继续执行并且申请内存后不释放，下边是内存截图

换成Write就好了。

Major version of gnet

v2

Specific version of gnet

v2.5.7

Operating system

Linux

OS version

Linux 6.2.0-39-generic x86_64

Go version

1.20

Relevant log output

gnet] 2025-01-10T13:26:34.090595704Z	WARN	logging/logger.go:263	error occurs in user-defined function, use of closed network connection
[gnet] 2025-01-10T13:26:34.090602406Z	WARN	logging/logger.go:263	error occurs in user-defined function, use of closed network connection
[gnet] 2025-01-10T13:26:34.090608067Z	WARN	logging/logger.go:263	error occurs in user-defined function, use of closed network connection
[gnet] 2025-01-10T13:26:34.090618116Z	WARN	logging/logger.go:263	error occurs in user-defined function, use of closed network connection

Code snippets (optional)

No response

How to Reproduce

Steps to reproduce the behavior:

1. 初始化两个event loop 一个前端（接收请求）一个后端（转发请求）
2. 前端使用asyncWrite写入后端连接，后端关闭连接

Does this issue reproduce with the latest release?

It can reproduce with the latest release

[panjf2000]

AsyncWrite 确实是可以继续执行的，但最后会判断连接是否已关闭，已关闭会再回调里返回错误。你是不是 Conn 自己存起来没释放掉？

还有，请提供能复现这个问题的完整代码。

[gh-translator]

🤖 Non-English text detected, translating ...

---

AsyncWrite can indeed continue to execute, but it will eventually determine whether the connection has been closed. If it is closed, an error will be returned in the callback. Did Conn save it himself and not release it?

Also, please provide complete code that reproduces this issue.

[panjf2000]

你的这个问题应该是 gnet.Conn 还在其他地方有引用 (比如你是不是把 Conn 存在自己的 map 里没有删除)，所以 GC 没有回收这部分内存。你把 Conn 的引用去掉应该就没有这个问题了。

不过这里也确实可以优化一下，AsyncWrite/AsyncWritev 函数里检测到 Conn 已关闭之后就可以直接把内存释放掉：#673

[gh-translator]

🤖 Non-English text detected, translating ...

---

Your problem should be that gnet.Conn is still referenced in other places (for example, did you store Conn in your own map without deleting it), so the GC did not reclaim this part of the memory. If you remove the reference to Conn, this problem should disappear.

However, it can indeed be optimized here. After detecting that Conn has been closed in the AsyncWrite/AsyncWritev function, the memory can be released directly: #673

[xuhuigithub]

是的，前几天我手头不方便用电脑但我看到了邮件，有个问题，在提这个问题之前我在看源码的时候看到了判断，write时的isopend判断，我今天测试了你的修复，感觉还是线程之间有竞争，onclose 和 onread会并行触发，https://github.com/panjf2000/gnet/issues/557 我在看issue时看到了这个，想问一下什么时候会有这个issue的里程碑

[gh-translator]

🤖 Non-English text detected, translating ...

---

Yes, I was inconvenient to use a computer a few days ago, but I saw the email and there was a question. Before raising this question, I saw the judgment when looking at the source code, the isopend judgment during write. I tested your fix today. , it feels like there is still competition between threads, onclose and onread will be triggered in parallel, https://github.com/panjf2000/gnet/issues/557 I saw this when I was looking at the issue and wanted to ask when there will be a milestone for this issue.

[xuhuigithub]

release一遍。但当asyncwrite还在写入时，会再从池中分配出来，release就没效果了

[gh-translator]

🤖 Non-English text detected, translating ...

---

release again. But when asyncwrite is still writing, it will be allocated from the pool, and release will have no effect.