.NET的那些事儿(7)——C#线程编程

本文探讨了多线程编程的优势与潜在风险,并提供了实用的编程建议。介绍了何时及如何使用多线程来提高应用性能,同时避免常见的并发问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

使用多线程技术能有效地帮助你实现应用程序的更高性能和更优良的可伸缩性。但在真正运用这项技术的时候务必小心。本文是对线程技术所牵扯的工具和技术问题系列文章的开篇。我首先对线程概念进行介绍,然后总结一些常用的构造,最后介绍它们的用法。

 

线程的两面性  
用Java语言编写多线程程序并不难,这是好事也是坏事。微软在开发C#时,他们把这种易用性的窘境全盘照搬到了整个新平台上。同时,C#相比Java具有更多的程序原语,但是Thread对象和同步监视器的基本Java原语从形式和功能上看都已足够提供强大的线程编程能力了。因此,在决定为应用程序采用多线程技术之前务必小心。

为什么不用多线程
首先得记住,在决定是否采用多线程技术时,除非你正在玩代码,否则千万别因为多线程编程够“酷”而简单地使用线程技术编程。多线程编程技术太时髦了,如果你不小心点你的老板迟早也会着迷,那时你就死定了。其次,不要因为让程序运行得更快而轻易采用多线程,除非你真的能证明单线程实现确实慢得可以。最后,在冒昧地一头扎进多线程机制之前,先回忆下微软所提供的一种公寓(apartment)模型,也就是把对象写成单线程构造而运行在多线程环境下。所以,说来说去,你并不一定非要采用多线程编码。不过,公寓模型是另外一个话题了。
如果做得不对,多线程编程势必会打开“潘朵拉的盒子”(意思是说惹出无数的麻烦)。重复性不明显、产生程序垃圾、记数器没有正确增值等等。你的应用程序还可能突然挂起。例如,数据库连接这类资源就可能出人意料地关闭或者变得过载。高级开发人员所面临的一个大麻烦就是解决线程问题。这些大问题不花点时间休想解决,而且它们对产品交货日期以及产品可靠性产生了严重的负面影响。

为什么要用多线程
如果你的应用程序需要采取以下的操作,那么你尽可在编程的时候考虑多线程机制:
连续的操作,需要花费忍无可忍的过长时间才可能完成
并行计算
为了等待网络、文件系统、用户或其他I/O响应而耗费大量的执行时间
所以说,在动手之前,先保证自己的应用程序中是否出现了以上3种情形。

如果你的代码运行得足够快,但是你认为你能让它运行得更快(假设你确实有这本事),我劝你最好不要接受这种诱惑。如果你不能肯定程序的计算操作并行性(例如针对同一数据表的并发数据库更改——当你的数据库达到了数据表级锁定的情况下),那么再想想其他法子吧。还有,如果你不知道应用程序是否因为等待输入或输出而花费了过多的时间,那么请首先搞清楚真正耗费时间的情况再说。实际上,启动3个线程以百万分之一的步长计算圆周率所消耗的时间就比同一线程重复计算3次要长得多。为什么会出现这种失败的情形呢?原因就在于,虽然第2条并行计算确实可用,但设计者却恰恰忽略了以上第3个标准:并行计算可以用到的一次计算期间却没有空闲周期。

假如你在为一台装备了多个处理器的并行计算机编写程序,则以上规则在这种情况下例外,你可以通过适当的并行操作设计而令软件性能大大获益——哪怕每一操作都对CPU时间极其贪婪。

基本的线程管理工具
刚才我已经为多线程编程提出了相当程度的警告,同时还为何时使用或者不使用多线程提出了建议,接下来我对多线程编程所能利用的某些工具进行阐述。

Thread对象
.NET库提供了一种名为System.Threading.Thread的对象,这种对象代表了单一线程。你可以启动线程、在当前线程继续运行的情况下设法完成线程的任务。这对那些需要打印文档或者保存大型文件但希望获得用户确认请求并给用户返回控制的应用程序来说帮助实在太大了。我们通过程序清单A演示了这一机制。

线程编程主要包括:线程的创建、挂起、唤醒、终止等操作

具体测试代码如下所示:

另外一个代码如下所示:

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值