我想我已经完成了ThreadPool的测试了,测试的代码和初始结果看这里,后来又做了一次更加详细一点的测试,结果看这里。
我想结论已经很明显了,相对于不使用线程池的多线程来说,如果任务比较多,根本就是鸡蛋碰石头,性能相差非常的明显!(当然是线程池比较优秀啦。)当然,对于非常少量的大任务而言,多线程也许更简单,也更合理。但是性能差别还是不大的,除了一点:由于任务持续时间长,必然占用线程池有限的线程数量,可能造成无法展开其他任务。此外,我刚刚考虑到一点——如何中断线程池的任务呢?这个问题需要考虑一下。
相对于单线程来说,只要任务压力足够,线程池的管理和调度的消耗就会填平,甚至还有一定的优势存在。此外,由于多个线程存在,压榨了其他一些实际上并不是很必要的线程的CPU时间。换句话说,线程池拥有比单线程要好的抗变化、抗阻塞能力。比如说很简单的,如果突然有一些磁盘IO操作,可以看到对线程池的影响要比单线程要小。而且这里的测试,仅仅是纯数学意义上面的计算,不应该有任何的缓冲不命中、猜测转移错误等阻塞,更不会有IO操作阻塞。因此,使用线程池应该有比较好的前景。
当然,也有人会有一些担心,我想这些担心我也知道,我会仔细考虑的。正如我的某一个Post回复所说的,这个测试的目的是证明线程池在效率上面是可以的,而不是证明线程池就一定能够应用到所有地方。
我想结论已经很明显了,相对于不使用线程池的多线程来说,如果任务比较多,根本就是鸡蛋碰石头,性能相差非常的明显!(当然是线程池比较优秀啦。)当然,对于非常少量的大任务而言,多线程也许更简单,也更合理。但是性能差别还是不大的,除了一点:由于任务持续时间长,必然占用线程池有限的线程数量,可能造成无法展开其他任务。此外,我刚刚考虑到一点——如何中断线程池的任务呢?这个问题需要考虑一下。
相对于单线程来说,只要任务压力足够,线程池的管理和调度的消耗就会填平,甚至还有一定的优势存在。此外,由于多个线程存在,压榨了其他一些实际上并不是很必要的线程的CPU时间。换句话说,线程池拥有比单线程要好的抗变化、抗阻塞能力。比如说很简单的,如果突然有一些磁盘IO操作,可以看到对线程池的影响要比单线程要小。而且这里的测试,仅仅是纯数学意义上面的计算,不应该有任何的缓冲不命中、猜测转移错误等阻塞,更不会有IO操作阻塞。因此,使用线程池应该有比较好的前景。
当然,也有人会有一些担心,我想这些担心我也知道,我会仔细考虑的。正如我的某一个Post回复所说的,这个测试的目的是证明线程池在效率上面是可以的,而不是证明线程池就一定能够应用到所有地方。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· .NET周刊【3月第1期 2025-03-02】
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器