【开源】基于 IOCP 完成端口的异步高性能日志组件 v1.7

易造轮

类_IOCP日志框v1.7.e (27.9 KB, 下载次数: 70, 售价: 5 枚 精币)

2026-7-19 06:53 上传

点击文件名下载附件
售价: 5 枚 精币  [记录]
下载积分: 精币 -2 枚

大家好，在开发高频通信、多线程或大型项目时，日志记录往往是导致程序卡顿、甚至崩溃的隐形杀手。为了彻底解决这个问题，本人封装了一个基于 Windows IOCP（完成端口）机制的异步日志组件。

经过反复测试与打磨，推出了 v1.7 版本。本版本重构了底层内存与状态机逻辑，彻底解决了以往多线程日志组件中常见的“死锁、内存泄漏、UI假死、空指针崩溃”等顽疾，目前已达商业级稳定标准，现开源分享给大家。

核心特性

1. 真·异步不卡顿：基于 IOCP 完成端口，所有文件写入和 UI 刷新均在独立后台线程执行，调用 输出() 方法瞬间返回，绝不阻塞主线程或业务线程。
2. 无锁化设计：核心计数器采用 InterlockedIncrement 原子操作，避免临界区等待，多线程并发性能极高。
3. 智能 UI 联动：自带超级列表框绑定，日志超 2000 条自动清空（避免逐行删除带来的严重 UI 假死），超长文本自动截断并提示。
4. 非阻塞弹窗提示：支持严重错误弹窗提醒。弹窗逻辑在独立线程执行，即使不点“确定”，也完全不影响后续日志的记录和程序的运行。
5. 安全销毁机制：严格的状态机保护（未启动/运行中/正在创建/正在销毁）。销毁时自动等待队列排空，绝不碰已释放的 UI 组件，防止退出时闪退。

v1.7 核心更新记录（重点）

相较于旧版，本版本修复了多个致命隐患：

• 【修复空指针崩溃】：当传递空的日志类型时，旧版底层 指针到文本(0) 会引发 0xC0000005 崩溃；新版增加严格指针校验，安全处理空文本。
• 【修复计数器死锁】：重构 输出 方法逻辑，严格保证“只有 IOCP 投递成功才递减计数”。旧版中若内存分配失败或投递失败，会导致 m_Count 无法归零，最终引发 销毁() 时程序彻底死锁。
• 【修复 UI 严重假死】：旧版列表框超限时采用循环删除 1500 行，由于跨线程 SendMessage 同步特性，会导致 UI 线程被霸占卡死。新版改为瞬间 全部删除，丝滑流畅。
• 【修复内存泄漏】：完善了分配失败时的现场清理逻辑，杜绝了孤立的内存堆。
• 【修复文件轮替死循环】：优化了日志文件创建逻辑，强制预创建空文件，避免目录权限或异常导致的“一直重复提示更替日期”死循环。

调用示例

极其简洁，开箱即用：

.局部变量 我的日志, 类_IOCP日志框

' 1. 创建并绑定超级列表框
我的日志.创建 (超级列表框1, , , , )

' 2. 常规记录日志 (不卡UI，瞬间写入文件和列表框)
我的日志.输出 (“用户登录成功，IP: 192.168.1.1”, “系统消息”, , )

' 3. 严重错误记录并弹窗 (弹窗独立线程，不卡主程序，后台继续记录)
我的日志.输出 (“数据库连接断开！”, “致命错误”, 假, 真)

技术细节分享：为什么不用 PostMessage 更新 UI？

作为模块，外部窗口句柄未知，无法直接 PostMessage。本组件采用跨线程直接调用组件方法（底层 SendMessage 同步）。虽然这是妥协方案，但通过限制单次调用频率和规避大量循环操作，在实际高频测试中表现出了极高的稳定性。如果外部有其他线程也在修改该列表框，建议外部自行加临界区保护，但切忌在持有临界区时等待后台线程，以免死锁。

lassgo

IOCP日志组件啊，这个确实刚需呢。异步高性能，写服务器的时候应该能用上，我先下个试试水。

liqiang52

nb

lovetuantuan

感谢分享，支持开源！！！

please

感谢分享，支持开源！！！

please

感谢分享，支持开源！！！

易造轮

tian89 发表于 2026-7-20 01:19
有心了可是你有没有想过人家本来就要使用IOCP开发服务器你又来一个IOCP日志不觉得多余了吗?还有可能抢资源, ...

我们需要理清一个概念：IOCP 本身只是一个线程安全的“排队队列”。
你的 _任务处理函数 是唯一的一个“服务员”（工作线程）。如果服务员在处理某个任务时卡住了（阻塞了），那么后续排在队列里的任务就只能干等，无法被处理。

在你目前的代码中，哪些任务会阻塞工作线程？

1. 插入日志文件（磁盘 I/O）
   写入文件是需要和硬盘打交道的。正常情况下，写入一行文本非常快（微秒级），感觉不到阻塞。但如果遇到机械硬盘正在被其他程序大量占用，或者系统发生 I/O 卡顿，工作线程就会停在这里，直到写入完成。在此期间，新调用 输出() 投递的日志会在 IOCP 队列里排队。
   （不过对于日志来说，这种微小的阻塞是完全可以接受且必须的，总不能不写盘吧。）

2. 插入窗口日志（跨线程 UI 更新）
   这是最容易产生明显阻塞的地方。你在工作线程调用 m_日志框组件.插入表项()，底层相当于给主 UI 线程发了一个 SendMessage。工作线程会死等 UI 线程处理完这条消息。

   • 如果 UI 线程很闲，瞬间处理完，阻塞忽略不计。
   • 如果 UI 线程刚好在做耗时操作（比如正在响应用户的鼠标拖拽，或者在处理其他复杂计算），工作线程就会被卡住几秒甚至更久。

3. 信息框（已完美解决）
   如果你没有把弹窗分离到独立线程，用户不点“确定”，工作线程就会一直卡死。但你上一版已经用 CreateThread 把弹窗独立出去了，所以这个最大的阻塞源已经被你消除了！

队列阻塞会带来什么后果？

1. 日志显示延迟：高并发时，如果工作线程被卡了 1 秒，这 1 秒内产生的几百条日志会在内存队列里堆积，等卡顿结束，它们会瞬间一股脑写入文件和列表框。
2. 销毁() 超时：如果调用 销毁() 时，工作线程正好卡在写文件或更新 UI 上，WaitForSingleObject 就会一直等，导致程序退出时感觉卡顿。

需要修改吗？

不需要修改，目前的架构是最合理的。

虽然在极端情况下会有微小阻塞，但：

1. 日志写入磁盘是刚需，不可避免。
2. UI 更新如果不跨线程发送消息，就得用 PostMessage 重新写一套复杂的消息中转机制（对于模块来说太重了）。目前只要保证 UI 线程不死循环，几百条日志的 SendMessage 是非常快的。
3. 最致命的阻塞源（弹窗）已经被你剥离出去了。

所以，目前的 _任务处理函数 虽然理论上有被阻塞的可能，但在实际 99.9% 的应用场景中，它的处理速度远大于日志产生的速度，队列随时都是空的，完全不会感觉到阻塞。可以放心使用！

tsg2005

感谢分享

胖子葛格

感谢大神分享~！

一指温柔

感谢分享