关于BackgroundWorker资源占用问题

Question

    累加一int值，通过BackgroundWorker向窗口的label控件和progressBar显示，在拖动窗口时感觉比较占用资源，反应
较慢，但用thread建立线程则几乎没有影响？

Answer 1

BackgroundWorker的原理也是多线程,是个小对象,不会占用太多资源.楼主可检查一下你的代码,或是把代码贴出来,让大伙帮你分析.

Answer 2

觉得BackGroundWork效果不错的啊.呵.没觉得哪儿不好,不太懂LZ的意思,代码秀一下吧.嘻.MARK,学习一下

Answer 3

累加一int值
=====
不知道你是怎么实现这个的，需要看了代码才知道。一般没有遇见你描述的问题。偶尔有CPU占用较高的情况，也是因为我写的循环的缘故。一般在循环中Sleep几百毫秒就好了。

Answer 4

    累加时同样Sleep(0)，用BackGroundWork组件时，拖动窗口时有较大延迟，
但用thread建立的线程，在拖动窗口时有没有延迟现象，为何？   其他情况：
       用Application.DoEvents()比较占用CPU资源，用BackGroundWork组件，
Sleep(>0)时，progressBar显示得很慢，但窗口拖动时没有延迟反应。

Answer 5

    近日我在bbs.msproject.cn找到一个多线程的代码，用BackgroundWorker的，
所以我想对比一下，代码只是通过累加一int值，并显示到窗口的progressBar控件上，
累加过程中用了Sleep(0)，代码较乱，懒得贴了，我再找一下原因，明晚结贴。

Answer 6

同一种累加方式，没有直接在主线程内操作，只是用不同类实现而已（BackgroundWorker、thread）。

Answer 7

    呵呵，原来我的测试代码有问题，用thread类时直接在窗口类内声明操作没问题，但用BackgroundWorker
时，要将其声明在另一类中才没有影响主窗口的其他操作。
    奇怪？既然是独立线程，在那里声明不是一样吗？唉！基础差，想不通！再找找原因.........

Answer 8

你可能没有仔细去研究到底BackgroundWorker是怎么封装Thread的。BackgroundWorker的ProgressChanged和Completed两个方法都是在主线程（有时是创建BackgroundWorker实例的线程），而DoWork方法则是在新线程中执行的。这一点在使用调试器调试的时候可以看得很明显。估计你的测试代码出错就是因为几个线程间关系没有理清的缘故吧。

Answer 9

前几天我在MSDN上找到一段：
   处理 ProgressChanged 和 RunWorkerCompleted 事件的方法可以访问应用程序的用户界面，
原因是这两个事件是在调用了 RunWorkerAsync 方法的线程上引发的。但是，DoWork   事件处
理程序无法操作任何用户界面对象，原因是它在后台线程上运行。    我知道为何ProgressChanged 和 RunWorkerCompleted 事件在主线程上执行，但不懂的是，
thread作为窗体类一属性来建立线程或在独立一个类中声明thread建立线程操控窗体内控件，
结果是一样的，而BackgroundWorker，作为窗体类一属性来建立线程或在独立一个类中声明
操控窗体内控件结果有很大差别！！？？