Linux操作系统自带的测试内存泄漏的命令：
watch -n 1 "ps -o vsz,rss,pmem,comm -ppidof DataBridgeDeamon
通过查看：rss的数据变化来粗略的判断是否有内存泄漏。
在嵌入式开发和 Qt 编程中，内存泄漏（Memory Leak）通常是指程序申请了内存但未能正确释放，导致可用内存持续减少。
结合你目前的 TCP 服务器项目，常见的内存泄漏原因可以归纳为以下几类：
1. 逻辑性堆积（最隐蔽的原因）
这是你之前遇到的情况。程序并没有“忘记”释放内存，而是数据产生的速度快于处理的速度，导致数据在内存中无限堆积。
- 缓冲区积压：如
m_receiveBuffer没能成功匹配到协议帧，导致数据只增不减。 - 信号槽队列溢出：使用
Qt::QueuedConnection时，如果发送信号频率极高，事件循环来不及处理，每个挂起的信号及其携带的参数（如巨大的QString）都会占用内存。
2. Qt 特有的对象生命周期问题
Qt 提供了QObject的父子树机制来自动管理内存，但如果不熟悉该机制，很容易出错：
- 孤儿对象：通过
new创建了QObject对象，但没有为其指定parent，且没有手动delete。 - 重复创建：在定时器或频繁触发的槽函数（如
handleNewConnection）中new了对象，却忘记在关闭连接时调用deleteLater()。
注意：在 Qt 中，建议对
QTcpSocket使用socket->deleteLater()而不是delete socket，以防删除时还有未处理的事件导致崩溃。
3. 临时大对象的频繁拷贝
虽然这不一定是严格意义上的“泄漏”，但它会导致RSS (常驻内存)快速上升：
- 字符串转换：在高频函数中使用
QByteArray::toHex()、QString::arg()拼接大字符串。这些临时对象在被垃圾回收前会占用大量内存空间。 - 容器深拷贝：频繁地将大型
QByteArray或QList作为信号参数进行值传递，而不是使用引用或常量引用。
4. 经典的 C++ 内存管理错误
这些是所有 C++ 程序员都会面临的基础问题：
- 只申请不释放：调用了
malloc/new但没有对应的free/delete。 - 异常退出导致的泄漏：程序在
new之后、delete之前因为return或抛出异常而退出，跳过了释放逻辑。 - 析构函数未定义为虚函数：当删除一个指向子类对象的基类指针时，如果基类析构函数不是
virtual，子类的析构函数不会被调用。
5. 第三方库或系统层缓存
- Glibc 内存碎片：有时候程序释放了内存，但操作系统的内存管理器（如
glibc）并没有立刻将物理内存归还给内核，而是保留在自己的“内存池”中以备后用。这表现为 RSS 很高，但实际上并没有持续泄露。 - 日志系统缓存：如果你向控制台或文件输出大量日志，系统可能会缓存这些 IO 操作，占用一定的内存。
总结
对于我现在的 TCP 项目，内存增长的前三大元凶通常是：
- 信号槽里的
toHex字符串。 - 未处理的数据在
m_receiveBuffer中积压。 - **频繁
new出的QTcpSocket没有被正确deleteLater()**。
建议建议：既然现在观察到 RSS 每 13 分钟增长约 0.5MB，建议运行 1 小时。如果 1 小时后它停留在 30-40MB 不动了，通常不需要担心；如果它一直涨到 100MB 以上，说明代码里肯定还有一个new出来的对象没有被管理起来。
