AI 都已经开始写代码了，为什么还要继续维护 smart-socket 这样的通信框架？

这是个值得思考的问题。

如今，大模型已经能够生成完整的业务代码，自动补全、测试生成、代码重构……越来越多过去需要开发者亲手完成的工作，正在被 AI 接管。

但这些年的经历，让我越来越确信：

AI 可以生成代码，但无法替代工程积累。

AI 可以写代码，但连接不会消失

AI 改变的是软件的生产方式，但连接不会消失。

IoT 设备、MQTT Broker、即时通讯、实时推送，甚至未来大量协同工作的 AI Agent，本质上都离不开稳定、高效的通信能力。

而真正困难的，从来不是把功能实现出来，而是：

• • 如何降低海量连接的资源占用；
• • 如何在异常场景下及时释放资源；
• • 如何在性能、稳定性和易用性之间找到平衡。

这些问题，没有标准答案，更多来自于长期实践所积累的判断。

一个方法名背后的思考

在 smart-socket 最新版本中，我们调整了一个存在已久的能力。

过去：

server.disableLowMemory();

现在：

server.retainReadBuffer();

实际上，这并不是行为上的变化。

smart-socket 很早就已经支持：在读缓冲区空闲时自动释放内存。

但 disableLowMemory() 这个名字，需要开发者先理解 lowMemory 的含义，再推导默认行为，最后再理解 disable 的作用。

而 retainReadBuffer() 则更加直接：

如果你希望持续保留读缓冲区，以追求极致性能，就主动开启它。

看似只是改了一个方法名，但对于基础软件来说：

易用性，往往就是由这些细节组成的。

为什么敢默认释放读缓冲区？

很多人会担心：

频繁申请和释放 Buffer，不会影响性能吗？

事实上，这也是 smart-socket 设计时重点考虑的问题。

得益于高效的内存池机制，缓冲区的申请与回收开销被控制在极低水平。在绝大多数场景下，这种损耗几乎可以忽略不计。

因此，smart-socket 才敢默认采用这种更加节省内存的策略。

对于 MQTT、IoT 等海量低活跃连接场景而言，真正昂贵的往往不是 CPU，而是内存。

对于绝大多数用户来说：

默认配置，已经是最合理的选择。

比性能更重要的，是稳定性

本次还增强了 MultiplexClient 在异常场景下的资源治理能力。

在实际使用过程中，我们发现，极少数情况下资源未能及时回收，可能导致线程长时间阻塞。

最终，我们选择增加连接获取超时机制。

当资源长期无法获取时，系统会主动抛出异常，而不是无限等待。

因为在生产环境中：

明确的失败，往往比沉默的等待更加友好。

我们应该信任 AI，还是期待作者的创造力？

最近，我也经常思考另一个问题：

在基础软件领域，我们究竟应该信任 AI 生成的代码，还是期待作者自身的创造力？

后来我发现，这其实不是一个二选一的问题。

AI 可以帮助我们提升效率，但为什么这样设计、为什么做出这样的取舍、为什么承担最终责任，这些问题仍然需要有人给出答案。

AI 可以生成代码。

但最终承担设计责任的人，仍然应该是框架的作者。

因为：

代码可以复制，而判断力依然稀缺。

写在最后

AI 正在改变软件开发，但基础软件的价值，从来不只是代码本身。

它更像是一系列长期思考后的选择：

• • 哪些默认值更合理；
• • 哪些复杂性应该由框架承担；
• • 哪些风险需要提前暴露。

这也是为什么，在 AI 时代，我们依然愿意继续打磨 smart-socket。

少一些复杂，多一些克制；少一些炫技，多一些可靠。

也许 smart-socket 永远不会成为最热门的开源项目。

但我仍然希望，当有人需要构建稳定可靠的连接系统时，它会是那个值得被信赖的选择。

💬 加入我们

• • GitHub: https://github.com/smartboot/smart-socket
• • Gitee: https://gitee.com/smartboot/smart-socket

感谢每一位使用 smart-socket 的开发者！你的 Star ⭐ 是我们持续迭代的动力。

欢迎关注我们的公众号，获取更多关于 smart-socket 框架的最新动态和技术分享！

扫描微信二维码备注：smart-socket 可加入 smartboot 社群。（PS：若无备注将拒绝好友申请）